I watched a very interesting interview Developers are no longer paid to write code (french audio) (original title “On ne paie plus les développeurs pour écrire du code”) with Quentin Adam from Clever Cloud about how they are using AI coding agents internally.
I mostly agree with him, and I posted on X after watching the video while on the train. But a tweet is not very large to explain fully an idea, so here I am writing this here!
At one point in the video he explains why he thinks Rust works particularly well with LLMs. His argument is that the more constrained a language is, the more useful feedback the compiler gives to the agent. Rust is extremely good at this, so the agent can write code, run the compiler, read what rustc complains about, fix it, and continue until everything is green.
The distinction is interesting because I would not conclude from the success of Rust at Clever that more compiler constraints always mean a better language for coding agents. I do not write Rust myself, so what follows is about what a compiler gives an agent, not about the experience of writing Rust every day (and agents don’t care they will write code anyway).
Rust has an amazing oracle in that the compiler catches things that the Go compiler cannot catch. Ownership mistakes, invalid borrowing, a lot of concurrency problems, exhaustive matching when an enum changes (would be nice to have in Go, in fact it would be nice to have real enums, lol). If an agent adds a new entry to an enum, rustc can give it a list of places that now need to be fixed, this is extremely valuable when you let an agent refactor code autonomously.
The quality of the compiler errors matters too. Rust is known for having a compiler that explains why it is unhappy and often with good suggestions, this is indeed almost made for an LLM. The model does not need to deeply understand ownership the way an experienced Rust developer does (maybe it does). It can read the diagnostic, change something, run cargo check again and progressively move toward code that compiles.
In the video, Quentin also says that Go has a very relaxed compiler, to be put almost in the same bucket as JavaScript. Maybe a little bit misleading 😋. Go is statically typed, the compiler will refuse strange implicit conversions, bad signatures, interface incompatibilities and all that.
The language asks less from the programmer in the first place, for ex. memory ownership is the garbage collector problem. The language has way fewer concepts and abstractions, and fewer clever ways to express the same thing. This can be frustrating for humans coming from richer languages, but I think it becomes almost a feature when the programmer is an agent. Fewer concepts means fewer design decisions to get wrong on the first draft, and fewer iterations spent revisiting a decision.
To me convergence is at least as interesting as compiler strictness when discussing agentic development. The best feedback loop is not necessarily the one producing the most sophisticated error message. It can also be the one that lets the agent reach a correct and understandable solution with few iterations.
Rust does prove things Go cannot like data race, non null reference and exhaustive matching, but it proves nothing about deadlocks and business logic (two mutexes acquired in the wrong order still compile fine AFAIK), and either in Rust or Go an agent writing a test after writing a bug will both be happy about it 😎.
I will always be a fan of this Rich Hickey statement in Simple Made Easy:
What’s true of every bug found in the field?
It passed the type checker.
What else did it do?
It passed all the tests.
As I already said in a previous post, Go has a boring ecosystem, which just works, and the language is super stable. Rust also is very stable, but its ecosystem is richer and can expose agents to more moving APIs, especially once when external crates are being used (see this benchmark). For an LLM trained on years of public source code, consistency is useful (this is also stated by Quentin in the video), old examples being still valid reduces one source of confusions.
Agents also do not validate code once, they check the project, run a targeted test, change code, run some tests and finally build. Rust has cargo check and cargo will reuse previous compilation but tests still have to compile their targets. On growing workspaces that will add up. Go caches aggressively, including successful test results, meaning an unchanged package reports (cached) instead of running again, while cargo test re-runs the tests. In Go the edit/build/test loop is cheap.
This doesn’t make Go “better than Rust for AI”. At Clever Cloud they work on their own database system, kernel level components, and network switch software so they will love anything with as much memory safety and concurrency correctness as possible. But most software being developed is not this kind of software, for HTTP services, CLIs and internal tooling, well a lot of ordinary backend software, Go gives an agent a very attractive environment.
Rust gives the agent a stronger oracle while Go probably gives it an easier problem to deal with.
I think both approaches will work extremely well for agentic programming, for different reasons. When the programmer is an AI agent capable of trying again almost immediately, the ability to converge quickly matters a lot too.
Until next time!