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 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.
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.
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!
Feels like a skills issue but happy to be wrong.
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.
"Golang is C with garbage collection" I mean, Go isn’t C with GC - it’s C with:
- first-class concurrency (goroutines, channels)
- structural typing via interfaces
- a memory model safe enough for large-scale concurrent programs
- and tooling (formatter, linter, race detector, profiler) built in from day one.
That’s not just "C with GC." That’s decades of language design evolution deliberately integrated into a cohesive, batteries-included ecosystem that others have failed at (Typescript) or just haven't reached in their lifecycle (like Kotlin).
The Pike quote you’re half-remembering is about teams btw, not about "dumbing down" - Google had (and still has) thousands of engineers working on massive distributed systems. Go’s tradeoff wasn’t "let’s design for idiots" - it was “let’s design for readability, maintainability, and concurrency at scale.”
That’s why Go codebases from 2011 still compile cleanly today with minimal changes. Try that with your "ergonomic" TypeScript stack where half your dependencies are deprecated next quarter.
add-sub-mul-div•4mo ago
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.