Top
Best
New

Posted by karakanb 4 hours ago

A case for Go as the best language for AI agents(getbruin.com)
112 points | 189 commentspage 2
xlii 3 hours ago|
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 tries to get it right so it kinda levels out. Code might compile but only on some god-forgotten crate version everybody (but LLM) forgot about.

From personal experience Haskell benefits the most. Not only it has more type system usage than Rust, but its APIs are moving on snail-like pace, which means it doesn't suffer from outdated Rust and code compilable will work just fine. Also I think that Haskell code in training sets is guaranteed to be safe because of language extension system.

xmx98 1 hour ago|
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.
evanjrowley 4 hours ago||
Go has govulncheck[0] for static analysis of vulnerabilities in both code and binaries. The govulncheck tool has first-class support in the Go ecosystem. No other language has this level of integration with a static analyzer and at best will only analyze for known vulnerable modules (PLEASE CORRECT ME IF I'M WRONG).

[0] https://go.dev/doc/tutorial/govulncheck

linolevan 4 hours ago||
Not understanding the difference between this and something like cargo audit[0]. I suppose it has something to do with "static analysis of vulnerabilities" but I don't see any of that from a quick google search of govulncheck.

[0]https://crates.io/crates/cargo-audit

sa46 4 hours ago||
govulncheck analyzes symbol usage and only warns if your code reaches the affected symbol(s).

I’m not sure about cargo audit specifically, but most other security advisories are package scoped and will warn if your code transitively references the package, regardless of which symbols your code uses.

jerf 1 hour ago|||
It sounds like you think govulncheck can analyze your code and detect vulnerabilities that you wrote in your code. That's not what it does. It analyzes the libraries that you use and determines if you are using them in a vulnerable way. For a free tool, govulncheck is somewhat nicer than average in its class because it does call flow analysis and won't claim you're vulnerable just because you used a module, you have to actually have a call that could go over the vulnerable code, but "somewhat nicer than average" is as far as I would take it. But many languages have similar tools, and when you say "static analyzer" this isn't what I have in mind. For that I'd cite golangci-lint, which is a collection of community-built analysis tools, and it's nice to be able to pick them all up in one fell swoop, but they're nothing like Coverity or any real static analysis tool.
hrmtst93837 1 hour ago||
You're correct about govulncheck's integration; it significantly enhances Go's maintainability for large projects. Other languages often depend on external tools that lack the same level of usability and depth as Go's offerings.
philipp-gayret 4 hours ago||
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 counterpart was halfway. Maybe it's gotten better, or I need some kind of "how to Go" skill for Claude... But just didn't work out of the box _for me_ as well as Python did. I tried a couple projects rewritten in different languages; Go, Kotlin, Python, Javascript. I settled with Python. (My own background is in Kotlin, Java and C++.)
barelysapient 1 hour ago||
Completely agree with this take.

I've started what I'm calling an agent first framework written in Go.

Its just too easy to get great outputs with Go and Codex.

https://github.com/swetjen/virtuous

The key is blending human observability with agent ergonomics.

robviren 2 hours ago||
For me it is an active question if coding training data "purity" matters. Python has Go on volume, but within that is a ton of API changes, language changes, etc. Is that free regularization or does it poison the dataset? As the author points out Go code is nominal because basically all published Go code looks the same and the library APIs are frozen in time to some degree.

I actually spent some time trying to get to the bottom of what a logical extension of this would be. An entirely made up language spec for an idealized language it never saw ever, and therefore had no bad examples of it. Go is likely the closest for the many reasons people call it boring.

mbernstein 3 hours ago||
Shameless plug - I sort of eluded in this post I wrote about Dark Factories generally and about rust being better than Go for building software (not just agents) with AI - but I think something generally important is feedback loops. While not all feedback loops are created equal and some will be superior, my argument is that holistic approach of including diverse, valuable feedback loops matters more.

https://bernste.in/writings/the-unreasonable-effectiveness-o...

daxfohl 3 hours ago||
Yeah, I don't care for go but I expect it to win here. Its performance is good enough for most use cases, it has a huge ecosystem of libraries, lots of training data, and deploys as a binary so users don't need to install anything else.

I expect rust to gain some market share since it's safe and fast, with a better type system, but complex enough that many developers would struggle by themselves. But IME AI also struggles with the manual memory management currently in large projects and can end up hacking things that "work" but end up even slower than GC. So I think the ecosystem will grow, but even once AI masters it, the time and tokens required for planning, building, testing will always exceed that of a GC language, so I don't see it ever usurping go, at least not in the next decade.

I wish the winner would be OCaml, as it's got the type safety of rust (or better), and the development speed of Go. But for whatever reason it never became that mainstream, and the lack of libraries and training data will probably relegate it to the dustbin. Basically, training data and libraries >>> operational characteristics >>> language semantics in the AI world.

I have a hard time imagining any other language maintaining a solid advantage over those two. There's less need for a managed runtime, definitely no need for an interpreted language, so I imagine Java and Python will slowly start to be replaced. Also I have to imagine C/C++ will be horrible for AI for obvious reasons. Of course JS will still be required for web, Swift for iOS, etc., but for mainstream development I think it's going to be Rust and Go.

theta_d 2 hours ago|
> 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.

mpalmer 2 hours ago|||
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.
daxfohl 34 minutes ago||
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.
zozbot234 2 hours ago|||
ReasonML easily fixes that particular issue.
bad_haircut72 3 hours ago||
In this thread, people who like Go talking about how good Go is
stackedinserter 2 hours ago|
Because it IS good, even if you don't like it.
hmokiguess 4 hours ago||
This is an opinion piece without any benchmarks, some valid points there but all anecdotal. Hard to take it seriously, feels like cargo culting into a preference.
patrickthebold 4 hours ago|
I happen to just stumble across this article https://felixbarbalet.com/simple-made-inevitable-the-economi... extolling the virtues of Clojure. It specifically calls out Go for not being simple in the ways that matter for LLMs.

I've no idea myself, I just thought it was interesting for comparison.

mnsc 3 hours ago|
Is this your alt account?

https://news.ycombinator.com/item?id=47222705

Edit: cool article, I have myself speculated that we will get a new language made for/by llms that will be torture writing by hand/ide but easy to read/follow/navigate/check for a human and super easy for Llms to develop and maintain.

patrickthebold 1 hour ago||
Yes, I really wanted to post the comment and I (wrongly) thought this post got blocked by my procrastination setting. Apologies for the noise.
More comments...