The possibly ironic thing here is I find golang to be one of the best languages for LLMs. It's so verbose that context is usually readily available in the file itself. Combined with the type safety of the language it's hard for LLMs to go wrong with it.
Two or so months ago, so maybe it is better now, but I had Claude write, in Go, a concurrent data migration tool that read from several source tables, munged results, and put them into a newer schema in a new db.
The code created didn't manage concurrency well. At all. Hanging waitgroups and unmanaged goroutines. No graceful termination.
Types help. Good tests help better.
I fould golang to be one of the worst target for llms. PHP seems to always work, python works if the packages are not made up but go fails often. Trying to get inertia and the Buffalo framework to work together gave the llm trama.
I've found the same. To generalise it a bit, LLMs seem to do particularly well with static types, a well-defined set of idioms, and a culture of TDD.
I haven’t found this to be the case… LLMs just gave me a lot of Nil pointers