Pull up your agents folks, I'll convince you why Go is the best language for them.
I have been working with Go for the past 8 years in a professional capacity. I’d like to make a case here about why Go is the best language to work with using AI agents.
Background
I have worked with PHP, Go, JavaScript, and Python in a professional capacity for over 10 years now. Most of my career has been building web services, and I have been building Bruin over the past few years, which is primarily a CLI tool written in Go.
Bruin is an open-source ETL tool, and as some of you might know, the data ecosystem loves (or used to love?) building tools in Python. There are a ton of available libraries, data people are familiar with Python, so it is easier to get contributions, and it is easy to find Python developers compared to Go. When we started building Bruin, we had to make a decision: do we build the CLI in Go or do we build it in Python?
We had a few constraints that we needed to take into account before we made a decision:
- Bruin is a data orchestration tool, which means there’ll be a lot of stuff that needs to run concurrently.
- Bruin needs to interact with a lot of different systems, such as language runtimes or external APIs for data platforms; therefore, we need a decent ecosystem around the language.
- Bruin needs to be fast. It is a CLI tool, and we wanted to use it with various systems, such as VS Code extensions or local UIs as a backend, and it needed to have sufficient performance.
- Bruin needs to have predictable error handling paths for all the different systems it has to integrate with, and inform the user explicitly.
- Bruin will run on users’ machines, which means it should be easy to support various operating systems and architectures.
On top of all these constraints, there was a more subjective constraint as well: I would be the primary contributor for quite some time, and it had to be a language I enjoyed working with. Joy and energy is one of the rarest resources a small team can have when building large projects, and I felt it was crucial that I did not dread the tech stack we used.
In the end, we decided to go with Go. It ticked a lot of the boxes, and while having some drawbacks, such as a lack of libraries for certain data-related tasks compared to Python, it fulfilled the most important requirement: I seriously enjoyed working with Go. This joy allowed me to contribute thousands of lines of code before agents were a thing, and it kept us going for quite some time. Part of me was scared that I made a strategic mistake by choosing Go since we had to build quite a lot of stuff from scratch; however, my intuition told me that the speed and DX advantages of Go over Python would bring us further advantages in the long run.
I had absolutely no idea that agents would become a thing, but I believe our intuition put us in a pretty lucky spot when agents became a thing. I’d like to touch on some of the advantages of Go when it comes to working with AI agents to write software, and why I believe Go is the best language today for agents.
Go is compiled
Agents spit out tons of lines of code. Whether or not you call them intelligent in that regard, they produce very believable code, code that usually looks correct. That’s where the first challenge starts: how do we make sure the code they produce works?
One of the easiest ways of ensuring that is by using a compiled language. Strong typing, static typing, whatever, I always mix them up, which allows AI agents to iterate on the code they produce until it is correct to a certain extent. This does not mean that the code does what it is supposed to do, it just means that the code is exempt of certain subset of bugs with regard to using the wrong types or arguments. The code that compiles gives you the guarantee that, as far as the language standards go, the code that has been generated is syntactically correct.
While compiled languages have been around for a very long time, there are not many high-level programming languages like Go out there. There is Rust, obviously, which has very different dynamics and target usecases than Go, and I believe Go wins over Rust for an AI agent:
- Go’s syntax and concepts are simpler than Rust's.
- Go’s type system is not as sophisticated as Rust, allowing the generated code to be closer to a shared idiomatic way of writing code and simpler to understand for humans.
- Go compiles faster than Rust, enabling a faster feedback loop for AI agents.
- There are far more Go code out there than Rust, allowing models to generate better code in Go than Rust.
This is more of an intuitive thought than backed by real data, happy to be corrected here. While there are many more compiled languages, in terms of ease of use, community, speed of iteration, and simplicity, Go definitely becomes a clear top player there.
Go is simple
Maybe this should have been at the top? Anyway. Go is a very simple language. If you have any proficiency in any programming language, reading Go code should be trivial to you. You can immediately understand what the code does and reason about it. This means that if your agent generates a ton of Go code, you'll still be fine.
Another advantage here is understanding the design choices: while agents are able to generate very good code, they sometimes jump into weird design decisions and continue down the rabbit hole. The simplicity of the language helps a lot here to figure out where the agent is moving towards.
With that being said, I am a strong believer that we are not going to read code much in 12 months, and therefore could also make the argument that readability or simplicity won't matter much in the future, which could be true. Even in that case, I'd still like to be able to jump around the code if I ever wanted to.
Go has a way of doing things
This is one of the things I love about Go: it is an opinionated language with clear guidelines and tooling to support that. There is a standard way of running tests, formatting code, or building binaries. Go, even though it is hated by many, also has a particular way to deal with errors. Like it or not, it certainly advertises a way of doing things that makes it easier to write idiomatic Go that can be worked on by many people and agents.
Take JavaScript, for instance: there are a billion different ways of doing things. Every time I hop on a JS project, I have to discover the tools they use, learn how they work, and try to familiarize myself before I can be productive in it. Everyone has different opinions around how to format code, how to distribute packages, or even how to import libraries into a script. I find the state of JS to be a hot mess, to be frank, but I am digressing.
Go avoiding these problems surfaces a significant advantage for AI-generated code: the models know how to work with Go based on all the code they saw in their training data. Go code is generally very similar to each other, and the standardized tooling allows agents to use them effectively.
Ask an agent to format a JS code, and it’ll import a new tool and try to make it work. Ask it to do the same with a Go codebase, and it’ll just run gofmt and be done with it. The same goes for writing unit tests or building binaries.
Building cross-platform Go binaries is trivial
I don’t think this would resonate with you much if you are writing software that just runs in a specific environment, but if you write things like CLI tools that you have no control over where they run, then Go becomes the perfect choice. This point holds regardless of the AI stuff, but I think there’s an interesting effect of this with AI agents.
Cross-platform support being a first-class citizen in Go means that running all of our tests, be it unit or integration tests, across environments, on every change, becomes trivial.
You know what this means?
You guessed right: this means AI agents can validate their work quickly and ensure they didn’t break any existing functionality. Obviously, this is not a win on its own if you are not writing tests, but the fact that you have the ability to just throw the same commands on another OS and validate the code is big.
Background agents & Go
Like many others, we have been experimenting with background agents as much as we can. Be it triggering Cursor to tackle a change via a Slack message or handing off a local session to a remote one, we slowly decouple ourselves from having tight control over the environment in which our code is being built and run.
This is a small one, but Go’s cross-platform advantages shine here as well: the same code will produce binaries that run on Linux, Windows, or macOS the same way, and the whole process of working with Go code is standardized across environments. This means I don’t care where different agent platforms run in or if a sandbox provider can handle our dev dependencies; everything just works.
Agents know Go
This is likely one of the advantages that would go away over time as well, but as of early 2026, agents produce valid Go in one shot 95% of the time in my experience. I have absolutely no data whatsoever on this, although I struggle a lot more with Python than Go. Models know the libraries, patterns, and best practices in such a way that it becomes almost trivial to build a feature in Go once the direction is settled.
I think part of this is not that there is a lot of training data for Go; if that were the case, Python would have definitely won that. There's usually a single way of doing things in Go, whereas there are 20 different ways of doing the same thing in Python. If we said training data in Go vs Python, Python would win, but in practice, it seems more like training data in Go vs training data in Python for this particular library, and there Go wins.
I bet this advantage will disappear over time, if it hasn't happened already, due to models getting better and training data including more and more examples of other languages, such as Rust, and I definitely lack the evidence to support my claims here; therefore, treat this more as vibes.
I believe programming languages are going through a weird phase where a lot of the stuff we cared about in the past doesn't seem to matter anymore. It seems like humans will write less and less code by hand, and we'll need systems that empower agents to do that well.
I think by pure luck, Go might have landed in a sweet spot of usability, performance, and ubiquity that makes it a very good fit for agents. They write beautiful Go, they run, compile, test, format, and deliver performant software in Go that can be used across a variety of machines. All of these benefits are already available today to anyone who wants to build new tooling: just tell Claude Code to build you a CLI in Go, sit back, and enjoy the result.
Go has given us a lot of power at Bruin recently, thanks to these benefits, and we are doubling down on it. Is Go gonna be the programming language for agents? I don't know. Will there be better languages that are more suitable for agents? I don't know. All I know is that I am productive, my team is productive, and we deliver decent software very fast. And more importantly, I still do enjoy working with Go quite a lot, even with agents.
Read the original article
Comments
I've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it.
Go is an excellent language for LLM code generation. There exists a large stable training corpus, one way to write it, one build system, one formatter, static typing, CSP concurrency that doesn't have C++ footguns.
The language hasn't had a breaking version in over a decade. There's minimal framework churn. When I advise teams to adopt agentic coding workflows at my consultancy [0], Go delivers highly consistent results via Claude and Codex regularly and more often than working with clients using TypeScript and/or Python.
When LLMs have to navigate Python and TypeScript there is a massive combinatorial space of frameworks, typing approaches, and utility libraries.
Too much optionality in the training distribution. The output is high entropy and doesn't converge. Python only dominated early AI coding because ML researchers write Python and trained on Python first. It was path dependence, not merit.\
The thing nobody wants to say is that the reason serious programmers historically hated Go is exactly why LLMs are great at it: There's a ceiling on abstraction.
Go has many many failings (e.g. it took over a decade to get generics). But LLMs don't care about expressiveness, they care about predictability. Go 1.26 just shipped a completely rewritten go fix built on the analysis framework that does AST-level refactoring automatically. That's huge for agentic coding because it keeps codebases modern without needing the latest language features in training data or wasting tokens looking up new signatures.
I spent four years building production public key infrastructure in Golang before LLMs [1]. After working coding agents like everyone else and domain-switching for clients - I've become more of a Go advocate because the language finally delivers on its promise. Engineers have a harder time complaining about the verbose and boilerplate syntax when an LLM does it correctly every single time.
Most of these reasons apply to Java as much, if not more.
It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.
By jmyeet 2026-03-0223:46 I agree with most of this. You can learn Go syntax in an afternoon. Idiomatic Go takes a little longer but it just doesn't have the complexity footguns C++ does. But you can shoot yourself in the foot somewhat in Go. I'm talking about buffered channels, which are a mistake most of the time and a premature optimization almost all of the time, and you can explode your program with goroutines. But honestly it's not bad.
Python is an interesting one because it's not always obvious the program is wrong or will fail, thanks to dynamic typing.
But another problem is the Python philosophy since 3.0. Where once backwards compatibility was treated as almost sacrosanct, 3.0+ does not. 2.7 persisted for so long for this reason. But minor releases in 3.x make breaking changes and it's wild to me.
I just wish Go had cooperative async/await rather than channels because (IMHO) cooperative async/await is a vastly superior abstraction to unbuffered channels in particular.
By muyuu 2026-03-0310:24 I'd have said the same a few months ago, but looking at the code quality that the SotA LLMs right now I have to say it's excellent and the problems they have are not with the language but with the subject problems, esp. when they require some complex design that isn't well documented beforehand. They seem to struggle with keeping a world model. Languages themselves, they run circles around humans.
Now the case for Go or for other tightly standardised languages is that whatever the LLM produces, you're likely to be familiar with and make sense of its decisions. With C++, you can generally steer the LLM to refactor things in a certain way but it's extra steps. With Ruby it works surprisingly well too. I'm a lot less happy with their results in Lisp or in Bash/zsh for instance, and mixed results in C depending on what you give them to start - they just come with such random stuff. But it may be just a matter of training set and the relative free-form of those languages.
> But LLMs don't care about expressiveness, they care about predictability.
I think this is true, but it misses a very key point. Go does an impressively bad job at designing APIs that are difficult to misuse, so LLMs will misuse them and will require also writing unit tests to walk through it, just to validate it used the libraries correctly. This isn't always possible (or is awkward/cumbersome) for certain scenarios like database querues.
All of the reasons people argue Go is good for LLMs are more true for Rust. You and the LLM can design libraries to be difficult to misuse, and then get instant feedback from the compiler to the LLM about what it did wrong, and often with suggestions about how it should fix them! This also makes RL deriving from compiler feedback more effective.
This allows the LLMs to reason more abstractly at larger scales, since the abstractions are less leaky (unlike in Go). The ceiling on abstraction screws you here, since troubleshooting requires more deep diving. It's the same reason Go projects become difficult for humans at large scales, too.
By truelinux1 2026-03-0319:03 > 'The thing nobody wants to say is that the reason serious programmers historically hated Go is exactly why LLMs are great at it: There's a ceiling on abstraction.
This lines up neatly with the kind of low‑abstraction systems I like running: 2021 HP PC with i7, bare‑metal‑ish, Crunchbang++, no desktop, openbox window manager. Boots to login in 17 seconds. Terminal front and center — local AI bare-metal inference, no wrapper, ffmpeg, ffplay, etc.
Go’s “no abstraction ceiling” feels like the same preference at the language level: shallow stack, no indirection, and code that stays close to the metal. That’s why LLMs work so well on Go: it’s opinionated, predictable, and there’s usually one obvious way to do things. Personally, I've come to love a LACK of abstraction.
By TrueSlacker0 2026-03-0220:481 reply A lot of those pros apply to c# as well. Which claude and gemeni both do very well with.
By jki275 2026-03-043:38 Preach.
Golang is the best language there is for most workflows that aren't bare metal embedded or have real time requirements, and this is coming from a 20 year+ C++ dev.
By CuriouslyC 2026-03-0223:041 reply This has been studied, Kotlin/C#/Elixir beat it handily.
> Python only dominated early AI coding because ML researchers write Python and trained on Python first. It was path dependence, not merit.
Python doesn’t need dependence to prove its merit. There’s a reason why it is one the major programming languages and was top 1 for a while.
By wuschel 2026-03-038:13 I wonder: How does Rust and Haskell compare to Go when it comes to LLM code generation? I was always thinking that the compiler induced feedback loops could give these languages an edge?
What would be the best language properties for LLM assisted coding?
I think the more you can shift to compile time the better when it comes to agents. Go is therefore 'ok', but the type system isn't as useful as other options.
I would say Rust is quite good for just letting something churn through compiler errors until it works, and then you're unlikely to get runtime errors.
I haven't tried Haskell, but I assume that's even better.
I think Rust is great for agents, for a reason that is rarely mentioned: unit tests are in the same file. This means that agents just "know" they should update the tests along with the source.
With other languages, whether it's TypeScript/Go/Python, even if you explicitly ask agents to write/run tests, after a while agents just forget to do that, unless they cause build failures. You have to constantly remind them to do that as the session goes. Never happens with Rust in my experience.
By jaggederest 2026-03-0219:181 reply Haskell is great, for what it's worth, but as with any language you have to reign in the AI's use of excessive verbosity. It will stack abstractions to the moon even for simple projects, and haskell's strengths for humans in this regard are weaknesses for AI - different weaknesses than other languages, but still, TANSTAAFL
I am trying out building a toy language hosted on Haskell and it's been a nice combo - the toy language uses dependent typing for even more strictness, but simple regular syntax which is nicer for LLMs to use, and under the hood if you get into the interpreter you can use the full richness of Haskell with less safety guardrails of dependent typing. A bit like safe/unsafe Rust.
By siliconc0w 2026-03-0219:27 +1 to Rust - if we're offloading the coding to the clankers, might as well front-load more complexity cost to offload operational cost. Sure, it isn't a particularly ergonomic or simple language but we're not the ones who have to use it.
I've been cruising on rust too, not just because it works great for LLMs but also the great interop:
- I can build SPAs with typescript and offload expensive operations to a rust implementation that targets wasm
- I can build a multi-platform bundled app with Tauri that uses TS for the frontend, rust for the main parts of the backend, and it can load a python sidecar for anything I need python for (ML stuff mainly)
- Haven't dived too much into games but bevy seems promising for making performant games without the overhead of using one of the big engines (first-class ECS is a big plus too)
It ended up solving the problem of wanting to use the best parts of all of these different languages without being stuck with the worst parts.
Was asking on mastodon if people tried leveraging very concise and high level languages like haskell, prolog with 2025 llms.. I'm really really curious.
Exactly. Here's my experience using LLMs to produce code:
- Rust: nearly universally compiles and runs without fault.
- Python,JS: very often will run for some time and then crash
The reason I think is type safety and the richness of the compiler errors and warnings. Rust is absolutely king here.
By squeegmeister 2026-03-0219:152 reply Have also wondered how Haskell would be. From my limited understanding it’s one of the few languages whose compiler enforces functional purity. I’ve always liked that idea in theory but never tried the language
> I think the more you can shift to compile time the better when it comes to agents
not born out by evidence. rust is bottom-mid tier on autocoderbenchmark. typescript is marginally bettee than js
shifting to compile time is not necessarily great, because the llm has to vibe its way through code in situ. if you have to have a compiler check your code it's already too late, and the llm does not havs your codebase in its weights, a fetch to read the types of your functions is context expensive since it's nonlocal.
By bensyverson 2026-03-0219:105 reply I built an agent with Go for the exact reasons laid out in the article, but did consider Rust. I would prefer it to be Rust actually. But the #1 reason I chose Go is token efficiency. My intuitive sense was that the LLM would have to spent a lot of time reasoning about lifetimes, interpreting and fixing compiler warnings, etc.
I absolutely love Rust, but due to the space it occupies there is simply more to specify in code, and more things to get wrong for a stochastic LLM.
Lifetimes are a global property and LLMs are not particularly good at reasoning about them compared to local ones.
Most applications don't need low level memory control, so this complexity is better pushed to runtime.
There are lots of managed languages with good/even stronger type systems than Rust, paired with a good modern GC.
By solomonb 2026-03-0219:23 I've been using LLMs (Opus) heavily for writing Haskell, both at work and on personal projects and its shockingly effective.
I wouldn't use it for the galaxy brain libraries or explorations I like to do for my blog but for production Haskell Opus 4.5+ is really good. No other models have been effective for me.
By lokl 2026-03-0219:40 What about SPARK? Not enough training data?
By chrismanning 2026-03-0219:35 Haskell works pretty well with agents, particularly when the agent is LSP-capable and you set up haskell-language-server. Even less capable models do well with this combo. Without LSP works fine but the fast feedback loop after each edit really accelerates agents while the intent is still fresh in context
I am guessing there is a balance between a language that has a lot of soundness checks (like Rust) and a language that has a ton of example code to train on (like Python). How much more valuable each aspect is I am not sure.
By michaelbarton 2026-03-0222:19 I wonder if then Idris would be even better than that since it has even more typing
I have let Gemini, Claude Code and Codex hallucinate the language they wanted to for a few days. I prompted for "design the language you'd like to program in" and kept prompting "go ahead". Just rescued it from a couple too deep rabbit holes or asked it for some particular examples to stress it a bit.
It´s a weird-ass Forth-like but with a strong type system, contracts, native testing, fuzz testing, and a constraint solver for integer math backed by z3. Interpreter implemented in Elixir.
In about 150 commits, everything it has done has always worked without runtime errors, both the Elixir interpreter and the examples in the hallucinated language, some of them non-trivial for a week old language (json parser, DB backed TODO web app).
It´s a deranged experiment, but on the other hand seems to confirm that "compile" time analysis plus extensive testing facilities do help LLM agents a lot, even for a weird language that they have to write just from in-context reference.
Don´t click if you value your sanity, the only human generated thing there is the About blurb:
