7 ms·
I've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it. Go is an excellent language for LLM code generation. There exists a
by jryio 7mo ago
I've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it.
Go is an excellent language for LLM code generation. There exists a large stable training corpus, one way to write it, one build system, one formatter, static typing, CSP concurrency that doesn't have C++ footguns.
The language hasn't had a breaking version in over a decade. There's minimal framework churn. When I advise teams to adopt agentic coding workflows at my consultancy [0], Go delivers highly consistent results via Claude and Codex regularly and more often than working with clients using TypeScript and/or Python.
When LLMs have to navigate Python and TypeScript there is a massive combinatorial space of frameworks, typing approaches, and utility libraries.
Too much optionality in the training distribution. The output is high entropy and doesn't converge. Python only dominated early AI coding because ML researchers write Python and trained on Python first. It was path dependence, not merit.\
The thing nobody wants to say is that the reason serious programmers historically hated Go is exactly why LLMs are great at it: There's a ceiling on abstraction.
Go has many many failings (e.g. it took over a decade to get generics). But LLMs don't care about expressiveness, they care about predictability. Go 1.26 just shipped a completely rewritten go fix built on the analysis framework that does AST-level refactoring automatically. That's huge for agentic coding because it keeps codebases modern without needing the latest language features in training data or wasting tokens looking up new signatures.
I spent four years building production public key infrastructure in Golang before LLMs [1]. After working coding agents like everyone else and domain-switching for clients - I've become more of a Go advocate because the language finally delivers on its promise. Engineers have a harder time complaining about the verbose and boilerplate syntax when an LLM does it correctly every single time.
[0]: https://sancho.studio https://sancho.studio
[1]: https://github.com/zoom/zoom-e2e-whitepaper https://github.com/zoom/zoom-e2e-whitepaper
- TrueSlacker0 7mo agoA lot of those pros apply to c# as well. Which claude and gemeni both do very well with.
- bwestergard 7mo agoOr Java, for that matter.
- wiseowise 7mo ago> Python only dominated early AI coding because ML researchers write Python and trained on Python first. It was path dependence, not merit. Python doesn’t need dependence to prove its merit. There’s a reason why it is one the major programming languages and was top 1 for a while.
- fridder 7mo agoIt is easy to get started in. Some of the major warts it has, at least the ones that annoy me, revolve around deployment and management. Python packaging has been "fixed" at least 6 times
- treyd 7mo ago> But LLMs don't care about expressiveness, they care about predictability. I think this is true, but it misses a very key point. Go does an impressively bad job at designing APIs that are difficult to misuse, so LLMs will misuse them and will require also writing unit tests to walk through it, just to validate it used the libraries correctly. This isn't always possible (or is awkward/cumbersome) for certain scenarios like database querues. All of the reasons people argue Go is good for LLMs are more true for Rust. You and the LLM can design libraries to be difficult to misuse, and then get instant feedback from the compiler to the LLM about what it did wrong, and often with suggestions about how it should fix them! This also makes RL deriving from compiler feedback more effective. This allows the LLMs to reason more abstractly at larger scales, since the abstractions are less leaky (unlike in Go). The ceiling on abstraction screws you here, since troubleshooting requires more deep diving. It's the same reason Go projects become difficult for humans at large scales, too.
- ForHackernews 7mo agoRust is harder for the bot to get "wrong" in the sense of running-but-does-the-wrong-thing, but it's far less stable than Go and LLMs frequently output Rust that straight up doesn't compile.
- zozbot234 7mo agoIf you use the stable version of Rust, it's stable. There's a very strong commitment from the Rust folks on that specific point.
- J_Shelby_J 7mo agoThe only thing I see is the LLM not being aware of new features, so I have to specify the version rust.
- jen20 7mo agoHaving a .rust-toolchain file and the edition in Cargo.toml should achieve this - and both of these should be done anyway!
- gf000 7mo agoMost of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.
- EGreg 7mo agoI wonder what people will say to that. I personally think neither Go nor Java would be good for "agents". Better to have them sandboxed in WASM.
- r_lee 7mo agoWASM isn't a language you'd want to program with. you can't verify outputs nor is there any proper training data aside from examples and such
- gf000 7mo agoSandboxing is a completely orthogonal issue and WASM is probably not a good direct target for LLMs. Of course writing a language that compiles to Wasm is certainly a way, but you would have to sandbox also all the other tools that is used during development (e.g. agents can just call grep/find/etc).
- yaseer 7mo agoExcept that Go is a simpler, smaller language than Java. That's one of the key points in the post.
- fasbiner 7mo ago[flagged]
- slibhb 7mo agoLLMs are great with Typescript. But the fact remains that there are many different browsers and several runtimes (Node, Deno, Bun), each of which may have slightly different rules.
- fasbiner 7mo ago[flagged]
- Orygin 7mo ago> As someone familiar with those ecosystems, I'm have trouble envisioning the degree of operator error or imprecision that would cause this to be a problem. Because you are familiar with the ecosystem? Just like python devs saying it's normal to juggle with 3 package managers to run a simple script. Back to your original point: You also are biased by what you are used to use. Thankfully, I don't have to touch any JS project anymore, but oh god what a nightmare it is. Even just having CLI tools requiring constant updates to not break randomly during the day is enough pain that I won't touch that with a 10m pole.
- fasbiner 7mo ago[flagged]
- slibhb 7mo ago[flagged]
- fasbiner 7mo ago[flagged]
- CuriouslyC 7mo agoThis has been studied, Kotlin/C#/Elixir beat it handily.
- cryptos 7mo agoDo have any links to back this up? I'd be really interested.
- jmyeet 7mo agoI agree with most of this. You can learn Go syntax in an afternoon. Idiomatic Go takes a little longer but it just doesn't have the complexity footguns C++ does. But you can shoot yourself in the foot somewhat in Go. I'm talking about buffered channels, which are a mistake most of the time and a premature optimization almost all of the time, and you can explode your program with goroutines. But honestly it's not bad. Python is an interesting one because it's not always obvious the program is wrong or will fail, thanks to dynamic typing. But another problem is the Python philosophy since 3.0. Where once backwards compatibility was treated as almost sacrosanct, 3.0+ does not. 2.7 persisted for so long for this reason. But minor releases in 3.x make breaking changes and it's wild to me. I just wish Go had cooperative async/await rather than channels because (IMHO) cooperative async/await is a vastly superior abstraction to unbuffered channels in particular.
- wuschel 7mo agoI wonder: How does Rust and Haskell compare to Go when it comes to LLM code generation? I was always thinking that the compiler induced feedback loops could give these languages an edge? What would be the best language properties for LLM assisted coding?
- muyuu 7mo agoI'd have said the same a few months ago, but looking at the code quality that the SotA LLMs right now I have to say it's excellent and the problems they have are not with the language but with the subject problems, esp. when they require some complex design that isn't well documented beforehand. They seem to struggle with keeping a world model. Languages themselves, they run circles around humans. Now the case for Go or for other tightly standardised languages is that whatever the LLM produces, you're likely to be familiar with and make sense of its decisions. With C++, you can generally steer the LLM to refactor things in a certain way but it's extra steps. With Ruby it works surprisingly well too. I'm a lot less happy with their results in Lisp or in Bash/zsh for instance, and mixed results in C depending on what you give them to start - they just come with such random stuff. But it may be just a matter of training set and the relative free-form of those languages.
- truelinux1 7mo ago> 'The thing nobody wants to say is that the reason serious programmers historically hated Go is exactly why LLMs are great at it: There's a ceiling on abstraction. This lines up neatly with the kind of low‑abstraction systems I like running: 2021 HP PC with i7, bare‑metal‑ish, Crunchbang++, no desktop, openbox window manager. Boots to login in 17 seconds. Terminal front and center — local AI bare-metal inference, no wrapper, ffmpeg, ffplay, etc. Go’s “no abstraction ceiling” feels like the same preference at the language level: shallow stack, no indirection, and code that stays close to the metal. That’s why LLMs work so well on Go: it’s opinionated, predictable, and there’s usually one obvious way to do things. Personally, I've come to love a LACK of abstraction.
- jki275 7mo agoPreach. Golang is the best language there is for most workflows that aren't bare metal embedded or have real time requirements, and this is coming from a 20 year+ C++ dev.