11 ms·

A case for Go as the best language for AI agents

203 points by karakanb 8mo ago

geldedus 8mo ago
TypeScript. Compiled, strongly typed. Tons of training data trumps any obscure language. Yes, compared to Typescript, Go is an obscure language.
evanjrowley 8mo ago
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 https://go.dev/doc/tutorial/govulncheck
- linolevan 8mo ago
  Not understanding the difference between this and something like cargo audit[0]. I suppose it has something to do with "static analysis of vulnerabilities" but I don't see any of that from a quick google search of govulncheck. [0]https://crates.io/crates/cargo-audit https://crates.io/crates/cargo-audit
  - sa46 8mo ago
    govulncheck analyzes symbol usage and only warns if your code reaches the affected symbol(s). 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.
- jerf 8mo ago
  It sounds like you think govulncheck can analyze your code and detect vulnerabilities that you wrote in your code. That's not what it does. It analyzes the libraries that you use and determines if you are using them in a vulnerable way. For a free tool, govulncheck is somewhat nicer than average in its class because it does call flow analysis and won't claim you're vulnerable just because you used a module, you have to actually have a call that could go over the vulnerable code, but "somewhat nicer than average" is as far as I would take it. But many languages have similar tools, and when you say "static analyzer" this isn't what I have in mind. For that I'd cite golangci-lint, which is a collection of community-built analysis tools, and it's nice to be able to pick them all up in one fell swoop, but they're nothing like Coverity or any real static analysis tool.
- hrmtst93837 8mo ago
  [flagged]
arrow7000 8mo ago
> 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
- rbtprograms 8mo ago
  what would you prefer? i liked rust a lot as i found the compiler feedback loop pretty great, but the language was much more verbose and i found the simplicity of Go to be great, and the typing system is good enough for almost everything.
  - alternatex 8mo ago
    I have a feeling F# would work great, but unfortunately we don't use it at work so I can't experiment with the fancy expensive models. Only problem might be amount of training data.
  - fridder 8mo ago
    Elixir works pretty well with the LLMs
- g947o 8mo ago
  Yeah, only one of these is a compiled language.
0x3f 8mo ago
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.
- bensyverson 8mo ago
  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.
  - 0x3f 8mo ago
    I've never actually seen it get a compiler issue arising from lifetimes, so it seems to one-shot that stuff just fine. Although my work is typically middle of the road, non-HFT trading applications, not super low-level.
    - bryanlarsen 8mo ago
      It certainly had to iterate on lifetimes prior to Claude 4.5, at least for me. Prior to Claude 4.0 it was pretty bad at Rust.
      - littlestymaar 8mo ago
        Most LLM sucked at Rust at the beginning because there's much less rust code available on the broad internet. I suspect the providers started training specifically in it because it appeared proportionally much more in the actual LLM usage (obviously much less than more mainstream languages like Python or JavaScript, but I wouldn't be surprised if there was more LLM queries on Rust than on C, for demographic reasons). Nowadays even small Qwens are decent at it in one-shot prompts, or at least much better than GPT-4 was.
WadeGrimridge 8mo ago
[flagged]
- rbtprograms 8mo ago
  put something out there wade. whats your preference?
- pestkranker 8mo ago
  Why?
synergy20 8mo ago
i have not used go for a while until claude code 4.5+, and yes it's the best language for AI coders.
abhimanyurawat 8mo ago
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?
esafak 8mo ago
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.
stackghost 8mo ago
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.
patrickthebold 8mo ago
I happen to just stumble across this article https://felixbarbalet.com/simple-made-inevitable-the-economics-of-language-choice-in-the-llm-era/ 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.
- mnsc 8mo ago
  Is this your alt account? https://news.ycombinator.com/item?id=47222705 https://news.ycombinator.com/item?id=47222705 Edit: cool article, I have myself speculated that we will get a new language made for/by llms that will be torture writing by hand/ide but easy to read/follow/navigate/check for a human and super easy for Llms to develop and maintain.
  - patrickthebold 8mo ago
    Yes, I really wanted to post the comment and I (wrongly) thought this post got blocked by my procrastination setting. Apologies for the noise.
radium3d 8mo ago
Agents are language agnostic actually, I think "best" this "best" that is a little overboard.
poidos 8mo ago
Doesn't the high quantity of boilerplate pollute the context, thereby making agents less useful over time? i.e. go is not "token efficient"
- tgv 8mo ago
  Language models need redundancy (as informing structure). Not surprising, since they're trained on human language. It's hard to train a model on a language with a high entropy. I haven't tried it, but I think LLMs would perform quite badly on languages such as APL, where structure and meaning are closely intertwined.
gmueckl 8mo ago
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?
- hirvi74 8mo ago
  I haven't been amazed by the C# results that I have gotten either. I notice both GPT and Claude tend to write syntactically outdated C# code. Though, I have found both to be better at C# than Swift, for example.
pjcurran 8mo ago
I happen to just stumble across this article https://felixbarbalet.com/simple-made-inevitable-the-economics-of-language-choice-in-the-llm-era/ 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.
- nameless912 8mo ago
  I was prototyping to this end the other day - what would it be like for a coding agent to have access to a language that can be: - structurally edited, ensuring syntactic validity at all times - annotated with metadata, so that agents can annotate the code as they go and refer back to accreted knoweledge (something Clojure can do structurally using nodepaths or annotations directly in code) - put into any environment you might like, e.g. using ClojureScript I haven't proven to myself this is more useful/results in better code than just writing code "the normal way" with an agent, but it sure seems interesting.
- lukev 8mo ago
  Clojure is awesome for LLMs (if you shim in an automatic paren balancer). But that's because it's tight, token efficient, and above all local. Pure functions don't require much context to reason about effectively. However, you do miss the benefit of types, which are also good for LLMs. The "ideal" LLM language would have the immutability and functional nature of Clojure combined with a solid type system. Haskell or OCaml immediately come to mind, but I'm not sure how much the relative lack of training data hurts... curious if anyone has any experiences there.
  - mpalmer 8mo ago
    I was ripping through an OCaml project of mine over the weekend with Gemini 3 Flash. Could have fooled me there's a training data shortage!
- WalterGR 8mo ago
  Clojure is definitely dense. I’m wondering, though, about the languages’ representation in the training data. Stack overflow tags: 17,775 Clojure 74,501 Go I’m not finding a way to get any useful information from GitHub, e.g. count of de-duplicated lines of code per language. There might be something in their annual “Octoverse” report but I haven’t drilled into it yet: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/ https://github.blog/news-insights/octoverse/octoverse-a-new-...
justinhj 8mo ago
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.
- win311fwg 8mo ago
  The most striking thing about Go codebases is that, for the most part (there are exceptions), they all look the same. You can choose a random repository on GitHub and be hard-pressed to not think that you wrote it yourself. Which also means that LLMs are likely to produce code that looks like you wrote it yourself. I do think that is one thing Go has going for it today. But for how long will it matter? I do wonder if programming languages as we know them today will lose relevance as all this evolves.
moritz 8mo ago
C.f., from 25d ago: “Why Elixir is the best language for AI” https://news.ycombinator.com/item?id=46900241 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
- masklinn 8mo ago
  There’s also a “why clojure is the best langage for Ai” floating around (and it specifically dumps on go): https://felixbarbalet.com/simple-made-inevitable-the-economics-of-language-choice-in-the-llm-era/ https://felixbarbalet.com/simple-made-inevitable-the-economi...
- jaen 8mo ago
  For convenience, a link to the original paper ("AutoCodeBench: Large Language Models are Automatic Code Benchmark Generators"): https://autocodebench.github.io/#:~:text=Experimental%20Results https://autocodebench.github.io/#:~:text=Experimental%20Resu... Go as a language for LLM generation actually trails a lot of other languages, at least according to this research...
mccolin 8mo ago
> 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.
afry1 8mo ago
If code is now free, why does the language matter at all?
- bigfishrunning 8mo ago
  Because you'll have to review it, and Go's design limits the number of ways it can go wrong. Code is free, sure, but it's not guaranteed to be correct, and review time is not free.
  - afry1 8mo ago
    If code must be correct, and review time is not free, and review time is costlier than code time, why not just ... ... write the code yourself?
    - bigfishrunning 8mo ago
      I 100% agree, and do, but it's an answer to the GP's question (why generated code language matters) I think many many people just skip the "review" step in this process, and assume they're saving time. It's not going to end well.
    - jim33442 7mo ago
      Cause it's still quicker to review only then to code + review. And review time isn't necessarily costlier than code time.
- jryio 8mo ago
  All code has bugs, the vector space of all possible bugs determines the entropy of the problem space for a large language model to traverse. Reduce entropy, increase probability of the correct outcome. LLMs are surfing higher dimensional vector spaces, reduce the vector space, get better results.
- kittikitti 8mo ago
  I thought about this for a while and came to a conclusion that while "code is free", tokens are not. If tokens were free and instant, it would generate machine code directly. Therefore, it needs abstractions like a compiled or interpreted language in order to address the token bottleneck.
storus 8mo ago
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.
- dnautics 8mo ago
  you'd think, and yet its like 70% on autocoderbenchmark
philipp-gayret 8mo ago
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++.)
- ottah 8mo ago
  But did the agent handle python errors correctly, or did you get a bunch of Expect and pass statements?
  - philipp-gayret 8mo ago
    Correct enough for me. It certainly doesn't handle every single possible error, likely one of the reasons it works better for me.
NitpickLawyer 8mo ago
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.
mpalmer 8mo ago
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.
- daxfohl 8mo ago
  How's the multicore and async story these days? I remember that was one of the big draws of F# originally, that it had all (or, most of) the type safety features of OCaml but all the mutlicore of dotnet. (Plus it created async before even C# had it). Has OCaml caught up?
  - sweetsocks21 8mo ago
    OCaml has full multicore support with algebraic effects now. The effect system makes things like async very nice as there's no function "coloring" problem: https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974 https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974 But I don't believe the effects are tracked in the type system yet, but that's on it way.
    - lambda_foo 8mo ago
      The type system for effects is an ongoing research effort. For now you get unhandled effect exceptions at runtime. With Multicore OCaml we gained thread sanitizer support and a reasonable memory model. Combined they give you tools for reasoning about data races and finding them. https://ocaml.org/manual/5.3/tsan.html https://ocaml.org/manual/5.3/tsan.html
- lambda_foo 8mo ago
  Strongly agree, plus OCaml has an expressive type system that lets you build abstractions that just aren’t possible with Go. The original article gives poor reasons for choosing Go.
clintonc 8mo ago
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 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.
- bigfishrunning 8mo ago
  I would say Go is better then python for 2 reasons 1) Go runs faster, so if you're not optimizing for dev time (and if you're vibe coding, you're not) then it's a clear winner there 2) Python's barrier to entry is incredibly low, so intuitively there's likely a ton of really terrible python code in the training corpus for these tools
yanis_t 8mo ago
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.
hmokiguess 8mo ago
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.
fidotron 8mo ago
TypeScript is what this author is looking for. Golang just gets bogged down in irrelevant details way too easily for this.
- synergy20 8mo ago
  are you serious, hundreds of node_modules that I have no idea about, plus a runtime in the 100+ MBs alone.
- karakanb 8mo ago
  Hi, author here, thanks! I have used TypeScript before across various projects, but I haven't considered building CLI tooling in that before, I guess due to my prejudice against the whole JS ecosystem. I plan to give it another try in the next weeks.
fcatalan 8mo ago
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 https://github.com/cairnlang/Cairn
- adregan 8mo ago
  Have you asked them to compile it to BEAM bytecode directly?
  - fcatalan 8mo ago
    It has been on the roadmap since they invented the thing. I fear it won't work but then they probably will do it in 10 minutes...
- ntonozzi 8mo ago
  Wow that is wild, that is exactly along the lines of my fantasy language. It'd be so easy to go into the deep end building tooling and improving a language like this.
  - fcatalan 8mo ago
    I have had to check myself a bit, too easy to fall too deep into what is essentially a practical joke
AtNightWeCode 8mo ago
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.
osigurdson 8mo ago
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.
mbernstein 8mo ago
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-of-external-feedback-loops/ https://bernste.in/writings/the-unreasonable-effectiveness-o...
deleted 8mo ago
[deleted]
daxfohl 8mo ago
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.
- theta_d 8mo ago
  > But for whatever reason it never became that mainstream Syntax. Syntax is the reason. It's too foreign to be picked up quickly by the mass of developers that already know a C style language. I would also argue that it's not only foreign, it's too clunky.
  - mpalmer 8mo ago
    The syntax is ridiculously simple, and I can't in good conscience allow OCaml to be called clunky in a thread about a language that solved error handling with record-like interfaces and multiple return types.
    - 8mo ago
xlii 8mo ago
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.
- xmx98 8mo ago
  How are the generated Haskell programs? I imagine much shorter than Go and easier to eyeball for correctness, but can’t say as I’m not fluent in it. LLM-generated procedural Python scripts are very readable in my experience.
  - xlii 7mo ago
    Haskell is one of the tersest language in general. With "no comments" instruction code actually is almost idiomatic one. It's hard to guess it was written by LLM.
jryio 8mo ago
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 https://sancho.studio [1]: https://github.com/zoom/zoom-e2e-whitepaper https://github.com/zoom/zoom-e2e-whitepaper
- TrueSlacker0 8mo ago
  A lot of those pros apply to c# as well. Which claude and gemeni both do very well with.
  - bwestergard 8mo ago
    Or Java, for that matter.
bad_haircut72 8mo ago
In this thread, people who like Go talking about how good Go is
- stackedinserter 8mo ago
  Because it IS good, even if you don't like it.
p0w3n3d 8mo ago
Java with orm might be easier actually. Also that middleware for microservices might be overkill (context filling)
devnull3 8mo ago
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.
- AlexCoventry 8mo ago
  That happens often enough that it might have its own token, if you BPE-encoded specifically for golang.
asim 8mo ago
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.
scuff3d 8mo ago
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.
deleted 8mo ago
[deleted]
robviren 8mo ago
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.
charlieflowers 8mo ago
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).
- r_lee 8mo ago
  For me Go is like the 80% language. I like TypeScript as well, but Go is just such a reliable workhorse I'd say? it's not "sexy" but it's just satisfying how it's just these simple building blocks that you can build extremely complex software with
barelysapient 8mo ago
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 https://github.com/swetjen/virtuous The key is blending human observability with agent ergonomics.
_pdp_ 8mo ago
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/pantalk/pantalk https://github.com/mcpshim/mcpshim https://github.com/mcpshim/mcpshim
bhekanik 8mo ago
[flagged]
xannabxlle 8mo ago
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.
jim33442 8mo ago
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.
kittikitti 8mo ago
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.
bear3r 8mo ago
the article conflates two different things: what's easy for an LLM to write vs. what's safe to run. python wins on the first axis (smaller context, more training data, faster iteration). go wins on the second (compile errors caught early, explicit error handling). for a long-running autonomous agent that can't be supervised, you probably want the second. for a human-in-the-loop workflow where you can just rerun, the first.
koalaman 8mo ago
One of the best reasons to use Golang is that it removes a huge amount of software supply chain risk. It's the only big language that has an end-to-end integrity story where you can be sure that the dependencies you've imported are what you think they are.
mparis 8mo ago
I love the simplicity & practicality of Go, but can't get over the limited type-system. I love the expressivity of Rust, but compile times are a problem. Someone with some sway, please convince a hyper-scalar to support something like https://borgo-lang.github.io/ https://borgo-lang.github.io/. I think it may be the AST that we all need.
- deleted 8mo ago
  [deleted]
geldedus 8mo ago
TypeScript. Tons of training data trumps any obscure language
meztez 8mo ago
The best language for AI agents is the one YOU believe is the best.
Fire-Dragon-DoL 8mo ago
We write Go and Ruby (rails) at work. There is no comparison l, everybody notice how much better it performs on Rails code. The react frontend is a huge slowdown given how well it debugs Hotwire issues. That's our take so, but we are just a sample.
evara-ai 8mo ago
Having built a bunch of production AI agent systems (workflow automation, conversational agents, data pipelines with LLM-in-the-loop) in Python and Node.js — my take is that language choice is genuinely the least important decision you'll make. The bottleneck in agent systems is almost never your language runtime. It's LLM API latency (200-2000ms per call), external service I/O, and retry/error handling across unreliable tool calls. Whether your orchestration loop runs in 2ms (Go) or 15ms (Python) is irrelevant when you're waiting 800ms for Claude to respond. What actually matters for production agent systems: (1) state management across multi-step workflows that can fail at any point, (2) graceful degradation when one tool in a chain times out, (3) observability into what the agent decided and why. These are design problems, not language problems. Python wins on ecosystem breadth — every LLM provider ships a Python SDK first, every embedding model has Python bindings, and the tooling around prompt engineering and evaluation is Python-native. When you're iterating on agent behavior (which is 80% of the work), that ecosystem advantage compounds fast. That said, Go's argument is strongest for the "agent runtime" layer — the part that manages concurrency, schedules tool calls, and handles streaming. If you separate the orchestration runtime from the AI logic, Go for the former and Python for the latter isn't a bad split.
mjbonanno 8mo ago
Go is my Go-to lately :-)
wycx 7mo ago
I have been having a good time getting Claude to code in the unfashionable choice of Object Pascal/Lazarus. Fast compile times, native cross-platform support, and small statically-linked binaries that should work for years to come in our RAM-constrained future.
joefrost01 7mo ago
I'm a Java developer by day and have also delivered production codebases in Python and Scala. Before that I worked in ETL with Informatica. I've been building systems professionally for quite a while. I’ve tried LLM-assisted development across Java, JavaScript, Python, Rust, C++ and Go. The difference in how well models hold the system in their “head” becomes obvious once the codebase grows beyond a few thousand lines. With most ecosystems the entropy explodes. Python and TypeScript in particular have an enormous combinatorial space: frameworks, build systems, typing styles, dependency patterns, project layouts. Two codebases solving the same problem can look completely different. That variability leaks directly into the training distribution and the output starts to drift. Go sits at the opposite end of that spectrum. There’s basically: one formatting style one standard build system one dependency mechanism one dominant project layout a very small set of concurrency primitives a language that has barely changed in a decade That constraint is exactly what LLMs thrive on. The solution space is narrow, so the model converges instead of wandering. In my own experiments, once a codebase passes ~8k lines, most languages start to show cracks: incorrect imports, wrong framework idioms, subtle API hallucinations. With Go the agents stay coherent much longer. The tooling helps too — extremely fast builds, deterministic formatting, and batteries-included tooling mean the feedback loop is tight. Java often gets suggested as an alternative because it’s statically typed and mature. But in practice the ecosystem is a maze: Maven vs Gradle, Spring everything, annotation magic, layers of frameworks, multiple architectural styles. The language may be stable, but the surrounding universe isn’t. I’m also a big Rust fan. If you actually need Rust’s capabilities it’s fantastic. But it’s slower to compile and significantly more complex for LLMs to work with. Beyond small codebases the difference becomes obvious. One final point: architecture matters as much as language. Strong modular boundaries, API-first feature access, and good code maps help enormously when working with LLMs. Used carefully, these tools are a serious productivity multiplier. The interesting question now isn’t whether they work - it’s which languages and system designs allow them to work reliably.
joefrost01 7mo ago
The thing I’ve noticed with LLM-assisted development is that the language ecosystem matters far more than people expect. Once a codebase gets beyond a few thousand lines, models stop struggling with syntax and start struggling with entropy. If the ecosystem allows many ways to structure the same program, the model’s output begins to drift. I’ve tried building non-trivial projects with LLM assistance in Java, JavaScript, Python, Rust, C++ and Go. The difference in how well the models hold the system in their "head" becomes obvious once you pass a few thousand lines of code. Python and TypeScript in particular have a massive combinatorial space: frameworks, build systems, typing styles, dependency patterns, project layouts. Two teams solving the same problem can produce codebases that look completely different. That variability leaks into the training distribution and the model has to guess which universe it’s operating in. Go sits at the opposite end of that spectrum. There is essentially: - one formatting style - one standard build system - one dependency mechanism - one dominant project layout - a very small set of concurrency primitives - a language that has barely changed in a decade That constraint turns out to be exactly what LLMs thrive on. The solution space is narrow, so the model converges instead of wandering. In my experiments, once a project passes ~8k lines most languages start to show cracks: incorrect imports, wrong framework idioms, subtle API hallucinations. With Go the agents stay coherent much longer. Extremely fast build times and batteries-included tooling also tighten the feedback loop significantly. Java often gets suggested as an alternative because it’s statically typed and mature. But in practice the ecosystem is a maze: Maven vs Gradle, Spring everything, annotation magic, layers of frameworks, multiple architectural styles. The language may be stable, but the surrounding universe isn’t. I’m also a big Rust fan. If you genuinely need Rust’s capabilities it’s an excellent tool. But it’s slower to compile and significantly more complex for LLMs to work with. Beyond small codebases the difference becomes noticeable. One thing that helps regardless of language is architecture. Strong modular boundaries, API-only feature access, and good code maps make a huge difference when working with LLMs. Used carefully, these tools are a huge productivity multiplier. The interesting question now isn’t whether LLM coding works - it’s which languages, practices, and system designs allow it to work reliably at scale.
xxwink 7mo ago
Concrete experience from building a Go framework with AI as the primary developer (not just a helper): the properties that make Go good for agents are exactly what you'd expect — one formatter, one build system, static typing, and a strong convention around package structure. The part that surprised me: the bottleneck wasn't AI capability. It was that the tooling wasn't designed for AI as the builder. Once I locked architectural decisions upfront and enforced a single way to do everything, the AI stopped hallucinating boilerplate and started making genuinely good decisions. Zero ambiguity in the codebase = zero drift in AI-generated code.
Kachilu 7mo ago
[flagged]

203 points by karakanb 8mo ago

TypeScript. Compiled, strongly typed. Tons of training data trumps any obscure language. Yes, compared to Typescript, Go is an obscure language.

evanjrowley 8mo ago

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 https://go.dev/doc/tutorial/govulncheck

linolevan 8mo ago
Not understanding the difference between this and something like cargo audit[0]. I suppose it has something to do with "static analysis of vulnerabilities" but I don't see any of that from a quick google search of govulncheck. [0]https://crates.io/crates/cargo-audit https://crates.io/crates/cargo-audit
- sa46 8mo ago
  govulncheck analyzes symbol usage and only warns if your code reaches the affected symbol(s). 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.
jerf 8mo ago
It sounds like you think govulncheck can analyze your code and detect vulnerabilities that you wrote in your code. That's not what it does. It analyzes the libraries that you use and determines if you are using them in a vulnerable way. For a free tool, govulncheck is somewhat nicer than average in its class because it does call flow analysis and won't claim you're vulnerable just because you used a module, you have to actually have a call that could go over the vulnerable code, but "somewhat nicer than average" is as far as I would take it. But many languages have similar tools, and when you say "static analyzer" this isn't what I have in mind. For that I'd cite golangci-lint, which is a collection of community-built analysis tools, and it's nice to be able to pick them all up in one fell swoop, but they're nothing like Coverity or any real static analysis tool.
hrmtst93837 8mo ago
[flagged]

arrow7000 8mo ago

> 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

rbtprograms 8mo ago
what would you prefer? i liked rust a lot as i found the compiler feedback loop pretty great, but the language was much more verbose and i found the simplicity of Go to be great, and the typing system is good enough for almost everything.
- alternatex 8mo ago
  I have a feeling F# would work great, but unfortunately we don't use it at work so I can't experiment with the fancy expensive models. Only problem might be amount of training data.
- fridder 8mo ago
  Elixir works pretty well with the LLMs
g947o 8mo ago
Yeah, only one of these is a compiled language.

0x3f 8mo ago

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.

bensyverson 8mo ago
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.
- 0x3f 8mo ago
  I've never actually seen it get a compiler issue arising from lifetimes, so it seems to one-shot that stuff just fine. Although my work is typically middle of the road, non-HFT trading applications, not super low-level.
  - bryanlarsen 8mo ago
    It certainly had to iterate on lifetimes prior to Claude 4.5, at least for me. Prior to Claude 4.0 it was pretty bad at Rust.
    - littlestymaar 8mo ago
      Most LLM sucked at Rust at the beginning because there's much less rust code available on the broad internet. I suspect the providers started training specifically in it because it appeared proportionally much more in the actual LLM usage (obviously much less than more mainstream languages like Python or JavaScript, but I wouldn't be surprised if there was more LLM queries on Rust than on C, for demographic reasons). Nowadays even small Qwens are decent at it in one-shot prompts, or at least much better than GPT-4 was.

WadeGrimridge 8mo ago

[flagged]

rbtprograms 8mo ago
put something out there wade. whats your preference?
pestkranker 8mo ago
Why?

synergy20 8mo ago

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

abhimanyurawat 8mo ago

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?

esafak 8mo ago

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.

stackghost 8mo ago

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.

patrickthebold 8mo ago

I happen to just stumble across this article https://felixbarbalet.com/simple-made-inevitable-the-economics-of-language-choice-in-the-llm-era/ 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.

mnsc 8mo ago
Is this your alt account? https://news.ycombinator.com/item?id=47222705 https://news.ycombinator.com/item?id=47222705 Edit: cool article, I have myself speculated that we will get a new language made for/by llms that will be torture writing by hand/ide but easy to read/follow/navigate/check for a human and super easy for Llms to develop and maintain.
- patrickthebold 8mo ago
  Yes, I really wanted to post the comment and I (wrongly) thought this post got blocked by my procrastination setting. Apologies for the noise.

radium3d 8mo ago

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

poidos 8mo ago

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

tgv 8mo ago
Language models need redundancy (as informing structure). Not surprising, since they're trained on human language. It's hard to train a model on a language with a high entropy. I haven't tried it, but I think LLMs would perform quite badly on languages such as APL, where structure and meaning are closely intertwined.

gmueckl 8mo ago

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?

hirvi74 8mo ago
I haven't been amazed by the C# results that I have gotten either. I notice both GPT and Claude tend to write syntactically outdated C# code. Though, I have found both to be better at C# than Swift, for example.

pjcurran 8mo ago

nameless912 8mo ago
I was prototyping to this end the other day - what would it be like for a coding agent to have access to a language that can be: - structurally edited, ensuring syntactic validity at all times - annotated with metadata, so that agents can annotate the code as they go and refer back to accreted knoweledge (something Clojure can do structurally using nodepaths or annotations directly in code) - put into any environment you might like, e.g. using ClojureScript I haven't proven to myself this is more useful/results in better code than just writing code "the normal way" with an agent, but it sure seems interesting.
lukev 8mo ago
Clojure is awesome for LLMs (if you shim in an automatic paren balancer). But that's because it's tight, token efficient, and above all local. Pure functions don't require much context to reason about effectively. However, you do miss the benefit of types, which are also good for LLMs. The "ideal" LLM language would have the immutability and functional nature of Clojure combined with a solid type system. Haskell or OCaml immediately come to mind, but I'm not sure how much the relative lack of training data hurts... curious if anyone has any experiences there.
- mpalmer 8mo ago
  I was ripping through an OCaml project of mine over the weekend with Gemini 3 Flash. Could have fooled me there's a training data shortage!
WalterGR 8mo ago
Clojure is definitely dense. I’m wondering, though, about the languages’ representation in the training data. Stack overflow tags: 17,775 Clojure 74,501 Go I’m not finding a way to get any useful information from GitHub, e.g. count of de-duplicated lines of code per language. There might be something in their annual “Octoverse” report but I haven’t drilled into it yet: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/ https://github.blog/news-insights/octoverse/octoverse-a-new-...

justinhj 8mo ago

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.

win311fwg 8mo ago
The most striking thing about Go codebases is that, for the most part (there are exceptions), they all look the same. You can choose a random repository on GitHub and be hard-pressed to not think that you wrote it yourself. Which also means that LLMs are likely to produce code that looks like you wrote it yourself. I do think that is one thing Go has going for it today. But for how long will it matter? I do wonder if programming languages as we know them today will lose relevance as all this evolves.

moritz 8mo ago

C.f., from 25d ago: “Why Elixir is the best language for AI” https://news.ycombinator.com/item?id=46900241 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

masklinn 8mo ago
There’s also a “why clojure is the best langage for Ai” floating around (and it specifically dumps on go): https://felixbarbalet.com/simple-made-inevitable-the-economics-of-language-choice-in-the-llm-era/ https://felixbarbalet.com/simple-made-inevitable-the-economi...
jaen 8mo ago
For convenience, a link to the original paper ("AutoCodeBench: Large Language Models are Automatic Code Benchmark Generators"): https://autocodebench.github.io/#:~:text=Experimental%20Results https://autocodebench.github.io/#:~:text=Experimental%20Resu... Go as a language for LLM generation actually trails a lot of other languages, at least according to this research...

mccolin 8mo ago

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

afry1 8mo ago

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

bigfishrunning 8mo ago
Because you'll have to review it, and Go's design limits the number of ways it can go wrong. Code is free, sure, but it's not guaranteed to be correct, and review time is not free.
- afry1 8mo ago
  If code must be correct, and review time is not free, and review time is costlier than code time, why not just ... ... write the code yourself?
  - bigfishrunning 8mo ago
    I 100% agree, and do, but it's an answer to the GP's question (why generated code language matters) I think many many people just skip the "review" step in this process, and assume they're saving time. It's not going to end well.
  - jim33442 7mo ago
    Cause it's still quicker to review only then to code + review. And review time isn't necessarily costlier than code time.
jryio 8mo ago
All code has bugs, the vector space of all possible bugs determines the entropy of the problem space for a large language model to traverse. Reduce entropy, increase probability of the correct outcome. LLMs are surfing higher dimensional vector spaces, reduce the vector space, get better results.
kittikitti 8mo ago
I thought about this for a while and came to a conclusion that while "code is free", tokens are not. If tokens were free and instant, it would generate machine code directly. Therefore, it needs abstractions like a compiled or interpreted language in order to address the token bottleneck.

storus 8mo ago

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.

dnautics 8mo ago
you'd think, and yet its like 70% on autocoderbenchmark

philipp-gayret 8mo ago

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

ottah 8mo ago
But did the agent handle python errors correctly, or did you get a bunch of Expect and pass statements?
- philipp-gayret 8mo ago
  Correct enough for me. It certainly doesn't handle every single possible error, likely one of the reasons it works better for me.

NitpickLawyer 8mo ago

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.

mpalmer 8mo ago

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.

daxfohl 8mo ago
How's the multicore and async story these days? I remember that was one of the big draws of F# originally, that it had all (or, most of) the type safety features of OCaml but all the mutlicore of dotnet. (Plus it created async before even C# had it). Has OCaml caught up?
- sweetsocks21 8mo ago
  OCaml has full multicore support with algebraic effects now. The effect system makes things like async very nice as there's no function "coloring" problem: https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974 https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974 But I don't believe the effects are tracked in the type system yet, but that's on it way.
  - lambda_foo 8mo ago
    The type system for effects is an ongoing research effort. For now you get unhandled effect exceptions at runtime. With Multicore OCaml we gained thread sanitizer support and a reasonable memory model. Combined they give you tools for reasoning about data races and finding them. https://ocaml.org/manual/5.3/tsan.html https://ocaml.org/manual/5.3/tsan.html
lambda_foo 8mo ago
Strongly agree, plus OCaml has an expressive type system that lets you build abstractions that just aren’t possible with Go. The original article gives poor reasons for choosing Go.

clintonc 8mo ago

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

bigfishrunning 8mo ago
I would say Go is better then python for 2 reasons 1) Go runs faster, so if you're not optimizing for dev time (and if you're vibe coding, you're not) then it's a clear winner there 2) Python's barrier to entry is incredibly low, so intuitively there's likely a ton of really terrible python code in the training corpus for these tools

yanis_t 8mo ago

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.

hmokiguess 8mo ago

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.

fidotron 8mo ago

TypeScript is what this author is looking for. Golang just gets bogged down in irrelevant details way too easily for this.

synergy20 8mo ago
are you serious, hundreds of node_modules that I have no idea about, plus a runtime in the 100+ MBs alone.
karakanb 8mo ago
Hi, author here, thanks! I have used TypeScript before across various projects, but I haven't considered building CLI tooling in that before, I guess due to my prejudice against the whole JS ecosystem. I plan to give it another try in the next weeks.

fcatalan 8mo ago

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 https://github.com/cairnlang/Cairn

adregan 8mo ago
Have you asked them to compile it to BEAM bytecode directly?
- fcatalan 8mo ago
  It has been on the roadmap since they invented the thing. I fear it won't work but then they probably will do it in 10 minutes...
ntonozzi 8mo ago
Wow that is wild, that is exactly along the lines of my fantasy language. It'd be so easy to go into the deep end building tooling and improving a language like this.
- fcatalan 8mo ago
  I have had to check myself a bit, too easy to fall too deep into what is essentially a practical joke

AtNightWeCode 8mo ago

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.

osigurdson 8mo ago

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.

mbernstein 8mo ago

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-of-external-feedback-loops/ https://bernste.in/writings/the-unreasonable-effectiveness-o...

deleted 8mo ago

[deleted]

daxfohl 8mo ago

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.

theta_d 8mo ago
> But for whatever reason it never became that mainstream Syntax. Syntax is the reason. It's too foreign to be picked up quickly by the mass of developers that already know a C style language. I would also argue that it's not only foreign, it's too clunky.
- mpalmer 8mo ago
  The syntax is ridiculously simple, and I can't in good conscience allow OCaml to be called clunky in a thread about a language that solved error handling with record-like interfaces and multiple return types.
  - 8mo ago

xlii 8mo ago

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.

xmx98 8mo ago
How are the generated Haskell programs? I imagine much shorter than Go and easier to eyeball for correctness, but can’t say as I’m not fluent in it. LLM-generated procedural Python scripts are very readable in my experience.
- xlii 7mo ago
  Haskell is one of the tersest language in general. With "no comments" instruction code actually is almost idiomatic one. It's hard to guess it was written by LLM.

jryio 8mo ago

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 https://sancho.studio [1]: https://github.com/zoom/zoom-e2e-whitepaper https://github.com/zoom/zoom-e2e-whitepaper

TrueSlacker0 8mo ago
A lot of those pros apply to c# as well. Which claude and gemeni both do very well with.
- bwestergard 8mo ago
  Or Java, for that matter.

bad_haircut72 8mo ago

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

stackedinserter 8mo ago
Because it IS good, even if you don't like it.

p0w3n3d 8mo ago

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

devnull3 8mo ago

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.

AlexCoventry 8mo ago
That happens often enough that it might have its own token, if you BPE-encoded specifically for golang.

asim 8mo ago

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.

scuff3d 8mo ago

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.

deleted 8mo ago

[deleted]

robviren 8mo ago

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.

charlieflowers 8mo ago

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

r_lee 8mo ago
For me Go is like the 80% language. I like TypeScript as well, but Go is just such a reliable workhorse I'd say? it's not "sexy" but it's just satisfying how it's just these simple building blocks that you can build extremely complex software with

barelysapient 8mo ago

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 https://github.com/swetjen/virtuous The key is blending human observability with agent ergonomics.

_pdp_ 8mo ago

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/pantalk/pantalk https://github.com/mcpshim/mcpshim https://github.com/mcpshim/mcpshim

bhekanik 8mo ago

[flagged]

xannabxlle 8mo ago

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.

jim33442 8mo ago

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.

kittikitti 8mo ago

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.

bear3r 8mo ago

the article conflates two different things: what's easy for an LLM to write vs. what's safe to run. python wins on the first axis (smaller context, more training data, faster iteration). go wins on the second (compile errors caught early, explicit error handling). for a long-running autonomous agent that can't be supervised, you probably want the second. for a human-in-the-loop workflow where you can just rerun, the first.

koalaman 8mo ago

One of the best reasons to use Golang is that it removes a huge amount of software supply chain risk. It's the only big language that has an end-to-end integrity story where you can be sure that the dependencies you've imported are what you think they are.

mparis 8mo ago

I love the simplicity & practicality of Go, but can't get over the limited type-system. I love the expressivity of Rust, but compile times are a problem. Someone with some sway, please convince a hyper-scalar to support something like https://borgo-lang.github.io/ https://borgo-lang.github.io/. I think it may be the AST that we all need.

deleted 8mo ago
[deleted]

geldedus 8mo ago

TypeScript. Tons of training data trumps any obscure language

meztez 8mo ago

The best language for AI agents is the one YOU believe is the best.

Fire-Dragon-DoL 8mo ago

We write Go and Ruby (rails) at work. There is no comparison l, everybody notice how much better it performs on Rails code. The react frontend is a huge slowdown given how well it debugs Hotwire issues. That's our take so, but we are just a sample.

evara-ai 8mo ago

Having built a bunch of production AI agent systems (workflow automation, conversational agents, data pipelines with LLM-in-the-loop) in Python and Node.js — my take is that language choice is genuinely the least important decision you'll make. The bottleneck in agent systems is almost never your language runtime. It's LLM API latency (200-2000ms per call), external service I/O, and retry/error handling across unreliable tool calls. Whether your orchestration loop runs in 2ms (Go) or 15ms (Python) is irrelevant when you're waiting 800ms for Claude to respond. What actually matters for production agent systems: (1) state management across multi-step workflows that can fail at any point, (2) graceful degradation when one tool in a chain times out, (3) observability into what the agent decided and why. These are design problems, not language problems. Python wins on ecosystem breadth — every LLM provider ships a Python SDK first, every embedding model has Python bindings, and the tooling around prompt engineering and evaluation is Python-native. When you're iterating on agent behavior (which is 80% of the work), that ecosystem advantage compounds fast. That said, Go's argument is strongest for the "agent runtime" layer — the part that manages concurrency, schedules tool calls, and handles streaming. If you separate the orchestration runtime from the AI logic, Go for the former and Python for the latter isn't a bad split.

mjbonanno 8mo ago

Go is my Go-to lately :-)

wycx 7mo ago

I have been having a good time getting Claude to code in the unfashionable choice of Object Pascal/Lazarus. Fast compile times, native cross-platform support, and small statically-linked binaries that should work for years to come in our RAM-constrained future.

joefrost01 7mo ago

I'm a Java developer by day and have also delivered production codebases in Python and Scala. Before that I worked in ETL with Informatica. I've been building systems professionally for quite a while. I’ve tried LLM-assisted development across Java, JavaScript, Python, Rust, C++ and Go. The difference in how well models hold the system in their “head” becomes obvious once the codebase grows beyond a few thousand lines. With most ecosystems the entropy explodes. Python and TypeScript in particular have an enormous combinatorial space: frameworks, build systems, typing styles, dependency patterns, project layouts. Two codebases solving the same problem can look completely different. That variability leaks directly into the training distribution and the output starts to drift. Go sits at the opposite end of that spectrum. There’s basically: one formatting style one standard build system one dependency mechanism one dominant project layout a very small set of concurrency primitives a language that has barely changed in a decade That constraint is exactly what LLMs thrive on. The solution space is narrow, so the model converges instead of wandering. In my own experiments, once a codebase passes ~8k lines, most languages start to show cracks: incorrect imports, wrong framework idioms, subtle API hallucinations. With Go the agents stay coherent much longer. The tooling helps too — extremely fast builds, deterministic formatting, and batteries-included tooling mean the feedback loop is tight. Java often gets suggested as an alternative because it’s statically typed and mature. But in practice the ecosystem is a maze: Maven vs Gradle, Spring everything, annotation magic, layers of frameworks, multiple architectural styles. The language may be stable, but the surrounding universe isn’t. I’m also a big Rust fan. If you actually need Rust’s capabilities it’s fantastic. But it’s slower to compile and significantly more complex for LLMs to work with. Beyond small codebases the difference becomes obvious. One final point: architecture matters as much as language. Strong modular boundaries, API-first feature access, and good code maps help enormously when working with LLMs. Used carefully, these tools are a serious productivity multiplier. The interesting question now isn’t whether they work - it’s which languages and system designs allow them to work reliably.

joefrost01 7mo ago

The thing I’ve noticed with LLM-assisted development is that the language ecosystem matters far more than people expect. Once a codebase gets beyond a few thousand lines, models stop struggling with syntax and start struggling with entropy. If the ecosystem allows many ways to structure the same program, the model’s output begins to drift. I’ve tried building non-trivial projects with LLM assistance in Java, JavaScript, Python, Rust, C++ and Go. The difference in how well the models hold the system in their "head" becomes obvious once you pass a few thousand lines of code. Python and TypeScript in particular have a massive combinatorial space: frameworks, build systems, typing styles, dependency patterns, project layouts. Two teams solving the same problem can produce codebases that look completely different. That variability leaks into the training distribution and the model has to guess which universe it’s operating in. Go sits at the opposite end of that spectrum. There is essentially: - one formatting style - one standard build system - one dependency mechanism - one dominant project layout - a very small set of concurrency primitives - a language that has barely changed in a decade That constraint turns out to be exactly what LLMs thrive on. The solution space is narrow, so the model converges instead of wandering. In my experiments, once a project passes ~8k lines most languages start to show cracks: incorrect imports, wrong framework idioms, subtle API hallucinations. With Go the agents stay coherent much longer. Extremely fast build times and batteries-included tooling also tighten the feedback loop significantly. Java often gets suggested as an alternative because it’s statically typed and mature. But in practice the ecosystem is a maze: Maven vs Gradle, Spring everything, annotation magic, layers of frameworks, multiple architectural styles. The language may be stable, but the surrounding universe isn’t. I’m also a big Rust fan. If you genuinely need Rust’s capabilities it’s an excellent tool. But it’s slower to compile and significantly more complex for LLMs to work with. Beyond small codebases the difference becomes noticeable. One thing that helps regardless of language is architecture. Strong modular boundaries, API-only feature access, and good code maps make a huge difference when working with LLMs. Used carefully, these tools are a huge productivity multiplier. The interesting question now isn’t whether LLM coding works - it’s which languages, practices, and system designs allow it to work reliably at scale.

xxwink 7mo ago

Concrete experience from building a Go framework with AI as the primary developer (not just a helper): the properties that make Go good for agents are exactly what you'd expect — one formatter, one build system, static typing, and a strong convention around package structure. The part that surprised me: the bottleneck wasn't AI capability. It was that the tooling wasn't designed for AI as the builder. Once I locked architectural decisions upfront and enforced a single way to do everything, the AI stopped hallucinating boilerplate and started making genuinely good decisions. Zero ambiguity in the codebase = zero drift in AI-generated code.

Kachilu 7mo ago

[flagged]