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.
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.
"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."
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...
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?
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 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:
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.
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.
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?
> 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?
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.
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.
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.
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.
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.
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.
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.
> ...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.
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.
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.
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.
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?
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.
Large projects at small companies use more than one language.
I'm not anti-go. I've had some bad things to say about it, but I could do that with any language I've used. It just hasn't emerged as a tool I feel delivers enough value to be the realistic choice. I've used it for a few small things, and it does what it says on the tin. The existence of nil, the primitive error handling and the years long misguided resistance to generics were a problem for me. Two of those still are.
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
>> 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"?
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.
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.
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 agree with you here and I think you raise several good points, such as "Go's weakness transmutes into a strength" (allegedly). Indeed that makes no sense for Google to try to claim that.
Your other point is even more interesting, e. g. "before AI, Go sucked and nobody used it" - now this may be an exaggeration or simplification, but it is a great observation nonetheless, because Google suddenly tries to connect Go with the rise of AI, almost as if AI could not have risen without Go, which is indeed very strange as an argument to make by Google here. This also reminds me of Google promoting Dart/Flutter before giving up on this and preparing to send it (eventually) to the infamous Google graveyard at some point in the not-so-distant future.
This would have been more credible coming from someone other than the creator of the Go language.
I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests.
Tokens are cheap, surprises at runtime are not. So a super anal compiler is what I want. I've looked at lean4 too as the logical next step but not confident I can guide an LLM competently enough for that.
fwiw I have a bunch of LLMs writing first Lean code and now Agda code.
My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code. I've thrown a lot of gnarly C and Ruby code at all sorts of LLMs and they have only gotten more and more impressive as frontier models have gotten stronger. With Agda, they're like "hmm, tricky" whereas for me it's an impenetrable fortress. I've asked them why they find Agda so much more difficult to write (and why they have to iterate and reiterate many many many times until they get to a destination whereas they can one-shot and two-shot C and Ruby and they tell me its the multiple competing constraints. GLM is hilarious, it flat out refuses to write Agda code but it reads it well enough. They all read it well enough. Fable is obviously great at it. And Opus 4.8/5.0 are great (if they stay on track and don't sneakily go their own way) but they're too annoying to talk to. On balance Kimi K3 is the best balance of not annoying, relatively cheap, and strong -- great model all round tbh.
So yeah, interesting I've discovered the limits of their ability coding-ability-wise. None of them are that good at designing/aesthetic judgment/architecting so thankfully they still need me in the loop.
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.
It would be neat to see a matrix of compile times vs. language features, showing things like:
- Bounds checks
- UAF prevention
- exhaustive enums
- test speed
But I think even among those the subtleties would make a fair comparison impossible.
Anyway I think this is all very nuanced, and anyone proclaiming language X is the language to use in 2026 lacks the experience/knowledge to consider these trade-offs and can safely be ignored.
> leveraging their compilers and enforcing more correctness guarantees.
The counter argument here is that these checks cause slower compile times and were designed to prevent common mistakes humans make.
If models get good, they may not need the same checks human written code needs. For example, frontier models already will virtually never produce a typo.
Humans need time to think, but a model’s bottleneck is in how quickly it can verify its work. Slower compile times hurt a models ability to iterate.
I don’t think we’re there yet (and we may not get there). But there is an argument to be made that languages with faster compile times may be better for LLMs in the long run than languages with strong checks but slow compilation.
This is a rather poorly-written post that more or less boils down to "GHC isn't fast enough to let us make deep-reaching changes to our codebase all the time" (fair, but this shouldn't be necessary if your abstractions are solid? seems to telegraph very substandard engineering practices, but I guess that's what you get with vibecoding) and vague complaining about how the Haskell community isn't all-in on AI.
I was curious about this so I dug further, and by the author's own admission, they've only made the switch for basic CRUD logic without performance needs, not their core services: https://news.ycombinator.com/item?id=48865986.
It's also pretty unsurprising, given what we know about LLMs' style transfer abilities, that transferring parts of an existing Haskell codebase into Python would avoid a lot of the errors and pitfalls that codebases originating in Python are known for. My experience coming from writing lots of Python is that this does not continue to hold true as you let the agents loose on your Python codebase.
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.
Here's how my assessment selected Go (long before LLMs):
- I had to write a moderately complex program. I didn't want to do it in C, and I didn't want to learn Rust.
- So I spent roughly about 2 hours becoming familiar with Go and playing around in Go playground. I decided that this would work.
- And then I got started on my program and I was immediately productive and that software is still running today, along with all the other stuff I've written since then.
Programmer productivity is excellent with Go. And it has a thriving ecosystem. Of course, some things could be better, but I don't really have much issue with it's error handling or types.
> I didn't want to do it in C, and I didn't want to learn Rust.
Sounds like you made a decision right there. The rest is just retro-justification, not a logical argument or comparative between options. It works for you, good.
Go is relatively easy to learn, and the semantics of the language make it more difficult to write "clever" code that's difficult to understand.
That's the main selling point, with a secondary point that it statically compiles so you don't have to do a whole Python/JS distribution thing for CLIs.
Java feels like the closest contender here, although it really sucks for CLIs due to start up times. I don't think it's the easiest to learn either, but I've never tried all that hard.
It only really makes sense to me at org-scale, though. I think you raise a very good point for individual projects, I too normally don't choose Go for that (unless I need compilation to make distribution to myself easier on corporate laptops).
Something doesn’t need to be the best at anything to be on a Pareto frontier. And (usually) no one chooses on a single dimension; they choose a point in many that maximizes distance from zero, scaled by their preferences, if you are thinking of it like a frontier.
Is there a language that you would argue is at least as good as Go at everything and better than Go in at least one thing? That would be the most straightforward way to argue against its Pareto optimality.
Listing particular sets of preferences for which Go is not optimal is not sufficient unless you can show the list to be exhaustive.
I'm not GP, but for me that would be TypeScript. TypeScript's tooling is as good as Go's across the board, it's very readable, it's a simple language, it has very few footguns, and it compiles fast. But it has better type safety than Go.
This isn't an exhaustive proof as no language will every be fully Pareto optimal in practice (it's just not possible, there are too many dimensions), but I'd argue it's at least somewhat close.
> if you highly value language popularity; Go is not most popular
Go is similar to popular languages like C, JS/TS, & Python. And so, easy to get started.
> highly value a type system that catches errors
Probably these folks already use even less popular ML-style languages like OCaml & Haskell; or (comparatively) obscure ones like Agda, Idris, & rocq/Coq.
LLMs fail to produce bug free concurrent code even for very simple cases.
Golang lacks the ability to build descent abstractions, not even mentioning the wild west of additional tools and libraries needed for non trivial micro services.
For me it is a red flag, that LLMs allow people to produce more bad Golang code faster. This is only optimization for companies which can afford enough software developers to review the excessive amounts of code needed to solve trivial problems in Golang, which are builtin in every descent programming language and/or framework.
Use LMMs and use the right programming language. This might be Golang, but most probably it is C#, Java, Python, Ruby or even PHP. (Or Rust, C, D, ...)
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 really don't agree. I'm not hear to evangelize rust but by using enums from DB to templates and writing the code to make it consistent my experience with LLMs is infinitely better than golang for consistency and you have to include a lot more context to make golang work without issues whenever things are operating on chans or workgroups.
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.
Ok so the question is which is more appropriate. Every use case has multiple langs you could use for it, and there's no universally agreed-upon choice. Like you're writing a typical web API backend with LLM assistance, which do you use between JS, Py, Java, Go, Rust...?
The article is assuming you're doing some basket of general programming tasks. You can use Go for all of them. I personally wouldn't.
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
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.
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.
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.
> 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.
Right. Go is a language, Tinygo is an implementation. We already discussed that, though.
> 10KB still matters a lot in a lot of minimal target/usage scenarios
But if the LLM cannot wrangle the language, better isn't an option. I mean, you can still write code by hand, if budget allows, but since we're explicitly talking about using LLMs that is irrelevant.
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.
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.
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
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.
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.
> 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.
I have found exactly the opposite to be true: as always, people think they can write safe concurrent code without the machine checking them and end up getting it completely wrong in lots of subtle cases. Except the problem is now much worse because you're not even writing the code, or in many cases, reading it. I prefer a language with a type system that saves me from the review burden of closely checking (and pretty much always finding issues in) concurrency invariants. And even tells me a bit more beyond that about what the code is intended to do.
Came here to say exactly this. If you’re not writing the code (or especially reviewing it) then we need stronger type systems and more checks and fewer legal programs. Might as well move all the way to Idris or some not-yet-invented language that humans would find very restrictive.
> Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, [...]
That's a pile of bollocks, pardon my French. Source/proof?
And to the contrary:
I've been working on a TS codebase that calls into C++ native/wasm-compiled code for six months now. The code is mostly LLM written.
Over these last six months we had four use-after-free and two other ownership-related bugs in LLM-generated TS code.
Whereas we had zero issues of any such kind with LLM-generated Rust code that sits in another two native/wasm-compiled metacrates we use.
LLMs are not much better at ownership tracking than humans.
Especially if resource acquisition and release are far apart in code and/or somehow nested/stacked/non-straightforward.
The problem with ownership tracking is that it's global. Humans are bad with global things, linters too, but LLMs are exceptionally bad at them due to the context window and (currently, at least) not knowing enough where to search. So yes I'd expect them to make the same mistakes as human and even more frequently.
> 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.
If the premise of the article is true, and I think that it is, that's quite the downside for AI coding with go. The premise being that reviewing now plays much more of a role than writing.
Personally, I'd rather review, say, a ruby oneliner that extracts specific row values from a csv file with filter_map, compared to 40 or so lines of go, many of which I'd have to check individually for possible mistakes.
Go doesn't have any kind of story for incremental migration from C++ or Java; you are talking about rewriting all those codebases from scratch, which is an obvious nonstarter as long as engineering resources are finite.
IIUC Fuchsia uses Dart mostly for UI stuff and Go has never really tried to be competitive there? I don't see much of a reason to suppose this is a serious bottleneck to Fuchsia adoption, as opposed to the obvious reasons why it's hard to displace an existing OS with a huge install base.
Sure, what I mean by that is that LLM makes different kind of mistakes than humans, they usually take the shortest direct route to accomplish their task. You can see that with the Bun Rust rewrite, I don't think any human coder would put as many `unsafe` and `Clone()` and `Arc<Mutex<T>` in their code, so a lot of time, they would just attempt to bypass the borrow checker if they see it get in their way.
So in terms of the mainstream languages, what would you say would be the most ideal language? (At least until Oct takes off!). Perhaps modern Java? .. Or even Zig?
C#, only because of dotnet ecosystem and tooling is great. TypeScript is a dark horse candidate, it's a great language with a great ecosystem trapped by JS tooling, and most of all, NPM. Rust is fine if you just tell LLMs to use short borrows only. I wouldn't even say Oct is the most ideal language, it's pretty good at getting LLMs to do science, but probably isn't the right language for all applications.
I have some very heavy criticism for Zig technically, because their whole thing about "no hidden control flow" becomes "shove all the hidden control flow into a second hard to debug runtime that runs at compile time", and manual allocation for everything is incredibly tedious and hard to keep track of in production code. I mean, C++ wasn't ALL wrong, there was a reason that templates exist in the first place, and having the entire generics model be just comptime isn't really a decision I agree with. The way I see it, Zig would probably find a niche as a language that configs C/C++ codebase at compile time instead of the C replacement they want it to be.
There are two more languages I have in the Oct repo, SDSL-V for SPIR-V shader/compute kernel authoring and Concept/Vulkan because the 20k line C Vulkan Prometheus runtime for GPU compute that we built is getting kind of unmaintainable even by AI that making up a new programming language to strangler fig refactor it is honestly the least bad option.
I mean I don't have anything against go, but frankly - it's not really better then modern Java.
Each have their trade-offs, both can support native compiled application code. Some architectures are easier to review and code in golang, but others go much better with Javas richer ecosystem and better composability.
Joking aside, as much as Go's stdlib and tools do the heavy lifting here, Go's verbostiy and expressing simple things in lots of lines worked against me most of the time.
I've had a really terrible time getting LLM to properly handle errors as return values. It seems that bubbling up errors, in a side channel, to a contextually relevant point in the code (exceptions) seems MUCH easier for LLM to reason about/implement properly.
Maybe my problem is I'm using a language with exceptions, so trying to go against the statistical grain, with return values, is just too much.
Exceptions are inherently better for high-level code. You only want errors as values in systems code. Rust and Go both did that because they were at least originally designed for systems code.
Even then, it does seem like LLMs at least a year ago had difficulty understanding that exceptions should bubble up, which probably made the story even worse with errors as return values.
https://news.ycombinator.com/item?id=45530486
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.
AI agents can only reason about a certain number of things at a time. Time (and tokens) they spend reasoning about how to create a stack calling convention in assembly is time they don't spend reasoning about business logic.
IMHO there's never been an overall "ideal language", and there still isn't, it's just about the right tool for the job. The only thing LLMs change is that you don't need to give quite as much weight to how well you know a particular language.
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!
I agree with the article, but there's one thing Go has that doesn't help LLMs: structural typing. An LLM has to grep a little more to understand which interfaces a struct implements.
The LLMs will continue to get better at language stuff, better to tell them what to do on the basis of non-language stuff.
Stuff like like which compilation targets are available, or which has the most mature library for what you're doing, or maybe you're integrating with something that anchors you to a specific interface type.
Anchor your language choice to the problem you're trying to solve and the people you're trying to solve it for.
99% of my projects are in NodeJS as web apps, so Javascript is king, my coding agents are in Node too, plain, boring, beautiful javascript, not typescript. Yesterday I needed a Rust project and my agents delivered so no need to change from JS
I have also aligned entirely on Go. Fewest glitches for AI generated code. compile targets are for every platform you need. Very high performance. Doesn't seem to burn tokens as much as other languages.
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.
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.
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:
Purely anecdotal, but my experience has been that LLMs generate low quality python code. It's spaghetti code on par with what I've seen when companies I worked at tried offshoring development. It's basically what you get when you give bad or incomplete specs to a team of inexperienced programmers with poor development practices. It's usually good in small chunks, but it gets extremely sloppy as the scope of work increases and more decisions are introduced. Interestingly, I've seen LLMs generate good clojure code.
My guess is it comes down the the training data more than anything else, although I suspect functional languages will fare a little better. At least that's been my experience. There's undoubtedly a ton of python code in the training corpus and portions of it are of dubious quality. Niche functional languages likely have a smaller training corpus where a larger portion of it is better quality.
I think it's far from being this simple. What you're describing is productivity on a greenfield project, but what's really interesting is productivity when working on an existing large codebase, with existing conventions, architecture decisions (or lack of)... How easy is it to do a product pivot, to rearchitect for performance, etc etc etc.
It is unclear to me though how much of your expectation might be set by the training dataset.
For example, Python and Typescript have the most amount of codebases and training being done on. So I feel as if that plays a part into the overall thing.
Languages which are more niche have genuinely hard times (Try arturo lang for example), so it depends on a lot of things/nuance, or well that has been my experience trying something recently.
My personal opinion is that if each language has the same amount of training. Golang comes close but the first might be Elixir. I have seen Elixir language perform really well with LLM's with magnitudes less training dataset. There have been some studies which had Elixir as the number one language for such tests iirc.
Gleam is a new addition as well and I feel as if it could be good and its another interesting option as well with more type-safety and an interesting language overall.
Never tried Elixir myself but came here to say the same thing. Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/
The readability is a plus at the same time if I target Rust and build it modular with lots of tests and io pure modules. The review part is not as important if the AI reviews it from various perspectives. With rust I get so much better performance and efficiency.
Go was designed as a systems language. They turned it into an applications language too, I'm guessing because turns out the greenthreading was uniquely good for that. But now it's awkward. The pointers and errors are not how you want an app lang to work. And LLMs struggle with error handling even more than humans.
Even as a systems lang, the error syntax is the worst part of Go. Can they at least put the ?/! syntax like in Rust instead of this "if err != nil" spam every other loc?
Yeah same but I always allow https://github.com/spf13/pflag because e.g. Claude really struggles with the default flag package (and it's shit in general)
1. The syntax surface is smaller, allowing less LLM "creativity;
2. The error handling is mechanical, which LLM clearly prefers (LLM is already trigger happy about writing tons of throw / try...catch.. in other languages, doing tons of `if err` is just in it comfort-zone).
The only problem I have with LLMs in Go is that they also make a lot of concurrency mistakes, in the same way as people. It's easy to fix though, just by asking to double check the code
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.
Yeah, no. Its good because LLM likes to copy paste things instead of doing code reuse which is the true go way of doing things. Imo, its hard to review Go code, probably why Go is yet to have a single correct Raft implementation.
I never seen k8s cluster that doesn't have some go process that segfaults once in a while because someone forgot to check `err`.
Only good thing got going for it is its vulnerability scanner. Which will be working overtime with all that "AI-assisted software engineering"
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.
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.
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.
Let me share a hot take. I am deliberately taking this somewhat to the extreme, so please attack the idea not the person. Looking for thoughtful replies and good counterpoints, rather than language zeal.
Let's assume that you need to write a program with a given set of requirements, and that you have a magic wand that can instantiate a high quality implementation of the program in any programming language instantaneously and for free. My hot take is that you would not want to choose Go, and you would likely want to choose Rust.
The Go implementation will have higher memory and CPU consumption due to garbage collection, while still being subject to memory bugs. The Rust implementation would be as efficient as possible on the given hardware with minimum memory/CPU, and it would be immune to memory bugs.
In my view, the biggest challenge with Rust, and where Go wins, is the relative difficulty of writing in Rust as the language is significantly more complex. With LLMs this is becoming a non-issue, and we are getting ever closer to having this magic wand (I'd argue that for smaller programs the wand already exists today). The article advocates that Go has excellent readability. I agree that Go has trivial syntax, but given that it's so verbose, I actually find it easier to read Rust code. Its higher expressivity allows you to see the higher level intention of a piece of code more easily.
Many of the other benefits the article mentions for Go are equally applicable to Rust: compiler error messages are super detailed and a great help to coding agents, auto-formatting, a great language server, and a package ecosystem.
I guess from a pure language POV, one might argue that rust leaves humans with more opportunity to add abstractions that are too clever and too hard to wrap your head around. That doesn't feel like a strong argument, though.
Then there is of course the ecosystem, where go maybe has better libraries for some stuff (while rust may have better ones for other things).
In my opinion, the by far biggest problem Go has is called ...
Google.
Now one can say that a programming language and its design or
usefulness is - or should be - decoupled from the company
developing is. I am not opposed to this, in theory, but Google
goes way too much on my nerves these days. And I am hardly the
only one here.
I am not saying this is a rationale used by many other people
either, mind you, but Rust has been taking strides (not that I
am a huge fan of it either but for different reasons) and it
seems to me as if Rust has finally now more momentum than Go,
which I find interesting. Again, this may be a correlation
rather than any causation, but I can not help but notice it.
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.
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.
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.
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 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 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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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...
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...
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.
> 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.
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!
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...
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?
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?
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.
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.
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.
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.
> ...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.
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.
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
though the letdown with Java is the wider ecosystem that makes unwarranted contraptions out of simple things.
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'm not anti-go. I've had some bad things to say about it, but I could do that with any language I've used. It just hasn't emerged as a tool I feel delivers enough value to be the realistic choice. I've used it for a few small things, and it does what it says on the tin. The existence of nil, the primitive error handling and the years long misguided resistance to generics were a problem for me. Two of those still are.
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.
> 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"?
It's anecdata and maybe, MAYBE, a spreadsheet. Or a Google Form somewhere.
Your other point is even more interesting, e. g. "before AI, Go sucked and nobody used it" - now this may be an exaggeration or simplification, but it is a great observation nonetheless, because Google suddenly tries to connect Go with the rise of AI, almost as if AI could not have risen without Go, which is indeed very strange as an argument to make by Google here. This also reminds me of Google promoting Dart/Flutter before giving up on this and preparing to send it (eventually) to the infamous Google graveyard at some point in the not-so-distant future.
I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests.
Tokens are cheap, surprises at runtime are not. So a super anal compiler is what I want. I've looked at lean4 too as the logical next step but not confident I can guide an LLM competently enough for that.
My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code. I've thrown a lot of gnarly C and Ruby code at all sorts of LLMs and they have only gotten more and more impressive as frontier models have gotten stronger. With Agda, they're like "hmm, tricky" whereas for me it's an impenetrable fortress. I've asked them why they find Agda so much more difficult to write (and why they have to iterate and reiterate many many many times until they get to a destination whereas they can one-shot and two-shot C and Ruby and they tell me its the multiple competing constraints. GLM is hilarious, it flat out refuses to write Agda code but it reads it well enough. They all read it well enough. Fable is obviously great at it. And Opus 4.8/5.0 are great (if they stay on track and don't sneakily go their own way) but they're too annoying to talk to. On balance Kimi K3 is the best balance of not annoying, relatively cheap, and strong -- great model all round tbh.
So yeah, interesting I've discovered the limits of their ability coding-ability-wise. None of them are that good at designing/aesthetic judgment/architecting so thankfully they still need me in the loop.
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.
It would be neat to see a matrix of compile times vs. language features, showing things like:
- Bounds checks
- UAF prevention
- exhaustive enums
- test speed
But I think even among those the subtleties would make a fair comparison impossible.
Anyway I think this is all very nuanced, and anyone proclaiming language X is the language to use in 2026 lacks the experience/knowledge to consider these trade-offs and can safely be ignored.
The counter argument here is that these checks cause slower compile times and were designed to prevent common mistakes humans make.
If models get good, they may not need the same checks human written code needs. For example, frontier models already will virtually never produce a typo.
Humans need time to think, but a model’s bottleneck is in how quickly it can verify its work. Slower compile times hurt a models ability to iterate.
I don’t think we’re there yet (and we may not get there). But there is an argument to be made that languages with faster compile times may be better for LLMs in the long run than languages with strong checks but slow compilation.
"After 7 years in production, Scarf has reluctantly moved away from Haskell"
And moved to Python, pretty much for the reasons you stated
I was curious about this so I dug further, and by the author's own admission, they've only made the switch for basic CRUD logic without performance needs, not their core services: https://news.ycombinator.com/item?id=48865986.
It's also pretty unsurprising, given what we know about LLMs' style transfer abilities, that transferring parts of an existing Haskell codebase into Python would avoid a lot of the errors and pitfalls that codebases originating in Python are known for. My experience coming from writing lots of Python is that this does not continue to hold true as you let the agents loose on your Python codebase.
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 had to write a moderately complex program. I didn't want to do it in C, and I didn't want to learn Rust.
- So I spent roughly about 2 hours becoming familiar with Go and playing around in Go playground. I decided that this would work.
- And then I got started on my program and I was immediately productive and that software is still running today, along with all the other stuff I've written since then.
Programmer productivity is excellent with Go. And it has a thriving ecosystem. Of course, some things could be better, but I don't really have much issue with it's error handling or types.
Sounds like you made a decision right there. The rest is just retro-justification, not a logical argument or comparative between options. It works for you, good.
The only logic that matters most of time is business logic of solution serving problem statement and not logic of choosing a technical stack.
That's the main selling point, with a secondary point that it statically compiles so you don't have to do a whole Python/JS distribution thing for CLIs.
Java feels like the closest contender here, although it really sucks for CLIs due to start up times. I don't think it's the easiest to learn either, but I've never tried all that hard.
It only really makes sense to me at org-scale, though. I think you raise a very good point for individual projects, I too normally don't choose Go for that (unless I need compilation to make distribution to myself easier on corporate laptops).
I guess if you consider enough attributes or "dimensions" then any programming languages will be the furthest in some direction, including Go.
Listing particular sets of preferences for which Go is not optimal is not sufficient unless you can show the list to be exhaustive.
This isn't an exhaustive proof as no language will every be fully Pareto optimal in practice (it's just not possible, there are too many dimensions), but I'd argue it's at least somewhat close.
Go is similar to popular languages like C, JS/TS, & Python. And so, easy to get started.
> highly value a type system that catches errors
Probably these folks already use even less popular ML-style languages like OCaml & Haskell; or (comparatively) obscure ones like Agda, Idris, & rocq/Coq.
LLMs fail to produce bug free concurrent code even for very simple cases.
Golang lacks the ability to build descent abstractions, not even mentioning the wild west of additional tools and libraries needed for non trivial micro services.
For me it is a red flag, that LLMs allow people to produce more bad Golang code faster. This is only optimization for companies which can afford enough software developers to review the excessive amounts of code needed to solve trivial problems in Golang, which are builtin in every descent programming language and/or framework.
Use LMMs and use the right programming language. This might be Golang, but most probably it is C#, Java, Python, Ruby or even PHP. (Or Rust, C, D, ...)
| 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.
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
The article is assuming you're doing some basket of general programming tasks. You can use Go for all of them. I personally wouldn't.
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.
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
Right. Go is a language, Tinygo is an implementation. We already discussed that, though.
> 10KB still matters a lot in a lot of minimal target/usage scenarios
But if the LLM cannot wrangle the language, better isn't an option. I mean, you can still write code by hand, if budget allows, but since we're explicitly talking about using LLMs that is irrelevant.
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.
~ Oreo cookie company.
- 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.
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
I have found exactly the opposite to be true: as always, people think they can write safe concurrent code without the machine checking them and end up getting it completely wrong in lots of subtle cases. Except the problem is now much worse because you're not even writing the code, or in many cases, reading it. I prefer a language with a type system that saves me from the review burden of closely checking (and pretty much always finding issues in) concurrency invariants. And even tells me a bit more beyond that about what the code is intended to do.
That's a pile of bollocks, pardon my French. Source/proof?
And to the contrary:
I've been working on a TS codebase that calls into C++ native/wasm-compiled code for six months now. The code is mostly LLM written.
Over these last six months we had four use-after-free and two other ownership-related bugs in LLM-generated TS code.
Whereas we had zero issues of any such kind with LLM-generated Rust code that sits in another two native/wasm-compiled metacrates we use.
LLMs are not much better at ownership tracking than humans.
Especially if resource acquisition and release are far apart in code and/or somehow nested/stacked/non-straightforward.
If the premise of the article is true, and I think that it is, that's quite the downside for AI coding with go. The premise being that reviewing now plays much more of a role than writing.
Personally, I'd rather review, say, a ruby oneliner that extracts specific row values from a csv file with filter_map, compared to 40 or so lines of go, many of which I'd have to check individually for possible mistakes.
IIUC Fuchsia uses Dart mostly for UI stuff and Go has never really tried to be competitive there? I don't see much of a reason to suppose this is a serious bottleneck to Fuchsia adoption, as opposed to the obvious reasons why it's hard to displace an existing OS with a huge install base.
Citation absolutely needed.
I have some very heavy criticism for Zig technically, because their whole thing about "no hidden control flow" becomes "shove all the hidden control flow into a second hard to debug runtime that runs at compile time", and manual allocation for everything is incredibly tedious and hard to keep track of in production code. I mean, C++ wasn't ALL wrong, there was a reason that templates exist in the first place, and having the entire generics model be just comptime isn't really a decision I agree with. The way I see it, Zig would probably find a niche as a language that configs C/C++ codebase at compile time instead of the C replacement they want it to be.
There are two more languages I have in the Oct repo, SDSL-V for SPIR-V shader/compute kernel authoring and Concept/Vulkan because the 20k line C Vulkan Prometheus runtime for GPU compute that we built is getting kind of unmaintainable even by AI that making up a new programming language to strangler fig refactor it is honestly the least bad option.
Each have their trade-offs, both can support native compiled application code. Some architectures are easier to review and code in golang, but others go much better with Javas richer ecosystem and better composability.
Joking aside, as much as Go's stdlib and tools do the heavy lifting here, Go's verbostiy and expressing simple things in lots of lines worked against me most of the time.
Maybe my problem is I'm using a language with exceptions, so trying to go against the statistical grain, with return values, is just too much.
Even then, it does seem like LLMs at least a year ago had difficulty understanding that exceptions should bubble up, which probably made the story even worse with errors as return values. https://news.ycombinator.com/item?id=45530486
> 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.
https://webassembly.github.io/spec/core/text/index.html
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!
https://news.ycombinator.com/item?id=47222270
203 points | 5 months ago | 304 comments
Pichai wants to eliminate engineers, and DeepMind wasn't fast enough or too noble for it. Now people need to be propagandized for their obsolescence.
Stuff like like which compilation targets are available, or which has the most mature library for what you're doing, or maybe you're integrating with something that anchors you to a specific interface type.
Anchor your language choice to the problem you're trying to solve and the people you're trying to solve it for.
Might be a skill issue, but I got frustrated with it on new projects constantly.
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/
My guess is it comes down the the training data more than anything else, although I suspect functional languages will fare a little better. At least that's been my experience. There's undoubtedly a ton of python code in the training corpus and portions of it are of dubious quality. Niche functional languages likely have a smaller training corpus where a larger portion of it is better quality.
For example, Python and Typescript have the most amount of codebases and training being done on. So I feel as if that plays a part into the overall thing.
Languages which are more niche have genuinely hard times (Try arturo lang for example), so it depends on a lot of things/nuance, or well that has been my experience trying something recently.
My personal opinion is that if each language has the same amount of training. Golang comes close but the first might be Elixir. I have seen Elixir language perform really well with LLM's with magnitudes less training dataset. There have been some studies which had Elixir as the number one language for such tests iirc.
Gleam is a new addition as well and I feel as if it could be good and its another interesting option as well with more type-safety and an interesting language overall.
This sounds like your personal feelings, not quantification.
Not as fun to write as Python and Nim, but I don't have to write it.
Even as a systems lang, the error syntax is the worst part of Go. Can they at least put the ?/! syntax like in Rust instead of this "if err != nil" spam every other loc?
Prefer standard Go libraries and tools.
80% of the time I can get by without external dependencies (outside of Go's X repository)
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.
If a language is simple, it' easier to generate good code.
I never seen k8s cluster that doesn't have some go process that segfaults once in a while because someone forgot to check `err`.
Only good thing got going for it is its vulnerability scanner. Which will be working overtime with all that "AI-assisted software engineering"
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.
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.
Let's assume that you need to write a program with a given set of requirements, and that you have a magic wand that can instantiate a high quality implementation of the program in any programming language instantaneously and for free. My hot take is that you would not want to choose Go, and you would likely want to choose Rust.
The Go implementation will have higher memory and CPU consumption due to garbage collection, while still being subject to memory bugs. The Rust implementation would be as efficient as possible on the given hardware with minimum memory/CPU, and it would be immune to memory bugs.
In my view, the biggest challenge with Rust, and where Go wins, is the relative difficulty of writing in Rust as the language is significantly more complex. With LLMs this is becoming a non-issue, and we are getting ever closer to having this magic wand (I'd argue that for smaller programs the wand already exists today). The article advocates that Go has excellent readability. I agree that Go has trivial syntax, but given that it's so verbose, I actually find it easier to read Rust code. Its higher expressivity allows you to see the higher level intention of a piece of code more easily.
Many of the other benefits the article mentions for Go are equally applicable to Rust: compiler error messages are super detailed and a great help to coding agents, auto-formatting, a great language server, and a package ecosystem.
I guess from a pure language POV, one might argue that rust leaves humans with more opportunity to add abstractions that are too clever and too hard to wrap your head around. That doesn't feel like a strong argument, though.
Then there is of course the ecosystem, where go maybe has better libraries for some stuff (while rust may have better ones for other things).
Of course it can’t just be simplicity, it has to be “opinionated” simplicity. Rolls eyes.
Google.
Now one can say that a programming language and its design or usefulness is - or should be - decoupled from the company developing is. I am not opposed to this, in theory, but Google goes way too much on my nerves these days. And I am hardly the only one here.
I am not saying this is a rationale used by many other people either, mind you, but Rust has been taking strides (not that I am a huge fan of it either but for different reasons) and it seems to me as if Rust has finally now more momentum than Go, which I find interesting. Again, this may be a correlation rather than any causation, but I can not help but notice it.
If you're going to have an agent write most of your code readability is very important.
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.
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.
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.
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.
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.
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.