Go is an ideal language for AI-assisted software engineering

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.

What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go.

Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squinted eyes. But the teams I work with are working on sprawling, evolving software where the compiler saying “hey, that’s not a valid Widget” would be extremely useful and save much heartache.

An LLM does a good job of “checking” for other uses and “checking” if everything is going to work correctly, but - supposedly we’ve committed the concept to code so that the compiler can actually verify it - and Go intentionally permits invalid states of structs. This makes Go a fundamentally problematic language choice for the kind of software I work with teams on, LLM or not.

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.

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, ...)

If I care about performance, use Rust.

If I care about iteration speed, use TypeScript.

If I want a script or numerical code, use Python.

LLMs are better with Rust because the more expressive type system provides stronger guardrails especially when writing multithreaded code. Go is almost the worst conceivable design of a programming language for LLMs: powerful but weak guardrails. Only C and C++ would be worse.

LLMs don't struggle with the low-level lifetimes like humans do. They struggle with the high-level view because of limited context windows. That's why you want a powerful type system to enforce those global constraints. Go ain't it.

| Go is Readable / Go is Maintainable

It's true that Go, as a low-magic language, tends to be very same-y looking across projects, which is incredible for being able to reliably understand your dependencies' source code. And its tooling is world-class. I love this about Go.

But in practice I've found that, working in a monorepo with multiple teams, contributors that don't have cross-team legibility as a priority will just write SO much more code. And with business logic, often the fact that I can read the code on a line-by-line level doesn't matter if I don't understand the wider context to know how something might effect spooky action at a distance.

Pre-agents, I witnessed a fast transition from a codebase that I could mostly hold in my head to one where large swathes of it had been written and rewritten until they were unrecognizable to me. Now we have agents and, since they are still mostly not good at software engineering in-the-large, the process of knowledge debt accumulation (and ofc tech debt accumulation) in a codebase accelerates tenfold without concerted effort in the other direction. Go being easy to read does not intrinsically help with that.

A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go--that's my argument.

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.

Having said that: my opinion is that LLMs thrive by working in a tight loop. Unlike a human, they thrive with more and tighter constraints (and the better models are obviously far better in this regard).

I want to ditch the things that made writing code easier due to the limitations of humans, and embrace something that an LLM can leverage for better results. For me that means: an especially rich type system, (ideally pure) functional code, efficient systems-level performance and leanness. Good error messages that guide the LLM incrementally.

Go does not provide much in the way of those 3 desires, so calling it "ideal" with nothing aside from anecdotes to back that up is not compelling.

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

~ Oreo cookie company.

1. JS is mem-safe, single-threaded, and there are lots of training data. Easily my first choice. I'd put Python here as well, although I don't like it personally. Both should be used with "avoid external deps" in your AGENTS.md

2. Go might be a good second choice. Simple language, IMO good primitives for concurrency, well-designed std, therefore smaller potential for supply chain attacks.

3. Elixir/Erlang, little training data but rising. Safe language, safe concurrency, immutable, scalable, there are some many advantages... It has been avoided because it's different but that could change drastically in the age of LLMs.

4. Rust is probably next choice, along with C++, because while Rust is safer, the language is quite complex. C might be here too, there is a lot of training data, but every project is different and the language is very unsafe.

5. Zig, I really like the language, but it is terrible for LLMs, mainly because it's constantly changing, and the std is also under-featured and IMO weirdly designed. It's a fun language for hobby hacking, which I believe is not going anywhere, it's just not going to be something you will be payed for.

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.

https://github.com/SteveCastle/loki

I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie. The most important task of a code formatter is to break long lines; it doesn't do it. It doesn't even have an option to do it!

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.

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.

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.

I’ve always disliked it for that reason.

In roughly November of 2025, “software developer” stopped being a position that humans fill directly. We all became architects and technical managers. Even the most complex code is now pair programmed with an AI.

I’ve chosen go for all new backend work since January 2026.

Development is now about good architecture that optimizes for locality of reasoning, rock solid testing, and categorizing risk on modules to decide what needs human pair programming and detailed review, and what can be safely vibecoded and left to AI to manage.

Frontend dev is now vibecoded directly by PMs at my organization within very specific and heavily enforced architectural constraints. The quality of work went up substantially because the experienced devs now just focus on the rules and review for the fronted codebases, while the PMs focus entirely on UX.

It is a strange new world.

These have been my and friends' observations since LLM-assisted coding started picking up steam. Go's simplicity, consistency, stdlib and tooling seem to make it very reliable for LLM generation, and it was especially true during late 2025 / earlier this year when frontier models weren't as strong; might not be as noticeable now.

https://webassembly.github.io/spec/core/text/index.html

That being said, the whole thing about go being "readable" is a little bit of a two-edged sword. Sure, it's straight-forward to read, but it's pretty verbose. And agents are good at producing a lot of text. The problem with reviewing go code for me is to see the forest for the trees. Subtle misunderstandings often hide in the vast amount of code that you have to read through while keeping the whole context in your head.

> 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.

For AI I use python+rust. I develop code in python (mostly AI-driven these days) and then have it port to rust for speed. As always, extensive testing (much of which is manually inspected to make sure it's logically consistent with the design and contract).

Anyway, it turned out that Go ironically makes it difficult to collect per-test-case coverage data. In spite of the standardized tooling it looks impossible to write a standardized collector that would run on most codebases. In hindsight using another language would have been a better choice

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

My background is in data science and MLOps, where Python rules. But the focus is now less on building new AI models, and more on building the infrastructure and API calls with AI Agents. Go has a great async model, stellar performance, amazing tooling ecosystem, and far less ways of doing things than Python.

I except grow to become more and more popular, as our LLMs are now writing most of our code. Between a 50 MB portable binary in Go with 10x performance, and a 5 GB venv in Python with lack of proper parallelism, the choice is easy.

I think partly it's because the training set contains a lot of JS, but also because complex software written in JavaScript must have impeccable architecture in order to exist at all.

It's rare to encounter a complex, functioning JavaScript application with bad architecture. I've never met any engineer smart enough to maintain a large spaghetti-code JavaScript project.

On the other hand, I've seen horrible TypeScript projects. If it wasn't for the helpful type annotations, no human being would have been able to maintain it.

Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/

And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program.

The first tests I have seen seem to confirm this. One recent example:

https://danluu.com/pl-tokens/

As a long term C programmer and start using go from the early days, really love it's rich ecosystem and portability.

Nowadays, for any backend code, i just let agent to write using go, and for resource constraint environment, i just use rust.

And both have good C interop, and good ffi interface to hook into more higher level language such as Swift/Kotlin if one wnat to develop some mobile Apps

But perhaps that's also a side effect of maybe having prior opinions about go and the number of foot guns I've let off

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.

The thing about Go, which some have complained bitterly about and others (and TFA) have touted as a strength, is the limited expressiveness of the language (hence my remark about generics!) This is what restricts the number of abstractions in Go code, leading to more verbose but much simpler code all around. Choosing between simplicity and expressiveness is a matter of taste, but also organizational dynamics; for larger organizations which require a large amount of context shared amongst a large pool of employees, it's better for the code to be simpler and locally understandable. As TFA indicates, this has been a guiding principle for Go.

I think what is happening with AI coding is similarly related to context. Consider that while more expressive languages enable more abstractions, they can make the code more concise, but critically, this also spread the logic around. E.g. in large Java codebases you will find deep inheritance hierarchies with class and method definitions spread around a dozen different source files and JavaDoc references.

This necessitates finding and stuffing a lot more information into the context for any given task, a lot of it irrelevant and all of it more complex, because it requires making multiple hops of reasoning to figure out the logic. On the other hand with fewer abstractions, all the necessary code and logic though verbose is right there. It's much easier for a human and an agent to follow that code.

The difference is a human gets tired reading a lot of code, which is what pushes us to devise more abstractions, whereas an AI does not get tired.

I get the sense that if a context is stuffed full of highly relevant information, the agent will perform well regardless of the size of the context window. But the moment you pollute it with noisy irrelevant information, performance will drop regardless of the size of the window. (There are some papers showing this effect IIRC.) Hence simpler code, as encouraged by simpler languages like Go, are more amenable to tighter and simpler contexts, which work better for AI.

Rust or Nim are really the ideal targets for LLMs and will continue to grow. As LLMs write more code and as humans review less, it will be more important to have confidence that your code doesn't run into a weird one off runtime heisenbug issue.

Go is quite good from a token usage point of view. Rust is not so good due to the complexity of the language.

I see AI agent programming language choice as only two now: Go or Rust.

Go for most systems, Rust for high performance.

Prefer standard Go libraries and tools.

80% of the time I can get by without external dependencies (outside of Go's X repository)

Only formal verification kernels will solve the issues discussed. It cannot make your c design correct, it can only verify the code itself whatever is written.

Point is, this is solved known, and everyone get enough ahead made the jump long time ago.

Also, sorry, standard libs are almost always forbidden now. They can’t be trusted. Anything important is written from scratch.

Why? Go and others standard libs are “broken”, meaning they are half assed lightly defined not purpose built for a developers job. They are general. That was good once upon a time. Not anymore.

Use Go and attempt JSON Canonicalization. You can’t. It’s valid. Proven so. Why? Stdlib json parsing is normalizing and lossy. Fail closed. Float to string violates ecma 262 for floats. Every single action taken is in violation. This is the stage of today’s programmmkng. Developers who don’t even understand what “correct” is. https://lattice-substrate.github.io/blog/2026/02/27/shortest...

The issue is NOT AI LLM, it’s poor development by HUMANS. The same problem we always had.

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 I'm reading the source then Go or Zig.

Not as fun to write as Python and Nim, but I don't have to write it.

IMO the concurrency model in go is the biggest reason, I'd hesitate to use it.

Managed memory, single threaded with lots of lints and good tooling. Is IMO what can raise my confidence in code, before I even review it.

Granted golang has a really good stdlib. Which counts for a lot.

https://news.ycombinator.com/item?id=47222270

203 points | 5 months ago | 304 comments

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.

I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie.

If a language is simple, it' easier to generate good code.

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?

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"

Poor correctness guarantees, especially w.r.t concurrency. Nil pointer. Why.

LLMs are like a magnifying function. Whatever you put in you get back 10x over.

In the case of Go, in goes verbosity, Nil pointers, poor concurrency and synchronisation primitives (or poor performance of the safe ones, leading to sync.Mutex everywhere anyway). Also Go prioritises local readability over global understandability which is a poor tradeoff for LLMs with limited context windows.

So the LLM generates absolutely monstrously huge amounts of very hard to review very likely incorrect code.

No thanks.

Rust > Go.

In goes powerful, terse type system. Strong correctness guarantees not just around memory and pointers but also data races. A tendency towards using the type system to model invariants instead of relying on procedural guards and runtime assertions etc. Producing denser code is an LLM feature, it increases context window efficiency. Similarily the typesystem takes something that the LLM can spend a bunch of thinking tokens on to create a powerful global constraint. This fixes the global reasoning/context problem by pushing it back onto the typesystem.

Depending on the quality of your robot you will get different quality of code out but the ceiling is much higher. With Go better robots don't help much, even the highest quality robots output insanely verbose Go. Sort of just like with people... sort of like the language was designed as a lowest common denominator tool...

For a seasoned Rust programmer the output probably won't be hard to review, it will be easy to look at the types and either say "yeah that should probably be correct" or "no robot, do better".

You simply can't actually review the output of the slop cannons with Go, there is too much, looking at a struct tells you almost nothing about how correct the thing likely is, etc. The tests don't help either because there is going to be 10x the usual amount of those too so trying to review those for correctness is the same Sisyphean endeavour.

Of course it can’t just be simplicity, it has to be “opinionated” simplicity. Rolls eyes.

> Go solves this through unyielding consistency.

What? Why is the word "unyielding" used here? What was the point of generating this AI article on the google blog post?

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.