Meanwhile I've switched to Go for some of my side projects which are now heavily coded by LLMs+agents. Nobody else is at risk of having to maintain these - but I did switch to Go because I feel it's a better fit for AI-generated code than other languages I've tried.
Having used LLMs on a large Go codebase, I’ve found that Go is especially difficult to work with due to how unopinionated it is about things that are trivial in other languages. I’d be really curious about what the positives are.
I've used Claude Code with a small Go project. The lack of some opinions makes it important to have some things codified in claude.md, such as telling it to running `go tool cover` to ensure claude is checking the code has test cases and writing new ones.
Positives for go is the relative lack of change in the language and libraries over the years since go 1.0. Less likely to need to correct ai-written code to use a newer version of a library with a different api. But there's limits to that in more obscure libraries.
The lack of opinion might benefit an LLM. Go is boring and verbose, not much room for cleverness. The code generated by AI or a human will probably be similar
I am mostly building stuff from the ground up and trying not to end up with a bunch of slop. I don't have experience dropping into a large Go codebase with it.
I have a strict requirement at this point to have a static type system. I need the LLM/agent to be able to leverage a type system at compile time, but I also need to be able to leverage the type system myself for guiding it, reviewing it, refactoring its work.
Of course that leaves a lot of options. I make small games and Go was not on my list to try initially - I've tried Lua with type annotations, Rust, C++, C, and C#. I've not yet tried TypeScript for games but would like to try it.
My observation has been that the less complex and less verbose the type system, the better the LLM has felt. That's a gut feel based on using these languages, I could be wrong about the cause - but based on that observation I opted to try Go and have been quite happy.
I was quite happy with C# before that but have been happier with Go.
Oh I also need a code-first game framework (not game engine) and would like it to target PCs, mobile, and hopefully web and have been happy with ebitengine whereas for C# I was happy with Raylib-cs except it seems quite difficult to target mobile.
I hate golang as language I just cannot get over how much I hate its syntax and I hate how verbose it is… however I do love that it is fast, compiles to a single binary and has a pretty nice standard library.
LLMs are the only way for me to make go usable.
The idea of “nice”, “high-quality” golang is an oxymoron. The very nature of the language makes it impossible to write nice high quality code… it’s designed by big tech to get college grads to pump out reams of garbage as fast as possible. LLMs are about as smart as college grads, so It was literally designed for LLMs to generate!
Yes it is a skill issue - I lack the skill to enjoy programming in a language with the ergonomics of something from the 70s. Golang is C with garbage collection
They’re complaining about mediocre AI-generated Go code, when Go was explicitly designed to optimize for mediocrity at scale. Rob Pike literally said they designed it for programmers who “are not capable of understanding a brilliant language.” The language deliberately trades expressiveness for simplicity so that huge teams of junior engineers can’t shoot themselves in the foot.
LLMs are basically junior engineers with perfect syntax recall. Of course they generate Go well, verbose, explicit, no clever abstractions. That’s not a bug, it’s the entire design philosophy.
For most of my work, TypeScript/Node is plenty fast and I can work fullstack in one language. When I actually need performance, Rust gives me control without random GC pauses. And if I need a GC language with good ergonomics, Kotlin on the JVM is miles ahead.
Go made sense in 2010 when Google needed to get thousands of new grads productive quickly. But those tradeoffs, sacrificing language quality for organizational scale - are exactly why it’s perfect for AI generation. You can’t have it both ways: you can’t design a language for the lowest common denominator and then be surprised when AI hits exactly that bar.
Maintaining bad AI code is the new maintaining bad offshore code.
Quality aside, it's also going to be a pain in general if all of the code "I" write is foreign to me when I go to look at it again later because it's not as familiar to me as if I'd fully originated it from the 25-year evolution of my personal experience.
Meanwhile I've switched to Go for some of my side projects which are now heavily coded by LLMs+agents. Nobody else is at risk of having to maintain these - but I did switch to Go because I feel it's a better fit for AI-generated code than other languages I've tried.
“Better fit” in what ways?
Having used LLMs on a large Go codebase, I’ve found that Go is especially difficult to work with due to how unopinionated it is about things that are trivial in other languages. I’d be really curious about what the positives are.
I've used Claude Code with a small Go project. The lack of some opinions makes it important to have some things codified in claude.md, such as telling it to running `go tool cover` to ensure claude is checking the code has test cases and writing new ones.
Positives for go is the relative lack of change in the language and libraries over the years since go 1.0. Less likely to need to correct ai-written code to use a newer version of a library with a different api. But there's limits to that in more obscure libraries.
The lack of opinion might benefit an LLM. Go is boring and verbose, not much room for cleverness. The code generated by AI or a human will probably be similar
I am mostly building stuff from the ground up and trying not to end up with a bunch of slop. I don't have experience dropping into a large Go codebase with it.
I have a strict requirement at this point to have a static type system. I need the LLM/agent to be able to leverage a type system at compile time, but I also need to be able to leverage the type system myself for guiding it, reviewing it, refactoring its work.
Of course that leaves a lot of options. I make small games and Go was not on my list to try initially - I've tried Lua with type annotations, Rust, C++, C, and C#. I've not yet tried TypeScript for games but would like to try it.
My observation has been that the less complex and less verbose the type system, the better the LLM has felt. That's a gut feel based on using these languages, I could be wrong about the cause - but based on that observation I opted to try Go and have been quite happy.
I was quite happy with C# before that but have been happier with Go.
Oh I also need a code-first game framework (not game engine) and would like it to target PCs, mobile, and hopefully web and have been happy with ebitengine whereas for C# I was happy with Raylib-cs except it seems quite difficult to target mobile.
I hate golang as language I just cannot get over how much I hate its syntax and I hate how verbose it is… however I do love that it is fast, compiles to a single binary and has a pretty nice standard library.
LLMs are the only way for me to make go usable.
The idea of “nice”, “high-quality” golang is an oxymoron. The very nature of the language makes it impossible to write nice high quality code… it’s designed by big tech to get college grads to pump out reams of garbage as fast as possible. LLMs are about as smart as college grads, so It was literally designed for LLMs to generate!
What do you recommend instead of Go?
Feels like a skills issue but happy to be wrong.
Yes it is a skill issue - I lack the skill to enjoy programming in a language with the ergonomics of something from the 70s. Golang is C with garbage collection
They’re complaining about mediocre AI-generated Go code, when Go was explicitly designed to optimize for mediocrity at scale. Rob Pike literally said they designed it for programmers who “are not capable of understanding a brilliant language.” The language deliberately trades expressiveness for simplicity so that huge teams of junior engineers can’t shoot themselves in the foot.
LLMs are basically junior engineers with perfect syntax recall. Of course they generate Go well, verbose, explicit, no clever abstractions. That’s not a bug, it’s the entire design philosophy.
For most of my work, TypeScript/Node is plenty fast and I can work fullstack in one language. When I actually need performance, Rust gives me control without random GC pauses. And if I need a GC language with good ergonomics, Kotlin on the JVM is miles ahead.
Go made sense in 2010 when Google needed to get thousands of new grads productive quickly. But those tradeoffs, sacrificing language quality for organizational scale - are exactly why it’s perfect for AI generation. You can’t have it both ways: you can’t design a language for the lowest common denominator and then be surprised when AI hits exactly that bar.
Maintaining bad AI code is the new maintaining bad offshore code.
Quality aside, it's also going to be a pain in general if all of the code "I" write is foreign to me when I go to look at it again later because it's not as familiar to me as if I'd fully originated it from the 25-year evolution of my personal experience.