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

221–230 of 310 posts

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

#221

Post by jmyeet »

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 agree with most of this. You can learn Go syntax in an afternoon. Idiomatic Go takes a little longer but it just doesn't have the complexity footguns C++ does. But you can shoot yourself in the foot somewhat in Go. I'm talking about buffered channels, which are a mistake most of the time and a premature optimization almost all of the time, and you can explode your program with goroutines. But honestly it's not bad.

Python is an interesting one because it's not always obvious the program is wrong or will fail, thanks to dynamic typing.

But another problem is the Python philosophy since 3.0. Where once backwards compatibility was treated as almost sacrosanct, 3.0+ does not. 2.7 persisted for so long for this reason. But minor releases in 3.x make breaking changes and it's wild to me.

I just wish Go had cooperative async/await rather than channels because (IMHO) cooperative async/await is a vastly superior abstraction to unbuffered channels in particular.

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

#222

Post by dwaltrip »

fcatalan wrote: post #192
gf000 wrote: post #169

Earlier quoted context omitted.

Interesting project, but I believe the base assumption is already slightly wrong. Why do we assume that LLMs know what kind of language would benefit them? This information is not knowable without doing proper research, and even if there is some research like that, it would have to be a part of the training data. Otherwise it's just hallucination.

I agree, it´s mostly a silly whim taken too far. Too much time in my hands. In particular the whole stack based thing looks questionable. In fact the very first answer by Gemini proposed an APL-like encoding of the primitives for token saving, but when I started the implementation Claude Code pushed back on that, saying it would need to keep some sane semantics around the keywords to be able to understand the program…

Next level:

Have the LLMs generate tests that measure the “ease of use” and “effectiveness” of coding agents using the language.

Then have them use these tests to get data for their language design process.

They should also smoke test their own “meta process” here. E.g. Write a toy language that should be obviously much worse for LLMs, and then verify that the effectiveness tests produce a result agreeing with that.

I await the blog post :)

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

#223

Post by hnhn34 »

dnautics wrote: post #146
zozbot234 wrote: post #140

Earlier quoted context omitted.

> if you have to have a compiler check your code it's already too late If you're running good agentic AI it can read the compile errors just like a human and work to fix them until the build goes through.

how about not making the error in the first place

If you have an LLM that doesn't make errors ever, then you have an ASI, at which point the conversation is meaningless. In the meantime, having a lower error rate but more uncaught errors is less important than making incorrect code impossible to compile, and/or flagged by strict linters.

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

#226

Post by waynesonfire »

nitwit005 wrote: post #208
gf000 wrote: 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.

If hadoop did it, so can you. I'm talking about a project that stretched Java 8 to, and arguably beyond, its intended operational boundaries. Unlikely that you’re leaning on this boundary. It's Spring Boot upgrades that will be giving you troubles.

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

#228

Post by thot_experiment »

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

Earlier quoted context omitted.

There are humans that can't do that but are clearly capable of reasoning. Not a meaningful categorical split.

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.

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

#229

Post by nitwit005 »

waynesonfire wrote: post #226
nitwit005 wrote: post #208

Earlier quoted context omitted.

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.

If hadoop did it, so can you. I'm talking about a project that stretched Java 8 to, and arguably beyond, its intended operational boundaries. Unlikely that you’re leaning on this boundary. It's Spring Boot upgrades that will be giving you troubles.

They clearly did have Java version issues, as the different Hadoop versions list ranges of JDKs they're compatible with.

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

#230

Post by fcatalan »

dwaltrip wrote: post #222
fcatalan wrote: post #192

Earlier quoted context omitted.

I agree, it´s mostly a silly whim taken too far. Too much time in my hands. In particular the whole stack based thing looks questionable. In fact the very first answer by Gemini proposed an APL-like encoding of the primitives for token saving, but when I started the implementation Claude Code pushed back on that, saying it would need to keep some sane semantics around the keywords to be able to understand the program…

Next level: Have the LLMs generate tests that measure the “ease of use” and “effectiveness” of coding agents using the language. Then have them use these tests to get data for their language design process. They should also smoke test their own “meta process” here. E.g. Write a toy language that should be obviously much worse for LLMs, and then verify that the effectiveness tests produce a result agreeing with that.…

Ugh sounds like work, we are vibing here. Or can we also vibe-science? :)
Post reply on HN