alt Hacker NewsI love Go and used to write it heavily for anything non LLM based.
Now that we have agentic coding I just write everything in Rust and couldn’t be happier. The struggle with rust was writing it, go was made so it was easy to write for mid level engineers. Now that we have agentic coding I’m not sure Go’s value prop holds up anymore
My rust services have been nothing short of amazing from a performance and reliability perspective
Replies
For me the bottleneck now is reading/reviewing code, not writing code. As you said, AI makes it way easier to write, but do you not review the code? And isn't a verbose, cryptic language with lots of nitty gritty memory management not harder to read/review?
I'm not sold on Rust being a great language to use with AI unless the reason to use it is a lot more than just Rust being fashionable.
Go was never about being easy to write (thought it is), but it was always about being easy to read and it is, by far, the easiest language to read that I've ever used (and throughout the decades, I went through Basic, Pascal, C, Java, JavaScript, C#, TypeScript, Ruby and Python). That becomes even more important if you are not writing the code yourself...
> The struggle with rust was writing it, go was made so it was easy to write for mid level engineers.
In practice, anything that makes it easier for humans to program also makes it easier for LLMs to program.
You also wont typically learn that the LLM is close to the limits of understanding your code base until after it has blown past it's own capabilities, leaving you with a mountain of code that you are not skilled enough to fix.
Java, C# are good choices as they tend to enforce a certain structure. Go, good because it's very readable even if you dont know the language.
C++, Rust are poor choices unless you are already a senior in that language.
Go is really easy to read and write, even if Go's philosophy means that some of that feels clunky because it's less featureful than other languages. It makes up for it with a comprehensive stlib that makes it trivial to build services with few to no third party dependencies.
I don't think the value prop has changed at all there. One day the AI gravy train will stop and people who used AI to punch above their weight will no longer be able to debug the stuff they built unless they put in the hard work of learning the language.
Nothing to worry about with Go in that respect because of how much it's been designed to be simple. Even the annoying err/nil checks you need to do all the time are in service of that simplicity. It gets old fast but it leaves nothing to the imagination.
The value prop of Go in not on writing, but in reading and comprehension by people different from the autor(s). For systems expected to last some years, this translates in reduced total cost of maintenance over the life of the system (in my experience typically 80% or more of the total cost) and facilitating traspassing maintenance to diferent people than the authors. In use cases where Go has "good enough" performance, for backend systems with business logic and small amount of "bare metal" programming, I recommend Go to teams instead of Rust. When extreme performance and reduced memory footprint is more important than the other properties, Rust is better than Go.
>Now that we have agentic coding I just write everything in Rust and couldn’t be happier. The struggle with rust was writing it, go was made so it was easy to write for mid level engineers. Now that we have agentic coding I’m not sure Go’s value prop holds up anymore
Agents seem to have a better time with Go. Humans need to review the agents outputs and in general they have an easier time to do it with Go.
In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust.
They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex<Refcell<` a-la global JS variables for info sharing instead of working out the lifetimes to do it properly. It loves making functions infallible and then panic-ing within them and certainly I wouldn't use them for unsafe at all - they hallucinate safety comments which are in fact, totally unsound.
Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .clone() and an Arc<Mutex<>> means they will spend minutes 'thinking' about basic lifetime issues until I step in and add the missing `move` in a closure.