It really isn't.

Poor correctness guarantees, especially w.r.t concurrency. Nil pointer. Why.

LLMs are like a magnifying function. Whatever you put in you get back 10x over.

In the case of Go, in goes verbosity, Nil pointers, poor concurrency and synchronisation primitives (or poor performance of the safe ones, leading to sync.Mutex everywhere anyway). Also Go prioritises local readability over global understandability which is a poor tradeoff for LLMs with limited context windows.

So the LLM generates absolutely monstrously huge amounts of very hard to review very likely incorrect code.

No thanks.

Rust > Go.

In goes powerful, terse type system. Strong correctness guarantees not just around memory and pointers but also data races. A tendency towards using the type system to model invariants instead of relying on procedural guards and runtime assertions etc. Producing denser code is an LLM feature, it increases context window efficiency. Similarily the typesystem takes something that the LLM can spend a bunch of thinking tokens on to create a powerful global constraint. This fixes the global reasoning/context problem by pushing it back onto the typesystem.

Depending on the quality of your robot you will get different quality of code out but the ceiling is much higher. With Go better robots don't help much, even the highest quality robots output insanely verbose Go. Sort of just like with people... sort of like the language was designed as a lowest common denominator tool...

For a seasoned Rust programmer the output probably won't be hard to review, it will be easy to look at the types and either say "yeah that should probably be correct" or "no robot, do better".

You simply can't actually review the output of the slop cannons with Go, there is too much, looking at a struct tells you almost nothing about how correct the thing likely is, etc. The tests don't help either because there is going to be 10x the usual amount of those too so trying to review those for correctness is the same Sisyphean endeavour.