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?

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.

> For a language team, Go is a dream.

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.

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.

When you give those resources to your coding agent, do you give them URLs? Or work with local versions?

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.

Isn't Netflix a Java shop

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

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.

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.

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.

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.

Simple toolchain which supports trivial lightweight deployment is my go to attribute to select Go in projects.

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

compilation time is massively important for developing with agents

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

> Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do.

The article specifically discusses how Go is well-suited for LLMs. It's not going on about general programming topics.

The article is about which tool is more appropriate, and you're dodging that question. Every use case has multiple langs you could use for it, and there's no universally agreed-upon choice. Like if you're writing a typical web API backend with LLM assistance from scratch, which do you use between JS, Py, Java, Go, Rust, etc?

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.

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

> Who cares? [sorry, but that question is trolling]

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.

Isn't that true? Prove them wrong.

(Someone who doesn't even eat cookie but heard a lot of praise of Oreo)

yeah the conflict of interest here is staggering.

nailed it

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

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.

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

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

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

> "because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker"

Citation absolutely needed.

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?

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.

Heh, I checked https://platform.openai.com/tokenizer to see if they made it 1 token, it's not.

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.

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

> Linting is really good as well.

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!

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.

Good luck if that's really the case, cause most of Google's code is not in Go.

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.

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.

How do you propose to quantify the terms "elegant" and "easy to reason about"? What unit of measurement do you use for these?

This sounds like your personal feelings, not quantification.

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)

Personally I find Rust a lot harder to read than Go.

If you're going to have an agent write most of your code readability is very important.

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.

I guess the difference in compile times doesn't matter enough?

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.

Zig seems to have more closely aligned with what Go devs prefer.

Ignoring performance for the moment (because most situations are bottlenecked on something else), why is rust better?

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.

can you elaborate?

except Rust is HARD while GO is super easy.

I agree all in all.

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

If you are going to take the human out of the loop you could just write the program in assembly or machine code directly.

Google: please don't forget our little language exists :(.