Live data from Hacker News

A case for Go as the best language for AI agents

getbruin.com

51–60 of 310 posts

Re: A case for Go as the best language for AI agents

#51

I happen to just stumble across this article https://felixbarbalet.com/simple-made-inevitable-the-economi... extolling the virtues of Clojure. It specifically calls out Go for not being simple in the ways that matter for LLMs. I've no idea myself, I just thought it was interesting for comparison.

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.

Re: A case for Go as the best language for AI agents

#53

Earlier quoted context omitted.

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.

LLMs don't "reason".

Why is this a meaningful distinction to you? What does "reason" mean here? Can we construct a test that cleanly splits what humans do from what LLMs do?

Re: A case for Go as the best language for AI agents

#54
post #23

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?

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.

Re: A case for Go as the best language for AI agents

#55
post #5

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.

Exactly. Here's my experience using LLMs to produce code: - Rust: nearly universally compiles and runs without fault. - Python,JS: very often will run for some time and then crash The reason I think is type safety and the richness of the compiler errors and warnings. Rust is absolutely king here.

[flagged]

Re: A case for Go as the best language for AI agents

#56
post #38

Earlier quoted context omitted.

I am guessing there is a balance between a language that has a lot of soundness checks (like Rust) and a language that has a ton of example code to train on (like Python). How much more valuable each aspect is I am not sure.

Rust is the best language for AI: - Rust code generates absolutely perfectly in Claude Code. - Rust code will run without GC. You get that for free. - Rust code has a low defect rate per LOC, at least measured by humans. Google gave a talk on this. The sum types + match and destructure make error handling ergonomic and more or less required by idiomatic code, which the LLM will generate. I'd certainly pick Rust or Go…

The downside is that even simple Rust projects typically use hundreds of dependencies, and this is even worse with LLMs, who don’t understand the concept of “less is more”.

Re: A case for Go as the best language for AI agents

#57
post #51

I happen to just stumble across this article https://felixbarbalet.com/simple-made-inevitable-the-economi... extolling the virtues of Clojure. It specifically calls out Go for not being simple in the ways that matter for LLMs. I've no idea myself, I just thought it was interesting for comparison.

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…

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!

Re: A case for Go as the best language for AI agents

#58
post #5

I think the more you can shift to compile time the better when it comes to agents. Go is therefore 'ok', but the type system isn't as useful as other options. I would say Rust is quite good for just letting something churn through compiler errors until it works, and then you're unlikely to get runtime errors. I haven't tried Haskell, but I assume that's even better.

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

It's not a waste of time though. Those warnings and clippy lints are there to improve the quality of the code and to find bugs.

As a human I can just decide to write quality code (or not!), but LLMs don't understand when they're being lazy or stupid and so need to have that knowledge imposed on them by an external reviewer. Static analysis is cheap, and more importantly it's automatic. The alternative is to spend more time doing code review, but that's a bottleneck.

Re: A case for Go as the best language for AI agents

#59
post #35
post #29

Earlier quoted context omitted.

I think Rust is great for agents, for a reason that is rarely mentioned: unit tests are in the same file. This means that agents just "know" they should update the tests along with the source. With other languages, whether it's TypeScript/Go/Python, even if you explicitly ask agents to write/run tests, after a while agents just forget to do that, unless they cause build failures. You have to constantly remind them to…

You can add a callback to e.g. Claude to guarantee it does a cargo check and test.

Fwiw i used to do this (and with lints) - it was the only way to make Claude consistent in the early days when i first started using it (~August 2025).

For many months now though, Claude is nearly consistent with both calling test and check/clippy. Perhaps this is due to my global memory file, not sure to be honest.

What i do know, is that i never use those hooks, i have them disabled atm. Why? Because the benefit is almost nonexistent as i mentioned, and the cost is at times, quite high. It means i cannot work on a project piecemeal, aka "only focus on this file, it will not compile and that's okay", and instead forces claude to make complete edits which may be harder to review. Worst of all, i have seen it get into a loop and be unable to exit. Eg a test fails and claude says "that failure is not due to my changes" or w/e, and it just does that.. forever, on loop. Burns 100% of the daily tokens pretty quick if unmonitored.

Fwiw i've not looked to see if there's an alternate way to write hooks. It might be worth having the hook only suggest, rather than forcing claude. Alternatively, maybe i could spawn a subagent to review if stopping claude makes sense.. hmm.

Re: A case for Go as the best language for AI agents

#60
post #5

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.

Was asking on mastodon if people tried leveraging very concise and high level languages like haskell, prolog with 2025 llms.. I'm really really curious.
Post reply on HN