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.
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.
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.