Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A case for Go as the best language for AI agents

getbruin.com

Post reply on HN
Print view View original

251–260 of 310 posts

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

#251

Post by Orygin »

fasbiner wrote: post #246
slibhb wrote: post #188

Earlier quoted context omitted.

LLMs are great with Typescript. But the fact remains that there are many different browsers and several runtimes (Node, Deno, Bun), each of which may have slightly different rules.

[flagged]

> As someone familiar with those ecosystems, I'm have trouble envisioning the degree of operator error or imprecision that would cause this to be a problem.

Because you are familiar with the ecosystem? Just like python devs saying it's normal to juggle with 3 package managers to run a simple script.

Back to your original point: You also are biased by what you are used to use.

Thankfully, I don't have to touch any JS project anymore, but oh god what a nightmare it is. Even just having CLI tools requiring constant updates to not break randomly during the day is enough pain that I won't touch that with a 10m pole.

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

#252

Post by cryptos »

gf000 wrote: post #242
jimbokun wrote: post #204

Earlier quoted context omitted.

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.

Well, that's just metaprogramming. Also, java annotation processors are strictly "append-only", they can't change code written as is. They may subclass it, or build new classes that make use of the annotations. In my experience LLMs are more than happy with annotations, especially from the widely used ones (spring/jakarta ee, lombok though it's not an annotation processor, etc). If you think about it, an annotation l…

Project Lombok rewrites code, however it misuses annotation processing.

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

#253

Post by philipp-gayret »

ottah wrote: post #239
philipp-gayret wrote: post #40

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

But did the agent handle python errors correctly, or did you get a bunch of Expect and pass statements?

Correct enough for me. It certainly doesn't handle every single possible error, likely one of the reasons it works better for me.

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

#254

Post by cryptos »

anthonypasq96 wrote: post #240
xannabxlle wrote: post #195

Earlier quoted context omitted.

Exactly, the propping up of Go seems unfounded. Java in it's newest iterations make it more compelling as a target, and people, especially young people, overlook it because of its stigma as enterprise cruft.

im a java guy, but it simply takes too long to start up and uses too much memory to be a reasonable language for ai agent development.

However, the cause it not really Java as such, but massive frameworks and tooling (e.g. Maven). Maybe AI will bring some fresh air to Java, because old truths might no longer be valid. But it will be hard to get rid of old habits because it manifested in AI training data.

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

#255

Post by cryptos »

jen20 wrote: post #233
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.

The points about tooling certainly do not apply to Java, for example, Maven vs Gradle (which is a huge mess in and of itself - do you use Kotlin or Groovy), and which plugins are you willing to pull in? Or is Ant still the thing? SpotBugs, Spotless? What test framework do you use? Do you use Mockito or one of the myriad alternatives? Go has _none_ of this nonsense, and it's better for it. Nor does Rust, FWIW, which I…

Gradle could be used as an AI benchenmark on its own! The syntax of plugin DSLs changes all the time. Special credits could be achieved for handling old (Groovy) and new versions (Kotlin) of Gradle itself.

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

#256

Post by cryptos »

CuriouslyC wrote: post #203
jryio wrote: 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.

Do have any links to back this up? I'd be really interested.

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

#257

Post by evara-ai »

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.

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

#258

Post by grey-area »

thot_experiment wrote: post #228
grey-area wrote: post #219

Earlier quoted context omitted.

There are certainly humans with poor reasoning or even incapable of reasoning, I’m not sure what you think that proves?

Ok, but if you read my comment you would note that I constructed a category of humans who can reason but cannot count the r's in strawberry. I think you don't know what it means to reason, and are dismissively claiming AI cannot reason as though it invalidates a point made earlier without even having a sturdy definition in your head. I think for you to say "LLMs can't reason" in this context is essentially a NOP.

It is hard to define reasoning or thinking, these are vague concepts. I use them to indicate there are areas where these machines take obviously wrong decisions, because they are above all probability weighing machines based on a corpus, that is not I hope you would agree thinking, so you must believe there is some emergent properties which constitute thinking since you're so confident these machines are in fact doing that.

AI companies use these terms (thinking, reasoning etc) to try to trick users into anthropomorphising pattern matching machines and so that people believe they are true general intelligence.

I don't think we've reached AGI yet, though we are closer than previously, and I'm skeptical LLMs will be the route - they are impressive, but they are better at tricking humans than at performing complex tasks they have not seen before IME.

Do you think we have seen AGI yet from LLMs? If not how would you define their limitations?

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

#259

Post by muyuu »

jryio wrote: 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…

I'd have said the same a few months ago, but looking at the code quality that the SotA LLMs right now I have to say it's excellent and the problems they have are not with the language but with the subject problems, esp. when they require some complex design that isn't well documented beforehand. They seem to struggle with keeping a world model. Languages themselves, they run circles around humans.

Now the case for Go or for other tightly standardised languages is that whatever the LLM produces, you're likely to be familiar with and make sense of its decisions. With C++, you can generally steer the LLM to refactor things in a certain way but it's extra steps. With Ruby it works surprisingly well too. I'm a lot less happy with their results in Lisp or in Bash/zsh for instance, and mixed results in C depending on what you give them to start - they just come with such random stuff. But it may be just a matter of training set and the relative free-form of those languages.

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

#260

Post by stouset »

wakawaka28 wrote: post #216
maleldil wrote: post #135

Earlier quoted context omitted.

Why do you say it's unstable?

It is literally being changed constantly. They chose to add it to the Linux kernel but they have to build the features they need into the language as they go. It's not backward compatible like C and C++ either. Sure, there are a couple of versions you could try to pin to in Rust, but then all your libraries need to be pinned to the same version (to be fair, this last part is an assumption).

I think very nearly every assertion in this statement is demonstrably untrue.
Post reply on HN