Top
Best
New

Posted by karakanb 9 hours ago

A case for Go as the best language for AI agents(getbruin.com)
155 points | 224 commentspage 5
justinhj 8 hours ago|
Intuitively I expect this. Go is a language designed by Rob Pike to keep legions of high IQ Google engineers constrained down a simple path. There's generally one way to do it in Go.

As a human programmer with creative and aesthetic urges as well as being lazy and having an ego, I love expressive languages that let me describe what I want in a parsimonious fashion. ie As few lines of code as possible and no boilerplate.

With the advances in agent coding none of these concerns matter any more.

What matters most is can easily look at the code and understand the intent clearly. That the agent doesn't get distracted by formatting. That the code is relatively memory safe, type safe and avoids null issues and cannot ignore errors.

I dislike Go but I am a lot more likely to use it in this new world.

win311fwg 6 hours ago|
The most striking thing about Go codebases is that, for the most part (there are exceptions), they all look the same. You can choose a random repository on GitHub and be hard-pressed to not think that you wrote it yourself. Which also means that LLMs are likely to produce code that looks like you wrote it yourself. I do think that is one thing Go has going for it today.

But for how long will it matter? I do wonder if programming languages as we know them today will lose relevance as all this evolves.

radium3d 8 hours ago||
Agents are language agnostic actually, I think "best" this "best" that is a little overboard.
NitpickLawyer 8 hours ago||
For the go vs rust points in the article:

- I agree that go's syntax and concepts are simpler (esp when you write libraries, some rust code can get gnarly and take a lot of brain cycles to parse everything)

- > idiomatic way of writing code and simpler to understand for humans - eh, to some extent. I personally hate go's boilerplate of "if err != nil" but that's mainly my problem.

- compiles faster, no question about it

- more go code out there allowing models to generate better code in Go than Rust - eh, here I somewhat disagree. The quality of the code matters as well. That's why a lot of early python code was so bad. There just is so much bad python out there. I would say that code quality and correctness matters as well, and I'd bet there's more "production ready" (heh) rust code out there than go code.

- (go) it is an opinionated language - so is rust, in a lot of ways. There are a lot of things that make writing really bad rust code pretty hard. And you get lots of protections for foot meets gun type of situations. AFAIK in go you can still write locking code using channels. I don't think you can do that in rust.

- something I didn't see mentioned is error messages. I think rust errors are some of the best in the industry, and they are sooo useful to LLMs (I've noticed this ever since coding with gpt4 era models!)

I guess we'll have to wait and see. There will be a lot of code written by agents going forward, we'll be spoiled for choice.

stackghost 8 hours ago||
I independently came to this conclusion myself a few months ago. I don't particularly enjoy working with Go. I find it to be cumbersome and tedious to write by hand. I find the syntax to be just different enough from C++ or C# to be irritating. Don't get me started on the package versioning system.

But it does have the benefit of having a very strong "blessed way of doing things", so agents go off the rails less, and if claude is writing the code and endless "if err != nil" then the syntax bothers me less.

kittikitti 5 hours ago||
This is a great article, thank you for sharing. The 4 languages I've honed in on with respect to AI agents are Rust, Python, C, and Go. Python has a foothold in the tooling for creating AI based on the training of large language models with frameworks including PyTorch and Tensorflow. As long as Python is the language to create AI, it will also be a great language for AI to code in.

The most important downside of Python is that it doesn't compile to a native binary that the OS can recognize and it's much slower. However, it's a great "glue" for different binaries or languages like Rust and Go.

Rust is the increasingly popular language for AI agents to choose from, often integrated into Python code. The trend is on the side of Rust here. I don't want to mention all the great points from the original poster. One technical point that wasn't mentioned, from my experience, is that the install size is too large for embedded systems. As the article mentioned, the build times are also longer than Go and this is an even worse bottleneck on embedded systems. I prefer Go over Rust in my research and development but I yield to other developers on the team professionally.

What about C/C++? At the moment, I've had great success with implementing C++ code through Agentic AI. However, there are a dearth of frameworks for things like web development. Because Python compiles to C, and integrating C modules into Python is relatively straightforward, I find myself implementing the Numpy approach where C is the backbone of performance critical features.

Personally, I still actively utilize code I've written more than 10 years ago that's battle tested, peer reviewed, and production ready. The above comments are for the current state, but what about the future? Another point that wasn't mentioned was the software license from Go. It's BSD3 with a patent grant which is more permissive than Rust's MIT + Apache 2.0 licenses. This is very important to understand the future viability of software because given enough time and all other things the same, more permissive software will win out in adoption.

The rabbit hole goes deeper. I think we will sacrifice Rust as the "good-enough" programming language to spoil the ecosystem with Agentic AI before its redemption arc. Only time will tell, but Python's inability to compile to a native binary makes it a bad choice for malware developers. You can fill in the blank here. Perhaps the stage has already been set, and it looks like Rust will be the opening act now that the lights are on.

jim33442 6 hours ago||
Go error handling is so bad that it ruins the language for me. But it might accidentally be an advantage here, because LLMs notoriously don't know how to handle exceptions properly. They'll do stuff like catch-log-ignore deep in the stack.
esafak 8 hours ago||
Go's fast compile times (feedback) are good for dumb models. Smarter ones are more likely to get it right and can therefore use languages with richer type systems.
afry1 8 hours ago||
If code is now free, why does the language matter at all?
jryio 7 hours ago||
All code has bugs, the vector space of all possible bugs determines the entropy of the problem space for a large language model to traverse.

Reduce entropy, increase probability of the correct outcome.

LLMs are surfing higher dimensional vector spaces, reduce the vector space, get better results.

bigfishrunning 8 hours ago|||
Because you'll have to review it, and Go's design limits the number of ways it can go wrong.

Code is free, sure, but it's not guaranteed to be correct, and review time is not free.

afry1 7 hours ago||
If code must be correct, and review time is not free, and review time is costlier than code time, why not just ...

... write the code yourself?

bigfishrunning 7 hours ago||
I 100% agree, and do, but it's an answer to the GP's question (why generated code language matters)

I think many many people just skip the "review" step in this process, and assume they're saving time. It's not going to end well.

kittikitti 6 hours ago||
I thought about this for a while and came to a conclusion that while "code is free", tokens are not. If tokens were free and instant, it would generate machine code directly. Therefore, it needs abstractions like a compiled or interpreted language in order to address the token bottleneck.
AtNightWeCode 8 hours ago|
My experience is that AI agents are not that good with Go. Not sure why but I think it is down to the low code quality of many major open source projects in Go.
More comments...