Rust asked a lot of the people who wrote it. We're no longer the ones writing it.
I had this hunch from reading what people write about Rust and agents: the languages we found too demanding might come back, because we're no longer the ones paying their price.
That suited me: I started out as an Objective-C developer, and I've always kept a soft spot for this neglected language. In 2015, at dotSwift, the first Swift conference in Paris, I watched Daniel Steinberg compare it to French cuisine, as opposed to fast food. The image stuck with me, I still prefer fine dining, and it has become a running joke with our junior developers.
In October 2026, an experiment on Objective-C added weight to that hunch. Fernando Olivares, an iOS developer at 37signals, asked two agents, Claude Opus 5.5 and GPT-6.1 Sol, to build the same chat screen in Swift and in Objective-C, then measured everything on an iPhone 12 and published the code and the results. The agents wrote the Objective-C, and it is the leanest version, on a single measurement pass per version: 35 MB of memory at peak, against 44.5 MB for the best Swift version built with the same framework.
I'm not betting on an Objective-C comeback for all that. But what the experiment shows is serious: an agent effortlessly writes a language we found tedious, and that applies first of all to Rust.
The price of Rust
Rust is the language developers admire most: in the 2026 Stack Overflow survey, 67% of the people who use it want to keep using it, a score no other language reaches. Yet many admire it from a distance. Its compiler rejects anything that isn't safe, and it takes a long time to stop fighting it.
Objective-C was paid for in lines to type, with brackets everywhere. Rust is paid for in compiler rejections. In both cases, the cost fell on the people writing the code. For years, we chose our languages for their comfort.
What the agent changes
An agent doesn't get tired. Writing a forty-character method name costs it a few tokens, not its patience. And the Rust compiler's rejections, which discourage a human, become a free check on its own work.
The first measurements point the same way. When SWE-bench Multilingual launched, a benchmark that asks an agent to fix real issues in nine languages, Rust was the language where the agent succeeded most often, and C or C++ where it succeeded least. In July, a team showed that feeding the Rust compiler's errors to the model while it writes brings the share of code that doesn't compile down from 20.7% to 13.1% (arXiv 2607.13921).
When writing costs almost nothing, what's left is what the language guarantees. For Rust, that's memory safety, and the stakes are concrete: at Chromium, around 70% of serious security bugs are memory safety problems.
And projects are already following. A team studied GitHub projects that use coding agents: among those created after August 2025, the share of Rust projects doubles, 10.5% against 5.3% among older ones, while C and C++ decline (Robbes et al., arXiv 2606.07448). Niko Matsakis, one of Rust's longtime designers, sees it too: in his words, Rust "happens to be a really good fit for agentic coding", and he draws ideas from it for evolving the language. I see it from another angle, that of the price of these languages, which has changed hands.
What I see at work
We needed Rust on a specific project: the same calculation had to give exactly the same result in the browser and on our servers. Writing two versions, one in JavaScript and one on the server side, meant accepting that they would eventually drift apart. Rust compiles to both, but it wasn't part of our stack. We're very happy with the result and the experience, but let's be honest: without agents, we wouldn't have tried.
The same mechanism plays out, more modestly, in our iOS engine. Born in Objective-C in 2011, it was gradually migrated to Swift, because it was getting hard to find developers who master Objective-C. The parts we no longer evolve stayed in their original language, and we can now fix them without depending on whoever on the team can still read it.
Further out: proof languages
Rust isn't the most demanding language. With Lean or Dafny, you write the program, and also the mathematical proof that it does what you expect. The human price is huge: according to Martin Kleppmann, proving the 8,700 lines of C in the seL4 kernel took 20 person-years and about 200,000 lines of proof. Few people know how to write these proofs, and almost nobody does it for ordinary code.
Kleppmann draws a prediction from it: AI will make formal verification mainstream. His argument is the Rust compiler's, pushed to the limit: the proof checker rejects any invalid proof and forces the agent to retry, so a made-up proof doesn't get through.
The numbers partly bear him out. In a study published in September 2025, the models' success rate on Dafny verification tasks had risen from 68% to 96% in a year. At the same date, they solved only 44% of the problems in Verus, the version of Rust built for proofs, and 27% in Lean. Verus is newer, and models have seen less of it.
What I take from it
The question "which language?" had stopped being asked: we took the most comfortable one, and paid the difference elsewhere, in memory vulnerabilities or in bugs no proof had ruled out. Agents reopen the question. We can once again choose a language for what it guarantees, as long as the model knows it well enough.
Cover photo by Judith Browne on Unsplash.
Mathieu Poli, Head of Frontend Engineering at GoodBarber. I write about frontend engineering, product design and AI.
X: hellomathieup · LinkedIn: hellomathieup
Top comments (0)