With Go it will increasingly become that one has to write the design doc carefully with constraints, for semi tech/coder folks it does make a lot of sense.
With Python, making believe is easy(seen it multiple times myself), but do you think that coding agent/LLM has to be quite malicious to put make believe logic in compile time lang compared with interpreted languages?
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.
Well if it's a choice between these 4, then sure. Not sure that really suffices to qualify Go as "the" best language for agents
- 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.
I've been successful with each, I think there's positives and negatives to both, just wanted to mention that particular one that stands out as making it relatively more pleasant to work with.
I’m not sure about cargo audit specifically, but most other security advisories are package scoped and will warn if your code transitively references the package, regardless of which symbols your code uses.
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.