Laurent Gaches

Rust Forces Me to Think

2026-05-09T00:00:00+00:00

Rust Forces Me to Think</a></h1>
I like Rust because it forces me to think.</p>
This is deeply inconvenient.</p>
Most of the time, when I write code, I have a vague but confident feeling that I know what I am doing. Rust has a talent for interrupting that feeling. It asks small, annoying questions like:</p>

who owns this data?</li>
how long should this reference live?</li>
are you sure this value can be shared here?</li>
did you really mean to clone that?</li> </ul>
Rude, honestly.</p>
But also useful.</p>
Data Has to Go Somewhere</a></h2>
One thing I appreciate about Rust is that it makes data flow visible.</p>
When data moves from one function to another, from one module to another, or across a boundary in the system, Rust makes me be explicit about it. I cannot just wave my hands and hope everything remains fine because the code compiled and the test that happened to run passed.</p>
The ownership model can feel strict at first, but I like what it does to the shape of the code. It pushes me to ask where data should live, who should be allowed to change it, and what a function really needs in order to do its job.</p>
That sounds serious. In practice, it often means I spend ten minutes arguing with the compiler and then realize the compiler was right, which is an emotionally complicated experience.</p>
Less Waste Is a Feature</a></h2>
I also like that Rust does not need much to run well.</p>
It is fast, yes, but the part I care about more is that it can be efficient without a lot of ceremony. Less memory, less CPU, fewer oversized containers doing heroic work to serve three requests and a health check.</p>
That matters for cost. When systems scale, waste becomes a line item. A small inefficiency repeated enough times becomes infrastructure, invoices, dashboards, meetings, and then someone says "optimization pass" with a straight face.</p>
It also matters environmentally. I am not pretending that choosing Rust saves the planet by itself. That would be a very intense claim for a programming language. But using fewer resources is still better than using more resources for no reason.</p>
If I can build something reliable, fast, and cheaper to run, I am not going to pretend that is a difficult choice.</p>
Clippy, My Strict Little Colleague</a></h2>
Then there is Clippy.</p>
I like Clippy. I also sometimes wonder if Clippy is okay.</p>
Enable enough lints and it becomes the kind of colleague who reviews your code and says, "This is fine, but have you considered being a better person?"</p>
Some suggestions are obvious. Some are genuinely helpful. Some make me stare at the screen for a moment and quietly accept that yes, technically, the machine has a point.</p>
What I like is that Clippy catches small habits before they become style, and style before it becomes architecture. It nudges the code toward clearer intent. It also teaches the language in a practical way, one mildly judgmental hint at a time.</p>
Should every lint be enabled? Probably not, unless the goal is personal growth through controlled irritation. But I like having that tool available. It makes the codebase feel less like a pile of opinions and more like something with pressure in the right places.</p>
I Still Like Python and Swift</a></h2>
This is not me saying Rust is the only good language. I still like Python. I like how quickly it lets me explore an idea, glue things together, and move from thought to working code without too much negotiation.</p>
I also like Swift. It has a nice balance between expressiveness and structure, especially when building iOS applications. There is a real pleasure in writing Swift when the APIs line up well and the model feels right.</p>
Rust gives me a different kind of satisfaction. It is slower at the beginning, but often calmer later. It asks for decisions early, which can be annoying, but those decisions tend to make the rest of the code easier to trust.</p>
That tradeoff fits the kind of backend and infrastructure work I enjoy.</p>
The Part I Keep Coming Back To</a></h2>
The main reason I like Rust is not performance, safety, or any of the usual brochure words, even if those things matter.</p>
I like it because it makes the important parts harder to ignore.</p>
Data movement. Ownership. Boundaries. Resource usage. Error handling. The small decisions that quietly define whether a system remains understandable six months later.</p>
Rust does not magically make me write good software. That would be convenient, and therefore suspicious.</p>
But it does make some bad shortcuts harder to take by accident.</p>
So yes, Rust makes me think. Terrible feature. Very effective.</p>

Orchestrator and Executor: A Practical Architectural Split

2026-04-28T00:00:00+00:00

Orchestrator and Executor: A Practical Architectural Split</a></h1>
Many AI systems begin with a single service that handles everything: request parsing, planning, tool calls, retries, and response formatting. This is often a reasonable starting point because it keeps delivery fast and implementation simple.</p>
As workflows become more complex, this approach can become harder to maintain. The orchestrator/executor pattern addresses that by separating two concerns:</p>

Orchestrator</strong>: decides what should happen next</li>
Executor</strong>: performs a specific action</li> </ul>
This article looks at that split from an architecture perspective: why it helps, where it costs, and when it may not be necessary.</p>