- There's a lot of Go code out there which the models have seen, so they know how to write it.
- Go has an exceptional standard library, so you don't need to drag in 100 dependencies to create a simple web app.
- Go compiles extremely quickly for incremental builds, which really matters when agents are building and running tests constantly.
- Go has a goldilocks blend of performance and safety. You get a good type system and excellent runtime performance without forcing the model to spend cycles fixing Rust lifetimes or Swift concurrency issues for a marginal incremental gain.
- Go is relatively stable, so the LLM's memorized knowledge is still pretty fresh (as opposed to something like SwiftUI, where the API changes rapidly).
- LLMs have clearly been trained on a lot of Rust as well
- Compile times are counterbalanced by strong compiler with excellent error messages, and "cargo check" can catch many issues without a full build.
- If you're willing to accept Go levels of performance from Rust, there's nothing preventing you from using copies and clones rather than borrows, which makes most code dead simple.
- For most major dependency types, there exists a clear "winner" in terms of community adoption, so the fact that it's not in the stdlib is not that problematic.
With that said, I have not done an extensive amount of agentic development in Rust, so maybe I just don't have the reps to compare fairly.
Nothing costs more tokens than an LLM trying to debug errors caused at runtime which doesn't map well to it's "intelligence" compared to what Rust provides
With golang, all borrow checker problems go away. This is a good trade off if your app is not cpu-bound, which most are not. If you need every last drop of performance then rust is a better choice of course.
However, I have run into a few cases of runtime null crashes in go.
You only have to compile when you actually want to test the behavior, which tends to be right on the first try more often as a result of the strict compiler.