I've moved from Rust to Go for most things because in the era of agents, being able to iterate quickly on a project is a huge advantage and Rust is way, way slower than Go for compilation. There are times when Rust is more appropriate, but for the vast majority of things Go is perfectly fine.
I don't really understand why Rust seems to be the go-to language for llms. Yes sure it has a good type system, but in practice llms seem to trip over it as much as I do, and given how fast llms are at writing code, that just makes compile times a much larger bottleneck.
Rust is built on the idea that code that compile must be correct, to the best of its abilities. LLMs are fast and sloppy, Rust keeps them in check by not letting them get away with preventable bugs.
Of course, Rust can't do anything for spec bugs, like making the stop light green when it should be red, but it can help with crashes and vulnerabilities.
Another thing I might add is that Rust is a relatively popular language, with a culture of writing high quality code. Many people, starting by those of Mozilla chose Rust to write security-critical, efficient software. They wouldn't chose it for throwaway, low skill, non-critical code, as there are languages that are more appropriate for this.
The result is a large amount of high quality code a LLM can train on. Compare to Zig for instance, which is a fine language, but not as popular so lacking in volume for good training. You then can understand why Anthropic ported Bun from Zig to Rust if they intend to vibe code. Languages like PHP, while actually quite decent today, have a long history of terrible code, so not great for a LLM as most of its training dataset is poisoned.
The unfortunate part is that it may not last. If Rust becomes the de-facto language for LLM production, overall quality may decrease. It is a common problem with many machine learning techniques including LLMs: feeding them their own output tend to decrease quality.
Go is full of footguns and LLMs still cannot be trusted to follow the rules they themselves conjured up out of thin air. Unlike humans, they don't need to be taught the language (which is the hardest part of using Rust, by far), so they get more benefits out of it than many humans do.
LLMs do trip up when they generate Rust code, but they also do when generating any other language. The big difference is that the Rust compiler refuses to compile broken code faster, whereas Go will just let you SIGSEGV on edge cases without warning.
The recent TLA+ hype here on HN shows that Rust may just be the beginning here. There are valid, safe Rust programs that will crash, the language isn't perfect. The older languages with more math and validation behind them (Ada?) are probably even better suited for generated code, but they don't have the hype culture to capture mainstream attention (and even fewer people have the ability to really review that code).
There's an alternative solution of course: use platforms like JS/.NET/JVMs/Python to run code that cannot violently crash because of the language runtime around it. That comes with a performance overhead but it's good for prototyping without as many stability footguns and with faster compilations.
slowin · · focus · HN ↗
Bolwin · · focus · HN ↗
GuB-42 · · focus · HN ↗
Rust is built on the idea that code that compile must be correct, to the best of its abilities. LLMs are fast and sloppy, Rust keeps them in check by not letting them get away with preventable bugs.
Of course, Rust can't do anything for spec bugs, like making the stop light green when it should be red, but it can help with crashes and vulnerabilities.
wannabe44 · · focus · HN ↗
[dead]
GuB-42 · · focus · HN ↗
The result is a large amount of high quality code a LLM can train on. Compare to Zig for instance, which is a fine language, but not as popular so lacking in volume for good training. You then can understand why Anthropic ported Bun from Zig to Rust if they intend to vibe code. Languages like PHP, while actually quite decent today, have a long history of terrible code, so not great for a LLM as most of its training dataset is poisoned.
The unfortunate part is that it may not last. If Rust becomes the de-facto language for LLM production, overall quality may decrease. It is a common problem with many machine learning techniques including LLMs: feeding them their own output tend to decrease quality.
jeroenhd · · focus · HN ↗
LLMs do trip up when they generate Rust code, but they also do when generating any other language. The big difference is that the Rust compiler refuses to compile broken code faster, whereas Go will just let you SIGSEGV on edge cases without warning.
The recent TLA+ hype here on HN shows that Rust may just be the beginning here. There are valid, safe Rust programs that will crash, the language isn't perfect. The older languages with more math and validation behind them (Ada?) are probably even better suited for generated code, but they don't have the hype culture to capture mainstream attention (and even fewer people have the ability to really review that code).
There's an alternative solution of course: use platforms like JS/.NET/JVMs/Python to run code that cannot violently crash because of the language runtime around it. That comes with a performance overhead but it's good for prototyping without as many stability footguns and with faster compilations.
mkesper · · focus · HN ↗