Live data from Hacker News

A case for Go as the best language for AI agents

getbruin.com

201–210 of 310 posts

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

#201

Earlier quoted context omitted.

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

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.

Yeah I half think Haskell is a big reason it's not more popular. If Haskell didn't exist, maybe OCaml would be better recognized as a good all-purpose language that makes safe practices the default, rather than just a gateway drug for Haskell.

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

#202

Earlier quoted context omitted.

breaking changes? hardly.

There is a decently long list of breaking changes now. Removing JavaEE modules from the JDK, and restricting sun.misc.Unsafe, are the ones people usually run into.

These are relatively small-scoped library changes only though.

Meanwhile Go already had a language change, while being less than half its age (loop variable capture).

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

#203
post #100

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…

This has been studied, Kotlin/C#/Elixir beat it handily.

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

#204
post #184
post #132

Earlier quoted context omitted.

Certainly not the "one way to write it" idea. Java has a ton of language features.

Not really. It has a pretty bare bones OOP (single inheritance, interface), primitives and objects, generics and pretty much that's it. Newer features fit very nicely and didn't increase the language surface (records are just a normal class with some methods auto-generated, while sealed types are just a restriction on who can subtype an interface -- and yet these give full ADT support for the language that improves r…

Annotations add a seemingly infinite amount of new semantics. You can’t predict anything with confidence just looking at the code without also studying the annotation processors in depth, which regular Java tools don’t help you with.

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

#205
post #115
post #100

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…

> But LLMs don't care about expressiveness, they care about predictability. I think this is true, but it misses a very key point. Go does an impressively bad job at designing APIs that are difficult to misuse, so LLMs will misuse them and will require also writing unit tests to walk through it, just to validate it used the libraries correctly. This isn't always possible (or is awkward/cumbersome) for certain scenario…

Go’s much faster compile times are a big advantage over Rust.

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

#206
post #29
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 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…

Even LLMs know they should write tests but hate doing it.

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

#207
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…

Unit tests in the same file wastes context and makes the whole thing hard to navigate for humans and machines alike.

It’s about the best possible documentation.

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

#208
post #202

Earlier quoted context omitted.

There is a decently long list of breaking changes now. Removing JavaEE modules from the JDK, and restricting sun.misc.Unsafe, are the ones people usually run into.

These are relatively small-scoped library changes only though. Meanwhile Go already had a language change, while being less than half its age (loop variable capture).

A long enough list of small changes eventually equates to a big change. People generally can't update applications from Java 8 or below to a new one without code updates.

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

#209
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.
Post reply on HN