Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.
The killer feature of golang for LLM dev is the tooling.
forbidigo is what allows me to keep ambient config out of my app, and restrict file access to a small set of paths. The coverage tool has "nocover", so you can guarantee that every realistic path is exercised at least once ("100%" code coverage, which is not a marker for testing completeness, but rather for flagging code you forgot to test). Linting is really good as well.
The only thing I haven't found is something to enforce error handling. Rust is better for error paths because you're not allowed to ignore them.
At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages.
- For a language team, Go is a dream. The `go fix` tooling, AST/SSA packages, ease of reading and writing `go.mod` (go mod edit, etc), and various other "platform"-y features make modifying Go code at scale way easier than other languages.
It seems like developers who champion Rust have a knack for making up a load of nonsense about other languages. Claude Fable knows exactly how to handle things in Go; the most recommended concurrency patterns are mastered by the likes of Sonnet, Opus, or Fable, and most of the concurrency "errors" cited in the Uber article are the sort of mistakes a Go beginner would make, some bugs are fixed on major go version too (capture loop..).
Your experience may vary, but Rust code once compile generally always works. I don't have same confidence about go or typescript. And, I don't know much rust, but I do use lot of go in my work.
Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do.
Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting?
Think about what you are doing and choose appropriately. This was true before LLMs.
All I will say is that I agree with how this is framed, it says "an" ideal language. It doesn't say "the" ideal language. Many languages will fit within this scope and concept, Go is not all bad.
It's definitely more about the ecosystem than the language at this point.
I think the most important thing is how big the standard library is. Pulling in 3rd party dependencies is where I begin to lose a lot of faith with LLM authored code.
My expectation is that AI will give us a way to nicely quantify how productivity is impacted by choice of language. Because we can rerun the same request as often as we like and compare the results.
And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program.
The first tests I have seen seem to confirm this. One recent example:
Python is great as a dynamic language, but I find very few things about are easy to reason conclusively about because the state of the running program can be so crazy (has pros and cons). But it probably depends at what level you are working in python and how deeply you understand it. Type checking and linting help a lot to keep the truly crazy contained, but it's just fundamentally a very difficult system to trust. Not to mention working around the GIL is fairly inefficient.
This seems like a cope, if you aren't writing the syntax who cares and everything here is even better with a stronger type system like Rust, F#, Scala, TypeScript.
I hate the rust v go wars, its not x vs y is 'best'. Rather is x better than y and by how much for xyz project done by ABC corp in this era?
As a lead I'd love to use rust, I will put in the time on my own, my team won't or can't. They treat this like any other job they signed up to deliver value with what they know. For hiring not everyone has the talent pool and fund access to get the goat-ed engineers that congregate to tech hubs for maximizing their income. Then if you get through that cherry on top is LLM's are only as smart as you guide it to be. There is probably a staggering amount of ways to write 1 approach to business logic, you may not know the ideal pattern so you'll commit to a worse one on the company dollar.
I'm moving my team's projects slowly to go because, its easy to go from novice to advanced in terms of code writing,legibility and patterns. We also don't have deep ecosystem requirements to ts/python in most of our work. It is verbose but I don't mind that on token spend if it gets done with with validation/error handling which it obnoxiously enforces. It runs cheap, ecosystem is good for platform eng, standard library does a ton out of box.
I like Go but a couple of these "advantages" wash out when you add the scale and typical usage patterns of agents.
| Go is Readable / Go is Maintainable
It's true that Go, as a low-magic language, tends to be very same-y looking across projects, which is incredible for being able to reliably understand your dependencies' source code. And its tooling is world-class. I love this about Go.
But in practice I've found that, working in a monorepo with multiple teams, contributors that don't have cross-team legibility as a priority will just write SO much more code. And with business logic, often the fact that I can read the code on a line-by-line level doesn't matter if I don't understand the wider context to know how something might effect spooky action at a distance.
Pre-agents, I witnessed a fast transition from a codebase that I could mostly hold in my head to one where large swathes of it had been written and rewritten until they were unrecognizable to me. Now we have agents and, since they are still mostly not good at software engineering in-the-large, the process of knowledge debt accumulation (and ofc tech debt accumulation) in a codebase accelerates tenfold without concerted effort in the other direction. Go being easy to read does not intrinsically help with that.
I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go.
A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go--that's my argument.
I couldn't agree more, but the following sentence is a little biased:
> Gophers often speak of how they love that they can never tell who on their team wrote a particular piece of code—it all looks the same.
Multiple languages can have a degree of understabillity, but what matters most is context, because sometimes we need to code in a way to solve a specific problem like performance and it should be kept as is.
Another side subject I should add is about test coverage, although code is cheap, mainly because AI, guarantee that new changes to a stable code should continue to work as expected.
I worked on a few go projects with bad structure and some of them with really low test coverage (e.g. 8%), so part of the post resonates with me about we as software engineers should pursuit good architecture and other skills to allow long term maintenance.
I theorized this about a year ago and had a good amount of success vibing small game projects in Go.
I still think Go is a very excellent choice but I have switched to, of all things, AssemblyScript within a Rust host. I've been very happy with it - surprisingly so. Compile time is a major drawback of course.
I keep seeing these language specific proclamations, and they are annoying and reek of inexperience to me.
I’ve had a great time doing LLM assisted coding in Zig, and it seems comparable to the generic Typescript/React I do at work.
I don’t doubt simplicity and good PL design pay dividends, but everyone’s favorite language can’t be the silver bullet in our new LLM world. Things just don’t add up, and I keep seeing it for Erlang, Gleam, Lisp, C, Rust, Go, TypeScript, Python, etc.
And to pick on Go a little bit, I don’t think it has any unique qualities that make it better for LLMs, where I think you could make that argument for other modern languages that offer new features leveraging their compilers and enforcing more correctness guarantees.
I love the sleight of hand this blog post tries to pull off here. It doesn't matter than Go isn't fun to write because the AI is doing it now! Yeah so it sucked for the last twenty years? I know the main thesis is that Go is holistically good at software engineering so its weakness as a programming language is minimized. I've made a similar arguments that coding agents push the burden more into the other aspects of software engineering. But like, we all see what Google is doing here right? They want to declare that the rules have changed so Go's weakness transmutes into a strength. I'm also not buying it.
I wouldn't say Go is IDEAL for AI coding, but it certainly has the case for one of the best programming languages that currently AI uses. Go definitely has its share of problems for human authors because it's so verbose and boilerplate heavy, which means it's less of an issue with LLMs than it is for human coders. Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, it only seems to get in their way, and they spend more time fighting Rust's infrastructure than writing code.
The biggest barrier to Go adoption seems to be Google's internal resistance to migrate C++/Java code bases to Go and refusal to admit that Go is an amazing application programming language and not really a systems programming language for bare metal OS/driver work. For example, one of the biggest barriers to Fuchsia adoption has been Google asking people to commit to Dart, I think Fuchsia would have fared a lot better as an Android successor/alternative if the official applications programming language just been Go.
(BTW Carbon isn't even a real programming language, it's still somehow stuck at 0.0.0.0 after 4 years of development which is honestly insane.)
Oh, so, little bit of self-promotion: if you like Go but is frustrated with the ergonomics of it, I would ask you to try out the programming language I developed, Oct, for LLM coding which you can kinda think of as my attempt at making Kotlin for Go's Java: It uses a codegen compiler and compiles to a plain Go binary, so it runs on everything that Go runs, and there is a lot of extra features as well: Rust style exhaustive tagged/payload enums/`match`, C#'s immutable records updated with `with`, exhaustive error handling easy parallel concurrency, xUnit.NET style unit test harness, TypeScript style compile time constraints, F# like SI unit system, Go code generation metaprogramming, etc. Would love to have some Go experts here on HN take a gander at it and provide some feedback.
130 comments
[ 0.22 ms ] story [ 18.3 ms ] threadforbidigo is what allows me to keep ambient config out of my app, and restrict file access to a small set of paths. The coverage tool has "nocover", so you can guarantee that every realistic path is exercised at least once ("100%" code coverage, which is not a marker for testing completeness, but rather for flagging code you forgot to test). Linting is really good as well.
The only thing I haven't found is something to enforce error handling. Rust is better for error paths because you're not allowed to ignore them.
At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages.
Two additional notes I'll add:
- Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://google.github.io/styleguide/go/. edit: Sorry, I forgot to add: we give these resources to AI agents and they use them to produce even better Go code.
- For a language team, Go is a dream. The `go fix` tooling, AST/SSA packages, ease of reading and writing `go.mod` (go mod edit, etc), and various other "platform"-y features make modifying Go code at scale way easier than other languages.
Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting?
Think about what you are doing and choose appropriately. This was true before LLMs.
Are you having fun? Chose LISP then
I think the most important thing is how big the standard library is. Pulling in 3rd party dependencies is where I begin to lose a lot of faith with LLM authored code.
And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program.
The first tests I have seen seem to confirm this. One recent example:
https://danluu.com/pl-tokens/
As a lead I'd love to use rust, I will put in the time on my own, my team won't or can't. They treat this like any other job they signed up to deliver value with what they know. For hiring not everyone has the talent pool and fund access to get the goat-ed engineers that congregate to tech hubs for maximizing their income. Then if you get through that cherry on top is LLM's are only as smart as you guide it to be. There is probably a staggering amount of ways to write 1 approach to business logic, you may not know the ideal pattern so you'll commit to a worse one on the company dollar.
I'm moving my team's projects slowly to go because, its easy to go from novice to advanced in terms of code writing,legibility and patterns. We also don't have deep ecosystem requirements to ts/python in most of our work. It is verbose but I don't mind that on token spend if it gets done with with validation/error handling which it obnoxiously enforces. It runs cheap, ecosystem is good for platform eng, standard library does a ton out of box.
| Go is Readable / Go is Maintainable
It's true that Go, as a low-magic language, tends to be very same-y looking across projects, which is incredible for being able to reliably understand your dependencies' source code. And its tooling is world-class. I love this about Go.
But in practice I've found that, working in a monorepo with multiple teams, contributors that don't have cross-team legibility as a priority will just write SO much more code. And with business logic, often the fact that I can read the code on a line-by-line level doesn't matter if I don't understand the wider context to know how something might effect spooky action at a distance.
Pre-agents, I witnessed a fast transition from a codebase that I could mostly hold in my head to one where large swathes of it had been written and rewritten until they were unrecognizable to me. Now we have agents and, since they are still mostly not good at software engineering in-the-large, the process of knowledge debt accumulation (and ofc tech debt accumulation) in a codebase accelerates tenfold without concerted effort in the other direction. Go being easy to read does not intrinsically help with that.
A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go--that's my argument.
Prefer standard Go libraries and tools.
80% of the time I can get by without external dependencies (outside of Go's X repository)
> Gophers often speak of how they love that they can never tell who on their team wrote a particular piece of code—it all looks the same.
Multiple languages can have a degree of understabillity, but what matters most is context, because sometimes we need to code in a way to solve a specific problem like performance and it should be kept as is.
Another side subject I should add is about test coverage, although code is cheap, mainly because AI, guarantee that new changes to a stable code should continue to work as expected.
I worked on a few go projects with bad structure and some of them with really low test coverage (e.g. 8%), so part of the post resonates with me about we as software engineers should pursuit good architecture and other skills to allow long term maintenance.
I still think Go is a very excellent choice but I have switched to, of all things, AssemblyScript within a Rust host. I've been very happy with it - surprisingly so. Compile time is a major drawback of course.
Of course it can’t just be simplicity, it has to be “opinionated” simplicity. Rolls eyes.
I’ve had a great time doing LLM assisted coding in Zig, and it seems comparable to the generic Typescript/React I do at work.
I don’t doubt simplicity and good PL design pay dividends, but everyone’s favorite language can’t be the silver bullet in our new LLM world. Things just don’t add up, and I keep seeing it for Erlang, Gleam, Lisp, C, Rust, Go, TypeScript, Python, etc.
And to pick on Go a little bit, I don’t think it has any unique qualities that make it better for LLMs, where I think you could make that argument for other modern languages that offer new features leveraging their compilers and enforcing more correctness guarantees.
The biggest barrier to Go adoption seems to be Google's internal resistance to migrate C++/Java code bases to Go and refusal to admit that Go is an amazing application programming language and not really a systems programming language for bare metal OS/driver work. For example, one of the biggest barriers to Fuchsia adoption has been Google asking people to commit to Dart, I think Fuchsia would have fared a lot better as an Android successor/alternative if the official applications programming language just been Go.
(BTW Carbon isn't even a real programming language, it's still somehow stuck at 0.0.0.0 after 4 years of development which is honestly insane.)
Oh, so, little bit of self-promotion: if you like Go but is frustrated with the ergonomics of it, I would ask you to try out the programming language I developed, Oct, for LLM coding which you can kinda think of as my attempt at making Kotlin for Go's Java: It uses a codegen compiler and compiles to a plain Go binary, so it runs on everything that Go runs, and there is a lot of extra features as well: Rust style exhaustive tagged/payload enums/`match`, C#'s immutable records updated with `with`, exhaustive error handling easy parallel concurrency, xUnit.NET style unit test harness, TypeScript style compile time constraints, F# like SI unit system, Go code generation metaprogramming, etc. Would love to have some Go experts here on HN take a gander at it and provide some feedback.
https://github.com/yuechen-li-dev/oct