Live data from Hacker News

A case for Go as the best language for AI agents

getbruin.com

241–250 of 310 posts

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

#241
post #202

Earlier quoted context omitted.

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.

Mostly an automatic updater call (for javax->jakarta) and a few dependency bumps away in the majority of cases.

Plain vanilla java code is really backwards compatible, on both a syntax, and on a binary level.

You can often find decades old jars on some random university site, working with JDK 25 with no issue.

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

#242
post #184

Earlier quoted context omitted.

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.

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 like @Path("/endpoint") is very informative for both humans and LLMs alike, being local to what it attaches to. Within an agent, the code serving the endpoint will be immediately visible in the context returned by a simple string search, no need to do another round of "find wherever this codebase registers routes".

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

#243

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.

"AI guys" use Claude CLI that renders to a terminal via freakin' react.

Come on, java starts up fast enough and the memory usage can be set (better throughput vs less memory, it's a classic tradeoff. Go just defaults to worse throughput).

Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly.

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

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

> if you explicitly ask agents to write/run tests, after a while agents just forget to do that

Add a single task using your project's preferred task-runner that performs all the checks you want the agent to adhere to: linting, test coverage, style checks, test, etc, and add a rule in AGENTS.md that agents should always run this tasks after edits, and fix any warnings or errors produced.

Add the same task to your version management's pre-merge checks, in case the agent (or colleague) forgets to check before pushing. This was good practice since before LLMs, but I never was a fan of having such checks to pre-commit hooks.

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

#245
post #110

Earlier quoted context omitted.

All comments are paid for in some way, even if only in "warm fuzzies". If that is sad, why are you choosing to be sad? But outlandish comments usually require greater payment to justify someone putting in the effort. If you're not being paid well, what's the motivation to post things you know don't make any sense to try and sell a brand?

> If you're not being paid well, what's the motivation to post things you know don't make any sense to try and sell a brand? Because it works. Because it does in fact make sense despite your frustration with the concept.

Right. So why did you deny it earlier?

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

#246
post #188

Earlier quoted context omitted.

[flagged]

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]

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

#247
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 wonder: How does Rust and Haskell compare to Go when it comes to LLM code generation? I was always thinking that the compiler induced feedback loops could give these languages an edge?

What would be the best language properties for LLM assisted coding?

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

#248
post #55

Earlier quoted context omitted.

[flagged]

What will you use for dependent types, Idris 2? Lean? None are as popular as Rust especially counting the number of production level packages available.

Scala has dependant types (though inferior than Idris ones) and has the whole jvm ecosystem.

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

#249
post #242

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…

Annotations are a scourge. Automagic extensions you have to understand through years of usage.

Go has no such things and you have circled back exactly to the GP's point: "There's a ceiling on abstraction". There is no such ceiling in java ime

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

#250
post #243

Earlier quoted context omitted.

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.

"AI guys" use Claude CLI that renders to a terminal via freakin' react. Come on, java starts up fast enough and the memory usage can be set (better throughput vs less memory, it's a classic tradeoff. Go just defaults to worse throughput). Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly.

> Come on, java starts up fast enough and the memory usage can be set

Yeah it can be adjusted, on the other hand you have a language that just works. Starts instantly and memory usage is bounded by usage, not guesstimate of how much the JVM will need.

> Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly

Have you many java projects that didn't use some fat framework? Good for you if you did, but 100% of java project I had the displeasure of touching were huge mess with deprecated frameworks on ancient java versions.

Post reply on HN