A case for Go as the best language for AI agents • Hacker News Board

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

#171

Post by littlestymaar » Mon, Mar 02, 2026, 9:42 PM UTC

0x3f wrote: post #13

bensyverson wrote: post #7

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.

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.

That matches with actual Rust use actually, I've worked with Rust since 2017 on multiple projects and the number of times I've used the lifetime annotation has been very limited.

It's actually rare to have to borrow something and keep the borrow in another object (is where lifetime happens), most (95% at least I'd say) of the time you borrow something and then drop the borrow, or move the thing.

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

#172

Post by lambda_foo » Mon, Mar 02, 2026, 9:42 PM UTC

mpalmer wrote: post #43

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

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.

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

#173

Post by r_lee » Mon, Mar 02, 2026, 9:43 PM UTC

EGreg wrote: post #122

gf000 wrote: post #118

Earlier quoted context omitted.

Most of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.

I wonder what people will say to that. I personally think neither Go nor Java would be good for "agents". Better to have them sandboxed in WASM.

WASM isn't a language you'd want to program with. you can't verify outputs nor is there any proper training data aside from examples and such

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

#174

Post by hu3 » Mon, Mar 02, 2026, 9:44 PM UTC

roegerle wrote: post #159

hu3 wrote: post #134

Earlier quoted context omitted.

Java has decade(s) of cruft and breaking changes which LLMs were trained on. It's hard to compare. Plus Go compilation speed/test running provides quick iteration for LLMs.

breaking changes? hardly.

Yes, breaking changes. And many ways to do the same thing because the language kept evolving (thankfully).

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

#175

Post by lambda_foo » Mon, Mar 02, 2026, 9:45 PM UTC

sweetsocks21 wrote: post #119

daxfohl wrote: post #112

Earlier quoted context omitted.

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?

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 But I don't believe the effects are tracked in the type system yet, but that's on it way.

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

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

#176

Post by r_lee » Mon, Mar 02, 2026, 9:45 PM UTC

charlieflowers wrote: post #170

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

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

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

#177

Post by littlestymaar » Mon, Mar 02, 2026, 9:46 PM UTC

bryanlarsen wrote: post #36

0x3f wrote: post #13

Earlier quoted context omitted.

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.

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.

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.

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

#178

Post by xmx98 » Mon, Mar 02, 2026, 9:46 PM UTC

xlii wrote: post #92

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

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.

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

#179

Post by gf000 » Mon, Mar 02, 2026, 9:47 PM UTC

zozbot234 wrote: post #145

gf000 wrote: post #130

Earlier quoted context omitted.

I absolutely love Rust, but due to the space it occupies there is simply more to specify in code, and more things to get wrong for a stochastic LLM. Lifetimes are a global property and LLMs are not particularly good at reasoning about them compared to local ones. Most applications don't need low level memory control, so this complexity is better pushed to runtime. There are lots of managed languages with good/even st…

> Lifetimes are a global property and LLMs are not particularly good at reasoning about them compared to local ones. Huh? Lifetime analysis is a local analysis, same as any other kind of type checking. The semantics may have global implications, but exposing them locally is the whole point of having dedicated syntax for it.

> Lifetime analysis is a local analysis, same as any other kind of type checking

That's what the compiler is doing.

The developer (or LLM) is supposed to do the global reasoning so that what they end up writing down makes semantic sense.

Sure, throwing a bunch of variants at it and see what sticks is certainly an approach, but "lifetimes check out" only proves that the resulting code will be memory safe, not that it actually makes sense.

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

#180

Post by ses1984 » Mon, Mar 02, 2026, 9:48 PM UTC

hu3 wrote: post #139

ses1984 wrote: post #131

Earlier quoted context omitted.

I’m not sure they’re saying rust is king of types, they’re saying it’s king of llm targets.

Which it obviously can't be because it has an anemic standard library and depends on creates for basic things like error handling and async. Not to mention it's one of the slowest compilation of recent languages if not the slowest (maybe Kotlin).

But there is no language that is best in all of these dimensions (including ones described above).

Everything is a trade-off.