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.

[0]: https://sancho.studio

[1]: https://github.com/zoom/zoom-e2e-whitepaper

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

https://github.com/cairnlang/Cairn

Have yet to find a better choice than OCaml:

- Strongly typed, including GADTs and various flavors of polymorphism, but not as inscrutable as Haskell

- (Mostly) pure functions, but multiple imperative/OO escape hatches

- The base language is surprisingly simple

- Very fast to build/test (the bytecode target, at least)

- Can target WASM/JS

- All code in a file is always evaluated in order, which means it has to be defined in order. Circular dependencies between functions or types have to be explicitly called out, or build fails.

I should add, it's also very fun to work with as a human! Finding refactors with pure code that's this readable is a real joy.

> I have worked with PHP, Go, JavaScript, and Python in a professional capacity for over 10 years now.

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

C.f., from 25d ago:

“Why Elixir is the best language for AI” https://news.ycombinator.com/item?id=46900241

- for comparison of the arguments made

- features a bit more actual data than “intuitions” compared to OP

- interesting to think about in an agent context specifically is runtime introspection afforded by the BEAM (which, out of how it developed, has always been very important in that world) - the blog post has a few notes on that as well

Yeah, Go is probably the best general purpose language at the moment.

Rust is great, but there's no need to manage memory manually if you don't need to.

So for general mainstream languages, that leaves ... Python. Sure, it's ok but Go has strong typing from the start, not bolted on with warts.

(I realized how incredibly subjective this comment turned out to be after I had written it. Apologies if I omitted or slighted your fave. This is pretty much how I see it).

Go has govulncheck[0] for static analysis of vulnerabilities in both code and binaries. The govulncheck tool has first-class support in the Go ecosystem. No other language has this level of integration with a static analyzer and at best will only analyze for known vulnerable modules (PLEASE CORRECT ME IF I'M WRONG).

[0] https://go.dev/doc/tutorial/govulncheck

I've read these arguments and they make perfect sense; but having tried different projects rewritten in Go vs Python (with Claude & Cursor); Python was just significantly faster, smaller, and easier to understand for Claude. It was done faster, and made less mistakes. I don't mean faster as execution time, but the code for its Python projects was almost a magnitude smaller. So it was done by the time its Go counterpart was halfway. Maybe it's gotten better, or I need some kind of "how to Go" skill for Claude... But just didn't work out of the box _for me_ as well as Python did. I tried a couple projects rewritten in different languages; Go, Kotlin, Python, Javascript. I settled with Python. (My own background is in Kotlin, Java and C++.)

I think Go isn't bad choice. It is widely popular, so I'd assume there's plenty of it in training sets and has stable APIs, so even "outdated code" would work. There's also rich ecosystem of static analyzers to keep generated code in check.

On the other hand I think Rust is better by some margin. Type system is obviously a big gain but Rust is very fast moving. When API changes LLMs can't follow and it takes many tries to get it right so it kinda levels out. Code might compile but only on some god-forgotten crate version everybody (but LLM) forgot about.

From personal experience Haskell benefits the most. Not only it has more type system usage than Rust, but its APIs are moving on snail-like pace, which means it doesn't suffer from outdated Rust and code compilable will work just fine. Also I think that Haskell code in training sets is guaranteed to be safe because of language extension system.

Great discussion! As someone who works with AI coding agents daily, my take is that the "best" language really depends on what the agent is building. Go's simplicity and predictability are huge for general-purpose agents, but I've found TypeScript shines for agents that live in the web ecosystem - interacting with APIs, browser automation, etc. The ecosystem alignment matters a lot. Python will always have a stranglehold on data/ML workloads simply because that's where the libraries are. The key insight might be: pick the language that matches your agent's domain, not just what the LLM generates best.

Is Go the best programming language for AI agents? I don't think so.

But what makes Go useful is the fact that it compiles to an actual executable you can easily ship anywhere - and that is actually really good considering that the language itself is super easy to learn.

I've recently started building some A agent tools with it and so far the experience has been great:

https://github.com/pantalk/pantalk https://github.com/mcpshim/mcpshim

Shameless plug - I sort of eluded in this post I wrote about Dark Factories generally and about rust being better than Go for building software (not just agents) with AI - but I think something generally important is feedback loops. While not all feedback loops are created equal and some will be superior, my argument is that holistic approach of including diverse, valuable feedback loops matters more.

https://bernste.in/writings/the-unreasonable-effectiveness-o...

For me it is an active question if coding training data "purity" matters. Python has Go on volume, but within that is a ton of API changes, language changes, etc. Is that free regularization or does it poison the dataset? As the author points out Go code is nominal because basically all published Go code looks the same and the library APIs are frozen in time to some degree.

I actually spent some time trying to get to the bottom of what a logical extension of this would be. An entirely made up language spec for an idealized language it never saw ever, and therefore had no bad examples of it. Go is likely the closest for the many reasons people call it boring.

Yeah, I don't care for go but I expect it to win here. Its performance is good enough for most use cases, it has a huge ecosystem of libraries, lots of training data, and deploys as a binary so users don't need to install anything else.

I expect rust to gain some market share since it's safe and fast, with a better type system, but complex enough that many developers would struggle by themselves. But IME AI also struggles with the manual memory management currently in large projects and can end up hacking things that "work" but end up even slower than GC. So I think the ecosystem will grow, but even once AI masters it, the time and tokens required for planning, building, testing will always exceed that of a GC language, so I don't see it ever usurping go, at least not in the next decade.

I wish the winner would be OCaml, as it's got the type safety of rust (or better), and the development speed of Go. But for whatever reason it never became that mainstream, and the lack of libraries and training data will probably relegate it to the dustbin. Basically, training data and libraries >>> operational characteristics >>> language semantics in the AI world.

I have a hard time imagining any other language maintaining a solid advantage over those two. There's less need for a managed runtime, definitely no need for an interpreted language, so I imagine Java and Python will slowly start to be replaced. Also I have to imagine C/C++ will be horrible for AI for obvious reasons. Of course JS will still be required for web, Swift for iOS, etc., but for mainstream development I think it's going to be Rust and Go.

In this thread, people who like Go talking about how good Go is

Completely agree with this take.

I've started what I'm calling an agent first framework written in Go.

Its just too easy to get great outputs with Go and Codex.

https://github.com/swetjen/virtuous

The key is blending human observability with agent ergonomics.

This is an opinion piece without any benchmarks, some valid points there but all anecdotal. Hard to take it seriously, feels like cargo culting into a preference.

I happen to just stumble across this article https://felixbarbalet.com/simple-made-inevitable-the-economi... extolling the virtues of Clojure. It specifically calls out Go for not being simple in the ways that matter for LLMs.

I've no idea myself, I just thought it was interesting for comparison.

Doesn't the high quantity of boilerplate pollute the context, thereby making agents less useful over time? i.e. go is not "token efficient"

I happen to just stumble across this article https://felixbarbalet.com/simple-made-inevitable-the-economi... extolling the virtues of Clojure. It specifically calls out Go for not being simple in the ways that matter for LLMs.

I've no idea myself, I just thought it was interesting for comparison.

Right now, I'd say the best language for AI is the one that you can review the fastest and rarely changes. Go is fairly readable imo and never changes so it is probably a good contender. But, I can't see any reason for anyone to learn it if they don't feel like it. Same goes for other "language X is good for AI" type posts.

I wonder if this is why there's been a huge uptick in the visibility of Go related content. I've seen more posts about Go in the last few days then I had in the last year.

Static compiling is a minus not a plus. Dynamic languages like Clojure allow agents to REPL and prod with the code live, and follow Verified Spec-Driven development a whole lot better. Lisp-like languages allow agents to create the exact data structure they need for every problem.

Every agent I've seen in Go has been so straightforward. Take exe.dev's Shelley. Great example of clean code and very effective tooling. Worth a try if you haven't used it.

TypeScript is what this author is looking for.

Golang just gets bogged down in irrelevant details way too easily for this.

I wonder how many tokens are spent generating: if err != nil {return err} for large programs and over a long period of time.

May be this is good incentive to improve error handling in Go.

As long as python runs all the models, the best language for agents is likely Python as it allows e.g. auto-fine-tuning of (local) LLMs for self-improving agents without the need to change the programming language. Use Pydantic if you care about type/runtime errors.

i have not used go for a while until claude code 4.5+, and yes it's the best language for AI coders.

I had a lot of success when having agents write D code. The results for me have been better than with C# or C++. I hadn't considered Go. Does anybody have some experience about how D fares vs. Go?

> Joy and energy is one of the rarest resources a small team can have when building large projects

I really love this point-out. Not always an easy sell upstream, but a big factor in happy + productive teams.

Java with orm might be easier actually. Also that middleware for microservices might be overkill (context filling)

I find typescript pretty useful. As others pointed out the stricter the compile stage is, the better.

On the other hands if there good conventions it’s also a benefit, for example Ruby on Rails.

This is a great article, thank you for sharing. The 4 languages I've honed in on with respect to AI agents are Rust, Python, C, and Go. Python has a foothold in the tooling for creating AI based on the training of large language models with frameworks including PyTorch and Tensorflow. As long as Python is the language to create AI, it will also be a great language for AI to code in.

The most important downside of Python is that it doesn't compile to a native binary that the OS can recognize and it's much slower. However, it's a great "glue" for different binaries or languages like Rust and Go.

Rust is the increasingly popular language for AI agents to choose from, often integrated into Python code. The trend is on the side of Rust here. I don't want to mention all the great points from the original poster. One technical point that wasn't mentioned, from my experience, is that the install size is too large for embedded systems. As the article mentioned, the build times are also longer than Go and this is an even worse bottleneck on embedded systems. I prefer Go over Rust in my research and development but I yield to other developers on the team professionally.

What about C/C++? At the moment, I've had great success with implementing C++ code through Agentic AI. However, there are a dearth of frameworks for things like web development. Because Python compiles to C, and integrating C modules into Python is relatively straightforward, I find myself implementing the Numpy approach where C is the backbone of performance critical features.

Personally, I still actively utilize code I've written more than 10 years ago that's battle tested, peer reviewed, and production ready. The above comments are for the current state, but what about the future? Another point that wasn't mentioned was the software license from Go. It's BSD3 with a patent grant which is more permissive than Rust's MIT + Apache 2.0 licenses. This is very important to understand the future viability of software because given enough time and all other things the same, more permissive software will win out in adoption.

The rabbit hole goes deeper. I think we will sacrifice Rust as the "good-enough" programming language to spoil the ecosystem with Agentic AI before its redemption arc. Only time will tell, but Python's inability to compile to a native binary makes it a bad choice for malware developers. You can fill in the blank here. Perhaps the stage has already been set, and it looks like Rust will be the opening act now that the lights are on.

Intuitively I expect this. Go is a language designed by Rob Pike to keep legions of high IQ Google engineers constrained down a simple path. There's generally one way to do it in Go.

As a human programmer with creative and aesthetic urges as well as being lazy and having an ego, I love expressive languages that let me describe what I want in a parsimonious fashion. ie As few lines of code as possible and no boilerplate.

With the advances in agent coding none of these concerns matter any more.

What matters most is can easily look at the code and understand the intent clearly. That the agent doesn't get distracted by formatting. That the code is relatively memory safe, type safe and avoids null issues and cannot ignore errors.

I dislike Go but I am a lot more likely to use it in this new world.

Agents are language agnostic actually, I think "best" this "best" that is a little overboard.

For the go vs rust points in the article:

- I agree that go's syntax and concepts are simpler (esp when you write libraries, some rust code can get gnarly and take a lot of brain cycles to parse everything)

- > idiomatic way of writing code and simpler to understand for humans - eh, to some extent. I personally hate go's boilerplate of "if err != nil" but that's mainly my problem.

- compiles faster, no question about it

- more go code out there allowing models to generate better code in Go than Rust - eh, here I somewhat disagree. The quality of the code matters as well. That's why a lot of early python code was so bad. There just is so much bad python out there. I would say that code quality and correctness matters as well, and I'd bet there's more "production ready" (heh) rust code out there than go code.

- (go) it is an opinionated language - so is rust, in a lot of ways. There are a lot of things that make writing really bad rust code pretty hard. And you get lots of protections for foot meets gun type of situations. AFAIK in go you can still write locking code using channels. I don't think you can do that in rust.

- something I didn't see mentioned is error messages. I think rust errors are some of the best in the industry, and they are sooo useful to LLMs (I've noticed this ever since coding with gpt4 era models!)

I guess we'll have to wait and see. There will be a lot of code written by agents going forward, we'll be spoiled for choice.

Go error handling is so bad that it ruins the language for me. But it might accidentally be an advantage here, because LLMs notoriously don't know how to handle exceptions properly. They'll do stuff like catch-log-ignore deep in the stack.

I independently came to this conclusion myself a few months ago. I don't particularly enjoy working with Go. I find it to be cumbersome and tedious to write by hand. I find the syntax to be just different enough from C++ or C# to be irritating. Don't get me started on the package versioning system.

But it does have the benefit of having a very strong "blessed way of doing things", so agents go off the rails less, and if claude is writing the code and endless "if err != nil" then the syntax bothers me less.

Go's fast compile times (feedback) are good for dumb models. Smarter ones are more likely to get it right and can therefore use languages with richer type systems.

If code is now free, why does the language matter at all?

My experience is that AI agents are not that good with Go. Not sure why but I think it is down to the low code quality of many major open source projects in Go.

[flagged]

you had me at Compile time bugs, strong typing, and static typing.

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?

Strange article. Why is Go the best language for agents instead of, say, Python? Here are the points the author seems to make:

---

# Author likes go

Ok, cool story bro...

# Go is compiled

Nice, but Python also has syntax and type checking -- I don't typically have any more luck generating more strictly typed code with agents.

# Go is simple

Sure. Python for a long time had a reputation as "pseudocode that runs", so the arguments about go being easy to read might be bias on the part of the author (see point 1).

# Go is opinionated

Sure. Python also has standards for formatting code, running tests (https://docs.python.org/3/library/unittest.html), and has no need for building binaries.

# Building cross-platform Go binaries is trivial

Is that a big deal if you don't need to build binaries at all?

# Agents know Go

Agents seem to know python as well...

---

Author seems to fall short of supporting the claim that Go is better than any other language by any margin, mostly relying on the biases they have that Go is a superior language in general than, say, Python. There are arguments to be made about compiled versus interpreted, for example, but if you don't accept that Go is the best language of them all for every purpose, the argument falls flat.