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.
This is true. I'd like metrics on this though. It could be that LLMs find go easier so they end up writing better code and rarely hitting static errors like a human would in rust. IT could be through scientific measurements that the benefits of static checking could be negligible for LLMs.
No way to know until someone does the science on this. Until then it's just people saying that more static checking is better. But I do think, anecdotally, python is horrible for LLMs.
True but if the reviewer doesn’t have an intimate understanding of rust then the fact it can’t “slop” is no different than unreadable slop.
Go is simple, no “magic” marcos or meta programming even with just a little programming in any language it’s not hard to understand what the go code is doing.
That's simply not true. I wrote a piece of software in Rust that is non-trivial, robust, 50k lines of code, and 100% LLM generated, used by four people productively with only one or two minor bugs in the past two man-months
question did you review the code or did you test it was working? these are different things. and if you did review it, could an engineer without deep Rust experience have reviewed it just as effectively?
I have no doubt that you can get a LLM to write working bug free code in any language but that is not the topic of the article or my comment.
I have an agent read most of the code as well. The agent explains things to me in plain english.
The default sentiment is humans should read code it's more progressive and a leap of faith to start giving that up.
Obviously, I get why you feel humans still reading code is important, but if you look at the progress of AI for the past couple of years, that gap is closing. The trendlines speak of a future where it becomes less and less important.
This was exactly what happened with writing code. Now most people don't write code.
I don't read all of the code produced by my agents any more, but I like to reserve the ability to do so if I run into a particularly confusing bug, or for any code that's security adjacent.
I use LLM daily to write code for and "with" me, I also write code without LLM. Most people I come across mix it up. A few do it all by hand, and equally few all by LLM I would say. Is that just in my corner of the world?
The trendlines are moving away from this. It's all happening so fast that not every company is on the same page, but from what I see we are quickly converging on not writing anymore code.
My entire company for example does not write a line of code. We manage agents and that's it. Many, many, many companies and people are already doing this.
I have a few utility go codebases that I simply do not read at all - but it's internal tooling so there's literally no point in reading it when the LLM can modify it in seconds to do new things.
For whatever reason, maybe not even logical ones, Go repulses me. I don't know why exactly, I like the idea of Go, but the aesthetics rub me wrong.
I think it's the use of pointers and "if err != nil {}" error handling spam. It reads as a highly compromised imitation of Python and C rather than a solid execution of some other idea.
Rust is not the most beautiful language out there but it doesn't trigger any such reaction for me. The ? operator and "match", which I use constantly, more than compensate for some of the sigil noise which I barely need to look at much less write most of the time. So Rust wins on that comparison for me.
The "func name() -> retval" syntax also grew on me. I like the fact that Python type annotations copied that approach, and C-style declarations look ugly to me now. Same with C-style /* */ comments.
Because Go is kind of a Steampunk design. The creators collectively ignored decades of PL developments. What that nets is kind of a C without sharp edges, but can't be used where C can.
Rust is definitely jarring to look at, in the same way that decoding some strange C declaration can be, in ye olde days when you had to float all this context in your mind while doing work. But with modern tooling who cares: "explain this lifetime to me"
For me it's mainly the if err != nil {} stuff and the fact that everything is package scoped (C-style enums and constants).
You can pretty clearly see the limitations if you read, for example, the type of code the Protobuf compiler generates when trying to compile Protobuf/gRPC enums or structs into the way-more-limited Golang type system (this is despite the two being designed to work together). And it could really do with algerbraic data types and other modern programming language features.
Also the type system does have a couple weird behaviors that seem straight out of JavaScript. Like the difference between struct and interface nil for example:
```
var buf *bytes.Buffer = nil
var out io.Writer = buf // now out is nil
if out != nil {
// This block will execute because out is not nil
out.Write([]byte("crash")) // This line will crash because out is nil
}
```
Many things about the language almost seem to be designed to simplify the implementation of the compiler rather than to benefit the developer experience.
I'll qualify this from my POV (which may be different than GP's).
Go's historic maintainability strong suit has been its simplicity and consistency. The syntax is, relatively speaking, lightweight, the language invites complexity through composition, and information density for any unit of code is typically quite low (which isn't necessarily a bad thing).
In my opinion, though, these are all drawbacks, and Rust addresses all of them. It's syntactically and semantically much heavier, leading to its oft-maligned steep learning curve. It has, uniquely among the major languages, I think, a syntax for expressing variable lifetimes (with its own unintuitive semantics). It stuffs lots of abstraction into a hodgepodge of terse semantics and punctuation.
It sucks to read, until you get really used to it. Then it tends to read really quickly, and, at least for me, it's easier to reason about a conceptually-broad piece of logic if I don't have to jump between different locations in a file, a module, or a package to do it.
With Go, I find it more difficult to get into a flow state, and easier for my eyes to glaze over when looking over large diffs.
It's not lost on me that these are purely subjective arguments, though. My preference remains with Rust, and that goes back to before I used LLMs.
I'm also aware that Go is very prescriptive about how you write it; it's explicitly opinionated, and Rust doesn't have that. It means that most Go code bases will look more alike. I consider this an anti-feature; I believe code should be able to conform to the problem space or product and a good team will find the best way to do that.
Yeah, Go is easy to read in the same sense that English limited to its ten hundred most common words is easy to read (https://xkcd.com/1133/). Whether that nature is helpful or harmful to LLMs is an interesting question.
It seems very obviously detrimental to me (in the exact same way it's detrimental to people); e.g. use proper jargon with an LLM and you find it is suddenly an expert. The LLM has no trouble at all perfectly fluently using macros or monads or whatever thing people are afraid of to write simpler, more concise code that directly expresses the business logic in a fully type safe, high performance way that the compiler can introspect for even more information. Go of course lets you do none of those things and can only ever be used for "beginner code" by intentional design.
It's a matter of expressiveness, Rust expresses more.
E.g. make a table that's 3x3 is easier to read (Go), but the equivalent line in Rust would also include material, angles, height, etc. because the type system encodes much more information.
Though I always found Go to be significantly harder to read than Rust. Sure Rust has some crazy syntax at the edges, but Go makes it very hard to know where imports come from (and thus what they do), and the imperative style + lack of clarity about mutability makes code much harder to reason about.
Might be unpopular, but agents write too much code for humans to read in any meaningful time frame. Using agents to generate code to then require humans to slowly consume it defeats a lot of the speed you gain from AI.
I my self and teams members are slowly reading less code and requiring agents to prove things work the way we want in other ways.
I agree, but this doesn't justify anything. Saying rust is better because it "just is" won't convince anyone. I'd like to know why you think it's better.
Go doesn't have memory safety issues because of its GC, while Zig has UB problems. Zig might have slightly better performance, but I don't think choosing a language without memory safety is a good idea
Rust makes you solve many of your problems upfront, which is a nice feedback loop for using with an LLM. Go does much of this too, but I feel Rust is more experessive and takes the frontloading a bit further.
idk. In my experience the build/compile experience has been far worse esp for fast iterating. Even concurrency models did not seem as intuitive as Go's. Im no systems expert - have deployed practical and performant distributed systems though.
Personally, Rust or Typescript both happen to be better than Go for me. TypeScript has better type-safety and tooling for user-facing apps, and Rust has better type-safety and tooling for algorithmic stuff or stuff that needs to run fast.
Probably both, but I have to add: I agree with the post. I've done a ton of agentic development using Go over the past 6 months, and it hasn't let me down. You may ask "why not Rust, or Zig, or ____?" The reasons boil down to this:
- There's a lot of Go code out there which the models have seen, so they know how to write it.
- Go has an exceptional standard library, so you don't need to drag in 100 dependencies to create a simple web app.
- Go compiles extremely quickly for incremental builds, which really matters when agents are building and running tests constantly.
- Go has a goldilocks blend of performance and safety. You get a good type system and excellent runtime performance without forcing the model to spend cycles fixing Rust lifetimes or Swift concurrency issues for a marginal incremental gain.
- Go is relatively stable, so the LLM's memorized knowledge is still pretty fresh (as opposed to something like SwiftUI, where the API changes rapidly).
I don't think Rust is particularly worse than Go in any of these respects.
- LLMs have clearly been trained on a lot of Rust as well
- Compile times are counterbalanced by strong compiler with excellent error messages, and "cargo check" can catch many issues without a full build.
- If you're willing to accept Go levels of performance from Rust, there's nothing preventing you from using copies and clones rather than borrows, which makes most code dead simple.
- For most major dependency types, there exists a clear "winner" in terms of community adoption, so the fact that it's not in the stdlib is not that problematic.
Rust compiles way slower in my experience. This is a major problem because ais need to recompile many times especially when it keeps running into borrow checker problems.
With golang, all borrow checker problems go away. This is a good trade off if your app is not cpu-bound, which most are not. If you need every last drop of performance then rust is a better choice of course.
However, I have run into a few cases of runtime null crashes in go.
> and "cargo check" can catch compile issues without a full build.
You only have to compile when you actually want to test the behavior, which tends to be right on the first try more often as a result of the strict compiler.
I do not think "good error messages" is an even trade for "fast compile times." What happens is the LLM catches the error, then may hit another error, and try again. This leads to more tokens and more latency, and then after all that you have a longer compile time.
With that said, I have not done an extensive amount of agentic development in Rust, so maybe I just don't have the reps to compare fairly.
It's less that the error messages are just "good" with Rust, it's that more stuff gets caught at comptime, and many of them can be autoremediated by cargo fix or the compiler itself says exactly what should be changed.
Nothing costs more tokens than an LLM trying to debug errors caused at runtime which doesn't map well to it's "intelligence" compared to what Rust provides
How would you compare it to C#?
Stable-ish
There's a lot of documentation and plenty of stablished patterns, so LLM can produce it no sweat
Everything and the Kitchen Sink
Performant, and safeish, even if not null safe
Yeah, C# is probably the closest direct comparison. I like that Go emits a simple binary, whereas it seems like that needs to be configured with a .NET project. Probably just a matter of taste/preference!
In my experience C# works out pretty good. I wrote a project in Go, it mostly went well, but it had weird bugs and the AI struggled to solve them. Rewriting in C# seemed a lot more robust. I use it a lot these days and I find the AI rarely has any issues with language/framework and you get pretty good results.
I wouldn't call Go's type system "good". It's basic or less. It's sound, at least (in the presence of data races), but that is the case (or mostly the case) for most programming languages.
Fair—though SwiftUI has influenced/required new Swift features like Result Builders. I've found generating Swift to be a mixed bag. The LSP consistently reports stale errors which the model has to ignore, handling strict concurrency correctly can lead to ugly workarounds or huge refactors, the documentation for Apple's APIs aren't accessible to agents, the list goes on.
Agreed. Felt like a AEO / or GEO (generative engine optimization or whatever the field term is these days) puff piece. Seems too verbose for most people to bother reading.
Gemini overindexes on Reddit answers. It'll give me clearly wrong info just because one person on Reddit said it. People are probably already bot-spamming Reddit for this exact reason.
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.
"The only thing I haven't found is something to enforce error handling."
errcheck, generally as manifested in golangci-lint, ensures you can't forget to do something with them. It would be odd for you to know about forbidigo but not errcheck as the former is much less widely known; is there something that errcheck doesn't do for you?
It's worth pointing out that "discard this error on purpose" is a legitimate form of error handling, so "enforce error handling" can't really constitute banning that. That's not a Go statement, that's just true in general... it is sometimes valid to just ignore the error, because there's nothing useful to do with it anyhow. I would agree the ignoring should be explicit, but it is an option.
Poor defaults break systems by a thousand cuts. They seem to make sense when designing the language (more convenient, less typing, etc), but then they very quickly become liabilities as project complexity increases. Go made the mistakes of mutable-by-default and silent-error-dropping, but their cyclical-import-forbidding was a good call.
It isn't entirely clear to me how that relates to what I said. errcheck prevents you from dropping errors or catching them but then overwriting them before doing anything else. There's a flag you can twiddle to throw a lint error on using underscore to ignore an error, too, if you're really perturbed about that. I have a personal rule to always have a comment explaining why it's OK to do that that predates AI coding rules. This seems to meet your criteria.
Maybe we are using different tools (or we've set it up wrong) but I'm consistently surprised at how slow Go's linting is (using golangci-lint). Takes nearly 5 minutes on our codebase after any change (which means I just don't run it locally or in-editor). It's remarkable how poor the experience is after using tools like Python's Ruff (instant) or Rust's Clippy. I'd have expected a fast, default setup that I could tune.
Event JS's Eslint, which runs in actual JS, takes 21 seconds for a full sweep (which I don't normally run, since the in-editor hints are so fast)
It's surprising, because so many of Go's dev tools are so well thought out!
The issue I always had with Typescript, was that LLM's like to find the easiest way to get a job done on a micro level (they seem to like to find the hardest design patterns to implement on the macro level tho, but language agnostic). What this means for Typescript, is unless you place guardrails everywhere, they'll cast their way out of a compiler problem with as any, or as unknown and then casting later. You either end up with readability issues, or runtime issues leaking out.
Might be a skill issue, but I got frustrated with it on new projects constantly.
I haven't seen that too much, but I do have guardrails. I use Deno and run 'deno lint' as part of the build. It doesn't allow 'any'.
Also, I tend to ask planning questions, like "how would you implement this" and "what would the API changes be?" I'm picky about API's. Lately I've been using Deno workspaces (multi-package repos) and tell it when to make a new package or a new entrypoint. Maybe that helps?
If I just ask for features and don't look at the code, it will definitely make a mess, though. (A working mess, but it takes a while to refactor my way out.)
They're improving but you definitely need both a strong AGENTS.md and also usually many LLM passes (one for implementing a feature, another one for code quality, large passes every now and then for major refactors, etc).
That's not really a typescript thing though, just an LLM thing.
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.
I agree very strongly. There's no debate about things that have 1000000 permutations in other languages. e.g. The correct format can always be checked by `go fmt` with no real config options. the end.
This back-and-forth is a good example of why Go benefits from having a centralized linter. And uv isn't the official Python package manager even though it should be.
I don't get why this is a big issue. This isn't some recurrent decision to be made. It's something a lead decides once and the project follows. That's it. Many companies have style guides anyway (eg Google[1]); the choice of a formatter is much simpler.
Because at some point you have to interact with some other team or project that made a different decision. And whatever you picked might fall out of favor and lose support. There's already a graveyard of Python type linters, including Google's pytype.
Especially the uv thing. You clone some non-uv git repo that has no pyproject.toml and you don't know what to install. Maybe has requirements.txt but it's partially wrong.
If I do the simplest possible thing that isn't a single word, by highlighting "opinionated formatter these days (e.g. Black)" and clicking search, I get the right result. I also get the right result for black formatter, and I get the right result if I yolo the entire comment as my search.
> ...And so many languages have an opinionated formatter these days
The crux of gp's post is for Go, there is no debate as 'go fmt' is the only one that matters. Black is great, but some people prefer Ruff, leading to ...debates about which formatter the team/org should use. Go's batteries-included philosophy makes those discussions moot on so many levels beyond formatting.
It's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas. People with no other substantive contributions use formatting as a beard.
The first one to choose it (whatever it happens to be) wins and that's the end of it. If it isn't the end of it you've got a talent issue.
I have a question: why do you think Go is better compared to other languages?
After all, learning a new language takes a lot of time. While basic syntax is common and quick to pick up, mastering a language's specific mental model requires a significant time investment, which is why I've used Go before but never seriously.
My interest was piqued recently when I heard about TypeScript tooling being ported to Go, and I know it is incredibly fast. However, where do the results claiming that AI agents generate superior Go code actually come from? Is it a fair, apples-to-apples comparison?
Since Go is a very small language with only 25 keywords, the way you write code is extremely standardized. Because of this, I would assume it naturally produces a lot of excellent best practices and conventions, but I'm not sure if there are actual, direct code examples proving this
Ah, I see. I misunderstood.Is the report from an internal source, so it can't be shared? If not, I'd appreciate it if you could send me a link so I can look into it too.
You are being downvoted but I think this is correct. I doubt Netflix is really doing a double blind RCT on which languages produce better AI pull requests. How would that even work, have two versions of each service in different languages?
It's anecdata and maybe, MAYBE, a spreadsheet. Or a Google Form somewhere.
Exactly. I only count opinions from people who have deeply used the two langs they're comparing and can express what exactly was wrong with one of them for their task.
>> why do you think Go is better compared to other languages?
> I didn't say that. :)
I call this the Go paradox.
I simultaneously believe we should reach for it 80% of the time to solve common collaborative problems. And being a poorer language is actually an asset in these cases.
However, in doing so, we get rusty lose our fluency in more expressive, perhaps even better languages.
How does that work? Are they generating the same project in different languages and comparing the results? What does it mean for the code to be "better"?
Go is really amenable to being used to write code by LLMs. New code takes time to pick up, but the LLM is a quick study.
In my opinion, it has little to do with the speed of the language. The large quantity of source code to train on is quite helpful, but I think it's something else.
There are three things that I think make it well suited to LLM authorship -
1) static typing and a quick compiler - a variable can't change type after it's declared (unlike Python) makes Go more robust compared to dynamic languages. You (almost) always know what the type of a variable is. And the quick compiling with hard-stop errors means that the LLM gets a solid signal for each round.
2) It's quite opinionated, syntactically. There is generally one way that Go lang code is supposed to look. That means it's pretty easy to read as well as write. The lack of things like operator/method overloading make it an easy language to reason about.
3) the stdlib and limited dependencies. Dependency trees tend to be shallow, and because of the static linking (by default), you can generally be confident that what you wrote will run.
Uber reported that their Go code has quantitatively more concurrency bugs than code in other languages, and while to me it seems obvious from looking at Go's concurrency model, this is backed by actual data. Is there any quantitative data to back the claim that Go is better in an LLM based workflow than another popular language?
Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code.
As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. Antithesis found some more bugs in HashiCorp's Raft implementation recently[0]. I'm sure etcd still has some kicking around.
Maybe this is a "don't throw the baby out with the bath water' problem but the general evolution of Go has been lackluster. I reach for Rust, Zig, and modern Java instead depending on the specific needs and constraints.
You're misreading what I said. I didn't say other languages don't have buggy Raft/Paxos implementations, just that Go is yet to yield a single correct one.
The intersection of the set of Raft libraries Antithesis tested and all Raft libraries in existence do not fully overlap. I personally have worked on multiple proprietary ones that Antithesis would not have access to.
But they are misreading what I said. My original post is clearly about Go. What they wrote is also ambiguous.
> The antithesis author states:
> "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft"
What are they implying by citing that? That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people make Raft implementations for fun and learning. Again, Go does not have a single Raft/Paxos implementation that is rock solid. I have seen many in C++, Java, and Rust that are doing tens of millions of requests per second in production for over a decade.
Is their point that Go is not the only language with this problem? My post already points out the track record is that Go is the problem for writing correct code in highly critical domains.
If we rely on their evidence alone, it suggests nobody has ever made a correct implementation, so we learn nothing about Go. "Go has yet to yield a correct one" is an extremely misleading way to present evidence that says the same thing about every language.
The only way this becomes useful for comparing languages is if somebody gives evidence of correct implementations in other languages. You're claiming they exist but with no evidence and suggesting they're secret. How do you know those don't have bugs? Did any concurrency bug experts do extensive testing on them? And can we disprove secret Go implementations of the same quality?
> That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people make Raft implementations for fun and learning. Again, Go does not have a single Raft/Paxos implementation that is rock solid. I have seen many in C++, Java, and Rust that are doing tens of millions of requests per second in production for over a decade.
No, they are citing that every Raft implementation that Antithesis has tested has bugs. The etcd implementation you note in go that has bugs also does tens of millions of QPS and is over a decade old. How are you confident that the proprietary implementations that presumably haven't been fully tested don't have subtle bugs that don't show up in practice?
You're being very mealy-mouthed, even here, it reads as "The pre-eminent Go implementation can't even get it right" and yet the implementations Antithesis tested in Rust are apparently people's random "fun and learning" projects, nothing serious, and certainly not all the proprietary implementations that you've used that are all correct.
Java has so many excellent concurrency containers, plus robust 3rd-party containers like JCTools. It puzzles me why Go communities do not offer such containers.
No thread/goroutine handles for fork/join handling from "outside", and no generics for many formative years that influenced tons of habits, then significantly weaker generics (improving very soon[1]), have all led to most concurrent code to be very "intrusive" - you create bare threads and add bare synchronization primitives (or nearly) by hand inside the threaded code to make it concurrent. `errgroup` is as far as a lot of code goes, in terms of sophistication.
Java leans heavily in the other direction: a lot of concurrency is added externally, without changing existing code, often in very declarative-flavored ways.
E.g. Future<T> serves as a foundation for a ridiculous amount of stuff, while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics.
There are very obviously lots of counter-examples for both langs (`synchronized`, rill in Go, etc), and I expect Go to become more Java-flavored in time (it already has moved this direction somewhat, and 1.27 will enable a lot more). But I think it's a fair summary of broad ecosystem habits.
"This Raft library is stable and feature complete. As of 2016, it is the most widely used Raft library in production, serving tens of thousands clusters each day. It powers distributed systems such as etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Project Calico, Flannel, Hyperledger and more."
I don't care for Go myself (especially its concurrency model, which is a total dinosaur in a world where we have structured concurrency) so I'm not saying this to support my favourite language, but:
etcd has had numerous liveness and safety bugs, with one happening as recently as December of 2025. Would you consider that a correct implementation?
You may be interested in knowing that the largest managed Kubernetes service in the world (AWS EKS) ripped out etcd for in favor of their homegrown consensus service for large scale EKS clusters: https://aws.amazon.com/blogs/containers/under-the-hood-amazo...
etcd is some of the most amateur code I've ever seen, despite being one of the oldest and presumably most mature "infrastructure" projects written in Go.
goBGP is arguably even worse.
I don't have a third place in mind that's even worth mentioning relative to these two.
Sorry to pile on, but yeah, I wanted to use etcd during 2021 and 2022, around v3.5, but etcd had serious issues including silent data corruption. If you are curious, ask gemini flash "there were a number of etcd releases years ago where it seems a new wave of developers came in and started breaking everything"
I'd like to know what you base your statement on that the Raft implementations in etcd or CockroachDB are incorrect. Your original paper does not mention those implementations, so where does that claim come from?
Having run a fleet of 100s of etcd clusters for 10000s of rps, and the fact that upstream runs tests similar to antithesis and recently partnered with antithesis [0], and jepsen has tested it long ago as well [1]. Etcd's raft algorithm is fine. Someone even did a TLA+ proof on it in the last couple years[2]. Yes there was a correctness issue a few years ago but otherwise the person you're replying to doesn't know what they're talking about. Also those bugs have nothing to do with the raft implementation, but instead the state machine implemented on top.
The raft algorithm works and if you implemented a less complex state machine (like using a simpler kv store that doesn't need global event ordering via revisions and watches) it would work. That's what antithesis said they did to test the raft algorithms in the other article linked
"there was a correction issue" is downplaying it. Etcd is truly the worst example of Raft.
Etcd corruption and loss of quorum is extremely common in practice and the GitHub issues sit for years. The design is simple, the performance is modest, yet it still has still never been reliable, despite being marketed as so. I can't speak to whether this is specifically due to their Raft implementation, but I'd argue the entire codebase is over-engineered and questionable.
Their lock, leader election, sessions, and leases are all awful and I'd never recommend anyone to use those. But as a strongly consistent kv store and if you need the watch mechanics, its useful. It has its place and that's mostly being used by kubernetes.
Surely the King is doing it, so that must be the correct way. Look, the King even wears clothes and is totally not naked at all.
That the world runs on Kubernetes is no qualitative statement about the correctness of its Raft implementation. You can say that it's clearly good enough to not matter most of the time, but that is a different statement.
No matter who you look at, they're just cooking with gas like you do, and they can make mistakes in just the same way.
Now; I'm only attacking your argument. I do neither know nor particularly care about the correctness of that implementation itself. There's been better refutations of the claim you replied to in other answers anyway.
To combine both TFA with this comment: I find that LLMs are ~fine at generating/editing gocode, or at least as ~fine as they generate most mainstream languages.
But good god, the second it gets to anything concurrency-related, it just loses its mind. As much as it's gotten vaguely ok to try to let the agents loose on some bits of the codebase, they simply can't even do table stakes stuff with the kinds of concurrency you see in real life.
My experience as well. LLMs also struggle with Rust's many abstractions and offerings but you can know that if it compiles it is data race free and work with the LLM to use better abstractions over time.
Zig is also good at this but requires more up front design (thread-per-core, static allocation, etc.) and consistent checks to verify rules are followed.
C/C++ has "compiles but may have undefined behavior". Golang has numerous "compiles but has incorrect behavior" (normally known as footguns). Meanwhile with Rust, if you get past the compilation step, bugs become much much fewer. (You can still have memory leaks, but those are easily traceable).
It seems like claude code can code Rust pretty well with Opus, and I've started moving codebases away from Golang to Rust at work with Opus. Spin up an LLM and it cranks on it for a while, and as a benefit, I get easy apis to build on with other languages.
And that's the problem with Golang really, not that it's a bad language per se (all languages have footguns), but that the language interoperability story is terrible. Meanwhile Rust and Python/C/C++ go great together like peanut butter and chocolate. And I love it.
Correct concurrent code is mind-bogglingly hard even for seasoned veteran humans (and don't get me started on distributed programming...), so it's hardly surprising that LLMs with their limited context windows into the code have a hard time writing correct concurrent code
I wouldn't be surprised if Java has a much better experience here. After all, java.util.concurrent has many great implementations, and Java's `record`s are immutable, as are it's upcoming value types.
It's pretty easy to get yourself into trouble with channels: deadlocks, send on closed, channel leaks, deadlocks "fixed" thoughtlessly with arbitrarily-sized buffers, etc.
In my experience, shared memory instills the appropriate fear and caution, while the apparent simplicity of channels encourages novice Go programers to take on concurrency projects beyond their abilities and without due care. Been on both the submitter and reviewer side of that plenty of times in 10 years.
You seem to be implying, based on the rest of the thread, that Go has some sort of special defect that keeps it from implementing Raft correctly. But the "special defect" that Go has is that it in practice implements the same primitives in practice that almost every other mainstream language does, rather than implementing some sort of super-safe concurrency primitive like Erlang or Pony, or being immutable like Haskell. And even those things are of only marginal utility for Raft, preventing some local issues, but the hard part of Raft is more in the logic and the communication, for which none of these languages have any sort of special support or anything that will particularly help you get it right. Of the languages you listed only Rust provides any assistence over the standard mainstream languages, and like I said, in the context of Raft, it is not necessarily all that helpful.
If you want to see something that could potentially impact Raft's correctness, search the last couple of days of the HN front page for choreographic languages [1]. But none of these are even remotely mainstream enough to depend on for anything. Nor do I know if anyone in these languages has implemented Raft. A rather good test case for them, if any of them are looking. That's something that could actually help a Raft implementation's correctness, not just fiddle around the edges of local concurrency issues.
I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success.
Some time has passed and now their company does not exist anymore and we have a lot of their clients.
Perhaps that company failed because it chose to port things to Rust and not because of Rust itself? Or any other number of reasons that survivorship bias might be mistaking.
Where would one ever read that Go is not memory safe? That's just a false claim, and anyone believing it would have probably gone out of business regardless of choice of programming language.
My ex-boss was a JS guy and then moved over to Rust. He loathed Go because it has pointers and it's possible to use a nil pointer if you are not competent.
JS is fine for what and where it is, Rust is fine too. I just appreciate the stupid simple nature of Go and it does the job just fine.
> Go's internal data structures like interface values, slice headers, hash tables, and string headers are not immune to data races, so type and memory safety can be violated in multithreaded programs that modify shared instances of those types without synchronization.[113][114]
By a strict definition of memory safety it isn't - you can tear two-pointer-wide values using data races and cause arbitrary memory issues if you try to using only normal code.
It's close enough for most purposes... but it isn't.
Nobody serious claims Go is fully memory safe. Here's Russ Cox telling you concurrency is a hole in the memory safety: https://research.swtch.com/gorace
> Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. Antithesis found some more bugs in HashiCorp's Raft implementation recently[0].
the source you link to contradicts your own claims.
they say:
> we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft
The Raft bugs are the wrong kind of concurrency --- they're distsys bugs, not multithreading bugs. Not a good example, and a little telling that you'd cite it.
Just reading the abstract, it talks about finding a number of bugs (across millions of lines of code) but I didn't see any claims that there would be fewer bugs in a different language.
Go obviously does not stop you from writing buggy code. Neither does rust or zig or whatever. Does go make it more likely to have bugs? Or a specific class of bug? Like, the real world is about trade offs.
Uber has fairly large golang and java codebases so they have more of an apple to apples comparison here since they are both GC languages of a similar performance class. And if a large population tends to make more mistakes with 200hp sedan A vs 200hp sedan B, there is probably something up with the design of sedan A.
Uber has a history of blaming the tool - in Facebook fashion - rather than admitting their “talent” sucks and they didn’t hire on merit.
They used to blame Python a lot too - Python is slow compared to others but not so slow to matter that much, and you can build other services around it to handle certain work.
Facebook - who chose PHP - used to blame iOS/Obj-c as the reason they couldn’t build a decent Facebook native app in the early days (anyone remember Fastbook?)
What concrete arguments are there to believe in your talent hypothesis instead of their tool hypothesis?
A couple more comments like this from you, and I'll be able to say, "cyanmoonx has a history of blaming the talent rather than bad tools". There being a history like that is neither an argument for nor against tools being bad. And also, don't forget that bad tools and bad talent don't rule each other out.
Which languages are they comparing with? From what I understood, Rust makes stronger correctness guarantees, including with regard to concurrency, but has a much higher learning curve and cognitive load.
The best way to write concurrency in any language is a single threaded polling loop. Goroutines and messages are just as bad as all the other alternatives, which is to say they are a miserable way to write code.
But Go is also perfectly good at single threaded polling loops.
They use more than just Java. The UI was originally C#... I'm still surprised the front-end was C# but they went with Java longer term for the backend.
When I worked at OpenConnect (Netflix's CDN) there was a lot of Python too, and I started porting a lot of the tooling to Go. By the time I left (2019), Go was really starting to take off outside of OpenConnect too -- but yes, there's historically a huge amount of Java there.
Likely because Netflix relied on Silverlight for video playback early on. I'd be surprised if they still had C# in their front-end stack (and I say that as a general C# fan, though I use it on the back-end).
My favorite thing about it having Silverlight is Silverlight actually worked on Linux better than Flash did. I think I used the Mono version of it though, I don't remember?
I work at a large devsec company which uses primarily Go and TypeScript
I've found that the LLM generated Go has few mistakes, and generally isn't too obscure. But the volume of code is so high, colleagues do a bad job of reviewing it.
I've seen a lot of very silly decisions made, like returning the wrong HTTP code, or miscategorizing a metric used for an SLO, that I just don't think is helped by the sheer volume of code one has to wade through.
Ironically, we are considering migrating some initiatives to Rust, exactly because experiments indicate it works well with LLM development.
Why would you think so? Rust provide better type system and abstraction mechanisms compared to Go, hence equivalent system should have less lines of code, at least in from my experience.
Yes, and that's the case I've seen as well. I would also say rust is also more heavy on symbols, which can make code look kinda hard to parse in places.
But weirdly Opus (N=1) in Claude Code does okay on it. Enough I can reliably have it write software and feel confident it works.
A sort of an amateur I found Go to be really good when used with language models. Simplicity and tooling helps I suppose and I expected it to. However I was pleasantly surprised with how they are also pretty good with Flutter and Dart. Again good tooling, good documentation and perhaps not much historical baggage like a python or a PHP would have. And no stack overflow to speak of pretty much.
Your post reminds me of what I love about Python, we have PEP-8 which is a style guide, and it kind of shifts how you write code a bit (for the better) which is something I sorely miss in other languages, I don't get the feeling people care about style guides for other languages very much.
Go wins for simplicity. however what I have seen is companies end up going with Java coz it's simple enough - not simple as Go, but simple enough + fast enough.
though the letdown with Java is the wider ecosystem that makes unwarranted contraptions out of simple things.
Go's big advantage was M:N threads. Java's biggest flaw has been the lack of cooperative multitasking, which people worked around by mangling their code with promises. Now Java has M:N threads too thanks to Project Loom, but there's so much code written before that will never really go away.
I assume it's because Go is so opinionated? I experimented with it and found it almost boring to write, but I strangely loved it. Now in the AI era I crave the forced uniformity.
You can have that with generic functions, although Go's lambda syntax is too verbose. The slices package has DeleteFunc, which is kind of the opposite. I don't know why they have Filter.
If you know any other language, you basically already know Go (with the exception of the channels stuff). The biggest pain is the if err != nil stuff, which I know some people like but it is suboptimal in my view. While far better than C# and Java's exceptions, far worse than Zig's model.
We've seen a pretty consistent pattern in our evaluations where Go is among the languages that models perform worst with (alongside Python), for reasons unclear. Our coding evaluations are typically measuring the foresight and planning expressed in code that is run in interactive environments/games.
This trend has been there since we started evaluating models using different languages in February 2026 and if anything, the disparity has grown in frontier models. Even Google models prefer Kotlin/C#/Rust for coming up with creative ideas (compilation success is a different story). Data at https://gertlabs.com/rankings
That being said, models love to recommend Go, and Go does have a lot going for it, especially if you are serving a public-facing website. So most of our public facing API handlers are written in Go, and we offload some of our most important binaries to Rust. There are just too many reasons not to use the languages that models think a little more effectively in.
Yep. Have a primarily Go backend and from even early on the agents were doing a good job.
Now they are even better than me.
I do think the way software is organized for primarily agent driven repos will need to change a bit from how I preferred setting things up. (Guessing we're going to be returning to a world of microservices in the near future.)
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.
Been doing bash scripting for years. Tried Go recently, on my, it’s so much better for everything OS scripting. I regret I haven’t started with Go years ago. All my scripts are rewritten to Go. I kept only a handful, those that are just a few lines and no logic.
Not sure if it's obvious, but "go run" is just a thin wrapper around "go build" which compiles your Go code to a temporary location and then runs it in a single step.
Most of the time I use go build, or precisely make install with custom Makefile. For the one-time ad-hoc tools (vibe coded, by the way), I may use go run. My point is use the simplest tool, if it’s a little bit more complex than a few lines, it’s better in Go than bash. Here, I rather mean it’s better in any real programming language. Just… well, Go is really simple and with some GPT assistance you may be just one prompt and a minute away from automating some routine tasks. I try to automate as much as I can notice. E.g. I have a special script (now program) which moves files and directories from one location (synced documents) to another (archive on a disk). This is just a very simple operation, but doing it automatically feels very different. I’d highly recommend on trying something similar. Previously, I thought bash is good enough for this (and it is!), but Go is just better for me personally. And bonus thing, it works much faster.
I regret not going with bash or even sh when I had the chance. Nothing beats that for ubiquity and getting shit done.
Go is behind, specifically, you have no guarantees that a given machine has Go installed, and doing stuff like gluing commands together, inspecting some files, pipe output around, or automate the boring thing in 30 seconds.
Sure Go beats bash or sh when the thing you are doing starts to become real software, but that is a problem that sits between the chair and the keyboard.
That kept me away from the rewrite, but actually you can just throw a bin onto your server. At least for all my servers, I can do that. Migrating to Go helped me clean like hundreds of scripts into just a handful (tens) of slightly more complex, but unified programs with shared logic. I kept sticking to bash, not realising the complexity grew up already, and having a pile of simple scripts isn’t as simple as I thought. Go solved this beautifully, all the scripts were rewritten within just a month (with Claude assistance, but I’ve been checking on the code, it was OK), and now I can maintain them with less mental overhead.
> Is it better than zig if you are outputting minimal wasm deliverables?
Which tradeoffs are you willing to accept? Zig (along with several other languages) is superior in a lot of ways for that type of job, but I still settled on Go for a particular minimal WASM (browser) project. It wasn't my first choice, but it was where I ended up because LLMs kept going out to lunch in other languages and I didn't have anywhere close to the required budget to write it by hand. I read some comments like these about Go in the past so the Go attempt was mostly a contrarian Hail Mary after so many previous failed attempts in more technically well suited languages and... it worked! Shockingly well.
It still isn't my first choice for it, but having something useful with happy users beats technical imperfection every day of the week as far as my needs go. Go really did show its worth as an LLM target for that particular workload. Whether or not that is reproducible for any other project remains to be seen, but there seems to be a growing sentiment that echos the same. There just might be something to it.
the Go runtime comes along for the ride when producing a wasm file, if you are interested in "minimal" (as in small or without extra cruft) then languages that do not require such a thing might be more adequate
Tinygo's base runtime is only around 10kb. It was minimal enough for my needs. gc's runtime would have been a non-starter for that task, to be fair, but Go isn't an implementation. It is, quite explicitly, a language.
There are language implementations that would have been more minimal than that, sure, but there was no obvious way to get LLMs into alignment. I tried. Multiple times. When I switched to Go, it just worked. It may not be technical perfection, but it let me ship something I had almost given up on and it has satisfied users. The tradeoff was worthwhile for my needs. That tradeoff may not be acceptable in all cases. Hence what is best being meaningless without at least defining which tradeoffs you are willing to accept.
Exactly. Go is a language. Tinygo is an implementation, like gccgo, gc, llgo, etc. Just as gcc, clang, and msvc are not C.
> more Go-like or adjacent
It is true that recover isn't fully spec complaint at this time. That's not entirely unusual for an implementation, though. msvc is famously not 100% spec complaint with C, but Microsoft still officially considers it a C compiler, as do most who use it to compile their C code. There is usually a little grace given.
It is not like Solod that is Go-like but trying to do something quite different. Tinygo is intended to be a proper Go compiler implementation and has achieved that, aside from the recover situation.
> 10KB still matters a lot in a lot of minimal target/usage scenarios
But, of course, if the LLM cannot wrangle the language then it doesn't matter. Nobody cares how large or small your program is if you never ship it. That only matters if you are using LLMs, but since that's what we have always been talking about...
Token use didn't seem to be a criteria from my casual reading, but maybe you can illuminate me what section pointed to that, I may have been too superficial in my reading
The article is about which tool is more appropriate, and you're dodging that question. Every use case has multiple langs you could use for it, and there's no universally agreed-upon choice. Like if you're writing a typical web API backend with LLM assistance from scratch, which do you use between JS, Py, Java, Go, Rust, etc?
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.
394 comments
No way to know until someone does the science on this. Until then it's just people saying that more static checking is better. But I do think, anecdotally, python is horrible for LLMs.
Go is simple, no “magic” marcos or meta programming even with just a little programming in any language it’s not hard to understand what the go code is doing.
I have no doubt that you can get a LLM to write working bug free code in any language but that is not the topic of the article or my comment.
If you're going to have an agent write most of your code readability is very important.
The default sentiment is humans should read code it's more progressive and a leap of faith to start giving that up.
Obviously, I get why you feel humans still reading code is important, but if you look at the progress of AI for the past couple of years, that gap is closing. The trendlines speak of a future where it becomes less and less important.
This was exactly what happened with writing code. Now most people don't write code.
I use LLM daily to write code for and "with" me, I also write code without LLM. Most people I come across mix it up. A few do it all by hand, and equally few all by LLM I would say. Is that just in my corner of the world?
My entire company for example does not write a line of code. We manage agents and that's it. Many, many, many companies and people are already doing this.
I think it's the use of pointers and "if err != nil {}" error handling spam. It reads as a highly compromised imitation of Python and C rather than a solid execution of some other idea.
Rust is not the most beautiful language out there but it doesn't trigger any such reaction for me. The ? operator and "match", which I use constantly, more than compensate for some of the sigil noise which I barely need to look at much less write most of the time. So Rust wins on that comparison for me.
The "func name() -> retval" syntax also grew on me. I like the fact that Python type annotations copied that approach, and C-style declarations look ugly to me now. Same with C-style /* */ comments.
Rust is definitely jarring to look at, in the same way that decoding some strange C declaration can be, in ye olde days when you had to float all this context in your mind while doing work. But with modern tooling who cares: "explain this lifetime to me"
You can pretty clearly see the limitations if you read, for example, the type of code the Protobuf compiler generates when trying to compile Protobuf/gRPC enums or structs into the way-more-limited Golang type system (this is despite the two being designed to work together). And it could really do with algerbraic data types and other modern programming language features.
Also the type system does have a couple weird behaviors that seem straight out of JavaScript. Like the difference between struct and interface nil for example:
```
var buf *bytes.Buffer = nil
var out io.Writer = buf // now out is nil
if out != nil {
}```
Many things about the language almost seem to be designed to simplify the implementation of the compiler rather than to benefit the developer experience.
Go's historic maintainability strong suit has been its simplicity and consistency. The syntax is, relatively speaking, lightweight, the language invites complexity through composition, and information density for any unit of code is typically quite low (which isn't necessarily a bad thing).
In my opinion, though, these are all drawbacks, and Rust addresses all of them. It's syntactically and semantically much heavier, leading to its oft-maligned steep learning curve. It has, uniquely among the major languages, I think, a syntax for expressing variable lifetimes (with its own unintuitive semantics). It stuffs lots of abstraction into a hodgepodge of terse semantics and punctuation.
It sucks to read, until you get really used to it. Then it tends to read really quickly, and, at least for me, it's easier to reason about a conceptually-broad piece of logic if I don't have to jump between different locations in a file, a module, or a package to do it.
With Go, I find it more difficult to get into a flow state, and easier for my eyes to glaze over when looking over large diffs.
It's not lost on me that these are purely subjective arguments, though. My preference remains with Rust, and that goes back to before I used LLMs.
I'm also aware that Go is very prescriptive about how you write it; it's explicitly opinionated, and Rust doesn't have that. It means that most Go code bases will look more alike. I consider this an anti-feature; I believe code should be able to conform to the problem space or product and a good team will find the best way to do that.
E.g. make a table that's 3x3 is easier to read (Go), but the equivalent line in Rust would also include material, angles, height, etc. because the type system encodes much more information.
Though I always found Go to be significantly harder to read than Rust. Sure Rust has some crazy syntax at the edges, but Go makes it very hard to know where imports come from (and thus what they do), and the imperative style + lack of clarity about mutability makes code much harder to reason about.
I my self and teams members are slowly reading less code and requiring agents to prove things work the way we want in other ways.
- There's a lot of Go code out there which the models have seen, so they know how to write it.
- Go has an exceptional standard library, so you don't need to drag in 100 dependencies to create a simple web app.
- Go compiles extremely quickly for incremental builds, which really matters when agents are building and running tests constantly.
- Go has a goldilocks blend of performance and safety. You get a good type system and excellent runtime performance without forcing the model to spend cycles fixing Rust lifetimes or Swift concurrency issues for a marginal incremental gain.
- Go is relatively stable, so the LLM's memorized knowledge is still pretty fresh (as opposed to something like SwiftUI, where the API changes rapidly).
- LLMs have clearly been trained on a lot of Rust as well
- Compile times are counterbalanced by strong compiler with excellent error messages, and "cargo check" can catch many issues without a full build.
- If you're willing to accept Go levels of performance from Rust, there's nothing preventing you from using copies and clones rather than borrows, which makes most code dead simple.
- For most major dependency types, there exists a clear "winner" in terms of community adoption, so the fact that it's not in the stdlib is not that problematic.
With golang, all borrow checker problems go away. This is a good trade off if your app is not cpu-bound, which most are not. If you need every last drop of performance then rust is a better choice of course.
However, I have run into a few cases of runtime null crashes in go.
You only have to compile when you actually want to test the behavior, which tends to be right on the first try more often as a result of the strict compiler.
With that said, I have not done an extensive amount of agentic development in Rust, so maybe I just don't have the reps to compare fairly.
Nothing costs more tokens than an LLM trying to debug errors caused at runtime which doesn't map well to it's "intelligence" compared to what Rust provides
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.
errcheck, generally as manifested in golangci-lint, ensures you can't forget to do something with them. It would be odd for you to know about forbidigo but not errcheck as the former is much less widely known; is there something that errcheck doesn't do for you?
It's worth pointing out that "discard this error on purpose" is a legitimate form of error handling, so "enforce error handling" can't really constitute banning that. That's not a Go statement, that's just true in general... it is sometimes valid to just ignore the error, because there's nothing useful to do with it anyhow. I would agree the ignoring should be explicit, but it is an option.
https://github.com/kstenerud/yoloai/blob/main/docs/contribut...
Poor defaults break systems by a thousand cuts. They seem to make sense when designing the language (more convenient, less typing, etc), but then they very quickly become liabilities as project complexity increases. Go made the mistakes of mutable-by-default and silent-error-dropping, but their cyclical-import-forbidding was a good call.
Maybe we are using different tools (or we've set it up wrong) but I'm consistently surprised at how slow Go's linting is (using golangci-lint). Takes nearly 5 minutes on our codebase after any change (which means I just don't run it locally or in-editor). It's remarkable how poor the experience is after using tools like Python's Ruff (instant) or Rust's Clippy. I'd have expected a fast, default setup that I could tune.
Event JS's Eslint, which runs in actual JS, takes 21 seconds for a full sweep (which I don't normally run, since the in-editor hints are so fast)
It's surprising, because so many of Go's dev tools are so well thought out!
Might be a skill issue, but I got frustrated with it on new projects constantly.
Also, I tend to ask planning questions, like "how would you implement this" and "what would the API changes be?" I'm picky about API's. Lately I've been using Deno workspaces (multi-package repos) and tell it when to make a new package or a new entrypoint. Maybe that helps?
If I just ask for features and don't look at the code, it will definitely make a mess, though. (A working mess, but it takes a while to refactor my way out.)
That's not really a typescript thing though, just an LLM thing.
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.
I agree very strongly. There's no debate about things that have 1000000 permutations in other languages. e.g. The correct format can always be checked by `go fmt` with no real config options. the end.
Similar to black but faster, written in Rust, by the same team who created uv.
> mean this isn't true, formatting is the most trivial part. And so many languages have an opinionated formatter these days (e.g. Black)
I don't think this is correct
[1] https://google.github.io/styleguide/go/
Especially the uv thing. You clone some non-uv git repo that has no pyproject.toml and you don't know what to install. Maybe has requirements.txt but it's partially wrong.
If I do the simplest possible thing that isn't a single word, by highlighting "opinionated formatter these days (e.g. Black)" and clicking search, I get the right result. I also get the right result for black formatter, and I get the right result if I yolo the entire comment as my search.
> ...And so many languages have an opinionated formatter these days
The crux of gp's post is for Go, there is no debate as 'go fmt' is the only one that matters. Black is great, but some people prefer Ruff, leading to ...debates about which formatter the team/org should use. Go's batteries-included philosophy makes those discussions moot on so many levels beyond formatting.
The first one to choose it (whatever it happens to be) wins and that's the end of it. If it isn't the end of it you've got a talent issue.
Guess what other low-level bike-shedding argument 'go fmt' obviates? That's right - tabs vs spaces!
> If it isn't the end of it you've got a talent issue.
I know you meant this as a slur, but the implication is Go works better than other languages for those who have what you call "a talent issue"
In any case, that's a single decision the project lead takes once.
After all, learning a new language takes a lot of time. While basic syntax is common and quick to pick up, mastering a language's specific mental model requires a significant time investment, which is why I've used Go before but never seriously.
My interest was piqued recently when I heard about TypeScript tooling being ported to Go, and I know it is incredibly fast. However, where do the results claiming that AI agents generate superior Go code actually come from? Is it a fair, apples-to-apples comparison?
Since Go is a very small language with only 25 keywords, the way you write code is extremely standardized. Because of this, I would assume it naturally produces a lot of excellent best practices and conventions, but I'm not sure if there are actual, direct code examples proving this
I didn't say that. :)
> where do the results claiming that AI agents generate superior Go code actually come from?
Like I said - reports from users.
> Is it a fair, apples-to-apples comparison?
No - these are reports from users, not a systematic analysis.
It's anecdata and maybe, MAYBE, a spreadsheet. Or a Google Form somewhere.
> I didn't say that. :)
I call this the Go paradox.
I simultaneously believe we should reach for it 80% of the time to solve common collaborative problems. And being a poorer language is actually an asset in these cases.
However, in doing so, we get rusty lose our fluency in more expressive, perhaps even better languages.
How does that work? Are they generating the same project in different languages and comparing the results? What does it mean for the code to be "better"?
In my opinion, it has little to do with the speed of the language. The large quantity of source code to train on is quite helpful, but I think it's something else.
There are three things that I think make it well suited to LLM authorship -
1) static typing and a quick compiler - a variable can't change type after it's declared (unlike Python) makes Go more robust compared to dynamic languages. You (almost) always know what the type of a variable is. And the quick compiling with hard-stop errors means that the LLM gets a solid signal for each round.
2) It's quite opinionated, syntactically. There is generally one way that Go lang code is supposed to look. That means it's pretty easy to read as well as write. The lack of things like operator/method overloading make it an easy language to reason about.
3) the stdlib and limited dependencies. Dependency trees tend to be shallow, and because of the static linking (by default), you can generally be confident that what you wrote will run.
As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. Antithesis found some more bugs in HashiCorp's Raft implementation recently[0]. I'm sure etcd still has some kicking around.
Maybe this is a "don't throw the baby out with the bath water' problem but the general evolution of Go has been lackluster. I reach for Rust, Zig, and modern Java instead depending on the specific needs and constraints.
0 - https://antithesis.com/blog/2026/finding-bugs-in-raft-implem...
The antithesis author states:
> Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust.
That says that there are correct (i.e., bug-free) implementations in those languages. The GP noted
> "we’ve found bugs in every Raft implementation we’ve tested, ..."
which says that there aren't any correct ones. You then wrote
> I didn't say other languages don't have buggy Raft/Paxos implementations
which is a strawman. The issue is whether there are correct implementations. That there are buggy ones is irrelevant.
(FWIW I have no dog in this fight ... I'm just reading here.)
Edit:
> What are they implying by citing that? That Raft implementations in all languages have bugs?
That's what it says.
> I've already pointed out that is false.
You claimed that, and it's being disputed.
> Please let me know, since you're so comfortable speaking for them.
This has veered into bad faith ... I won't comment further.
> The antithesis author states:
> "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft"
What are they implying by citing that? That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people make Raft implementations for fun and learning. Again, Go does not have a single Raft/Paxos implementation that is rock solid. I have seen many in C++, Java, and Rust that are doing tens of millions of requests per second in production for over a decade.
Is their point that Go is not the only language with this problem? My post already points out the track record is that Go is the problem for writing correct code in highly critical domains.
The only way this becomes useful for comparing languages is if somebody gives evidence of correct implementations in other languages. You're claiming they exist but with no evidence and suggesting they're secret. How do you know those don't have bugs? Did any concurrency bug experts do extensive testing on them? And can we disprove secret Go implementations of the same quality?
No, they are citing that every Raft implementation that Antithesis has tested has bugs. The etcd implementation you note in go that has bugs also does tens of millions of QPS and is over a decade old. How are you confident that the proprietary implementations that presumably haven't been fully tested don't have subtle bugs that don't show up in practice?
>> "we’ve found bugs in every Raft implementation we’ve tested, ..."
> which says that there aren't any correct ones
That only follows if the GP tested every Raft implementation in existence and no new ones were written since.
Java leans heavily in the other direction: a lot of concurrency is added externally, without changing existing code, often in very declarative-flavored ways.
E.g. Future<T> serves as a foundation for a ridiculous amount of stuff, while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics.
There are very obviously lots of counter-examples for both langs (`synchronized`, rill in Go, etc), and I expect Go to become more Java-flavored in time (it already has moved this direction somewhat, and 1.27 will enable a lot more). But I think it's a fair summary of broad ecosystem habits.
1: https://tip.golang.org/doc/go1.27 (not yet released)
Are you saying that this implementation is wrong?
"This Raft library is stable and feature complete. As of 2016, it is the most widely used Raft library in production, serving tens of thousands clusters each day. It powers distributed systems such as etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Project Calico, Flannel, Hyperledger and more."
One of the most popular distributed DB is Cockroach which is written in go and also uses Raft: https://github.com/cockroachdb/cockroach/tree/master/pkg/raf...
> are you saying this implementation is wrong?
> That's not remotely what he's saying at all.
I'm v confused by this thread
That is literally what the comment says.
You may be interested in knowing that the largest managed Kubernetes service in the world (AWS EKS) ripped out etcd for in favor of their homegrown consensus service for large scale EKS clusters: https://aws.amazon.com/blogs/containers/under-the-hood-amazo...
goBGP is arguably even worse.
I don't have a third place in mind that's even worth mentioning relative to these two.
(I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)
[1] https://elegantnetwork.github.io/posts/comparing-open-source...
0: https://etcd.io/blog/2025/autonomus_testing_with_antithesis/
1: https://jepsen.io/analyses/etcd-3.4.3
2: https://github.com/etcd-io/raft/pull/113
Etcd corruption and loss of quorum is extremely common in practice and the GitHub issues sit for years. The design is simple, the performance is modest, yet it still has still never been reliable, despite being marketed as so. I can't speak to whether this is specifically due to their Raft implementation, but I'd argue the entire codebase is over-engineered and questionable.
Its very much {reliable, performant, flexible} pick none.
That the world runs on Kubernetes is no qualitative statement about the correctness of its Raft implementation. You can say that it's clearly good enough to not matter most of the time, but that is a different statement. No matter who you look at, they're just cooking with gas like you do, and they can make mistakes in just the same way.
Now; I'm only attacking your argument. I do neither know nor particularly care about the correctness of that implementation itself. There's been better refutations of the claim you replied to in other answers anyway.
I didn't know Go just isn't a good language for it, but now that I know I'm no longer surprised at etcd being problematic.
But good god, the second it gets to anything concurrency-related, it just loses its mind. As much as it's gotten vaguely ok to try to let the agents loose on some bits of the codebase, they simply can't even do table stakes stuff with the kinds of concurrency you see in real life.
Zig is also good at this but requires more up front design (thread-per-core, static allocation, etc.) and consistent checks to verify rules are followed.
It seems like claude code can code Rust pretty well with Opus, and I've started moving codebases away from Golang to Rust at work with Opus. Spin up an LLM and it cranks on it for a while, and as a benefit, I get easy apis to build on with other languages.
And that's the problem with Golang really, not that it's a bad language per se (all languages have footguns), but that the language interoperability story is terrible. Meanwhile Rust and Python/C/C++ go great together like peanut butter and chocolate. And I love it.
And deadlocks. "Fearless concurrency" helps a lot, but logic bugs are still possible.
If you want to see something that could potentially impact Raft's correctness, search the last couple of days of the HN front page for choreographic languages [1]. But none of these are even remotely mainstream enough to depend on for anything. Nor do I know if anyone in these languages has implemented Raft. A rather good test case for them, if any of them are looking. That's something that could actually help a Raft implementation's correctness, not just fiddle around the edges of local concurrency issues.
[1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success.
Some time has passed and now their company does not exist anymore and we have a lot of their clients.
Thank you!
JS is fine for what and where it is, Rust is fine too. I just appreciate the stupid simple nature of Go and it does the job just fine.
> Go's internal data structures like interface values, slice headers, hash tables, and string headers are not immune to data races, so type and memory safety can be violated in multithreaded programs that modify shared instances of those types without synchronization.[113][114]
It's close enough for most purposes... but it isn't.
the source you link to contradicts your own claims.
they say:
> we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft
(besides Go, that's 2 in Java and 1 in Rust)
Go obviously does not stop you from writing buggy code. Neither does rust or zig or whatever. Does go make it more likely to have bugs? Or a specific class of bug? Like, the real world is about trade offs.
Yes, it's a bit of blame the user which will likely get the retort of "but I thought Go was perfect for junior engineers?"
Yes, there are footguns but none of the points therein were compelling.
They used to blame Python a lot too - Python is slow compared to others but not so slow to matter that much, and you can build other services around it to handle certain work.
Facebook - who chose PHP - used to blame iOS/Obj-c as the reason they couldn’t build a decent Facebook native app in the early days (anyone remember Fastbook?)
I would take it with a grain of salt.
A couple more comments like this from you, and I'll be able to say, "cyanmoonx has a history of blaming the talent rather than bad tools". There being a history like that is neither an argument for nor against tools being bad. And also, don't forget that bad tools and bad talent don't rule each other out.
But Go is also perfectly good at single threaded polling loops.
I've found a lot of success pointing claude at locally downloaded docs over llms.txt URLs but not sure how to scale the pattern for a bigger project.
I've found that the LLM generated Go has few mistakes, and generally isn't too obscure. But the volume of code is so high, colleagues do a bad job of reviewing it.
I've seen a lot of very silly decisions made, like returning the wrong HTTP code, or miscategorizing a metric used for an SLO, that I just don't think is helped by the sheer volume of code one has to wade through.
Ironically, we are considering migrating some initiatives to Rust, exactly because experiments indicate it works well with LLM development.
But weirdly Opus (N=1) in Claude Code does okay on it. Enough I can reliably have it write software and feel confident it works.
though the letdown with Java is the wider ecosystem that makes unwarranted contraptions out of simple things.
I'm curious to try your proposal, I just want more specifics.
https://github.com/notque/vexjoy-agent/pull/908
Yeah Go is my preferred language to code with AI. Second up is type script. Followed by Java, then Python.
One of the cores behind Go is to make language simple, even if at the expense of more verbose code.
Two main examples of this is the infamous 'if err != nil' and how you handle filter/map/funcional operations.
On the other hand, being able to write 'list.filter(v => v.selected)' (or something similar) instead of:
would save much more tokens.https://pkg.go.dev/slices#DeleteFunc
This trend has been there since we started evaluating models using different languages in February 2026 and if anything, the disparity has grown in frontier models. Even Google models prefer Kotlin/C#/Rust for coming up with creative ideas (compilation success is a different story). Data at https://gertlabs.com/rankings
That being said, models love to recommend Go, and Go does have a lot going for it, especially if you are serving a public-facing website. So most of our public facing API handlers are written in Go, and we offload some of our most important binaries to Rust. There are just too many reasons not to use the languages that models think a little more effectively in.
Now they are even better than me.
I do think the way software is organized for primarily agent driven repos will need to change a bit from how I preferred setting things up. (Guessing we're going to be returning to a world of microservices in the near future.)
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
Go is behind, specifically, you have no guarantees that a given machine has Go installed, and doing stuff like gluing commands together, inspecting some files, pipe output around, or automate the boring thing in 30 seconds.
Sure Go beats bash or sh when the thing you are doing starts to become real software, but that is a problem that sits between the chair and the keyboard.
Which tradeoffs are you willing to accept? Zig (along with several other languages) is superior in a lot of ways for that type of job, but I still settled on Go for a particular minimal WASM (browser) project. It wasn't my first choice, but it was where I ended up because LLMs kept going out to lunch in other languages and I didn't have anywhere close to the required budget to write it by hand. I read some comments like these about Go in the past so the Go attempt was mostly a contrarian Hail Mary after so many previous failed attempts in more technically well suited languages and... it worked! Shockingly well.
It still isn't my first choice for it, but having something useful with happy users beats technical imperfection every day of the week as far as my needs go. Go really did show its worth as an LLM target for that particular workload. Whether or not that is reproducible for any other project remains to be seen, but there seems to be a growing sentiment that echos the same. There just might be something to it.
There are language implementations that would have been more minimal than that, sure, but there was no obvious way to get LLMs into alignment. I tried. Multiple times. When I switched to Go, it just worked. It may not be technical perfection, but it let me ship something I had almost given up on and it has satisfied users. The tradeoff was worthwhile for my needs. That tradeoff may not be acceptable in all cases. Hence what is best being meaningless without at least defining which tradeoffs you are willing to accept.
Two things to keep in mind here:
1. TinyGo is not Go, more Go-like or adjacent
2. 10KB still matters a lot in a lot of minimal target/usage scenarios
Exactly. Go is a language. Tinygo is an implementation, like gccgo, gc, llgo, etc. Just as gcc, clang, and msvc are not C.
> more Go-like or adjacent
It is true that recover isn't fully spec complaint at this time. That's not entirely unusual for an implementation, though. msvc is famously not 100% spec complaint with C, but Microsoft still officially considers it a C compiler, as do most who use it to compile their C code. There is usually a little grace given.
It is not like Solod that is Go-like but trying to do something quite different. Tinygo is intended to be a proper Go compiler implementation and has achieved that, aside from the recover situation.
> 10KB still matters a lot in a lot of minimal target/usage scenarios
But, of course, if the LLM cannot wrangle the language then it doesn't matter. Nobody cares how large or small your program is if you never ship it. That only matters if you are using LLMs, but since that's what we have always been talking about...
The article specifically discusses how Go is well-suited for LLMs. It's not going on about general programming topics.
what would be the purpose then?
Token use didn't seem to be a criteria from my casual reading, but maybe you can illuminate me what section pointed to that, I may have been too superficial in my reading
It's hard not to, given your comments in this thread.
People who want to use the most appropriate tool.
> Use the ones more appropriate for what you are trying to do.
What they are trying to do is find a programming language that LLMs work well with.
> So you are using Go with LLMs for the objective and destination of token consumption for token consumption sake?
The trolling gets more intense with each comment ...
P.S. Someone else responded:
> But this isn't a user story. The user story is what you should be picking the tool for.
I don't see how this is at all relevant to my comments. I'm certainly not going to argue about what some other party should or should not be doing.
But this isn't a user story. The user story is what you should be picking the tool for.