Go is an ideal language for AI-assisted software engineering

Learn Go if you have to, or want to learn it. Otherwise, I don't think there is any reason to do so. I agree that it is easy to read, but less so than the language you already know.

When I use AI with Go I give it this rule:

Prefer standard Go libraries and tools.

80% of the time I can get by without external dependencies (outside of Go's X repository)

> By enforcing a single, standardized format via the built-in gofmt tool

I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie.

Seems to me the ideal language for AI has not been created yet.

Had the same impression about TypeScript and Rust.

Not as fun to write as Python and Nim, but I don't have to write it.

I theorized this about a year ago and had a good amount of success vibing small game projects in Go.

I still think Go is a very excellent choice but I have switched to, of all things, AssemblyScript within a Rust host. I've been very happy with it - surprisingly so. Compile time is a major drawback of course.

Related, though 5 months is a long time: “A case for Go as the best language for AI agents” (getbruin.com)

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

203 points | 5 months ago | 304 comments

The readability is a plus at the same time if I target Rust and build it modular with lots of tests and io pure modules. The review part is not as important if the AI reviews it from various perspectives. With rust I get so much better performance and efficiency.

I agree with the article, but there's one thing Go has that doesn't help LLMs: structural typing. An LLM has to grep a little more to understand which interfaces a struct implements.

It's definitely more about the ecosystem than the language at this point.

I think the most important thing is how big the standard library is. Pulling in 3rd party dependencies is where I begin to lose a lot of faith with LLM authored code.

I'm currently writing a TUI for a harness I'm building in Go. It's a magical experience, truly.

I hate the rust v go wars, its not x vs y is 'best'. Rather is x better than y and by how much for xyz project done by ABC corp in this era?

As a lead I'd love to use rust, I will put in the time on my own, my team won't or can't. They treat this like any other job they signed up to deliver value with what they know. For hiring not everyone has the talent pool and fund access to get the goat-ed engineers that congregate to tech hubs for maximizing their income. Then if you get through that cherry on top is LLM's are only as smart as you guide it to be. There is probably a staggering amount of ways to write 1 approach to business logic, you may not know the ideal pattern so you'll commit to a worse one on the company dollar.

I'm moving my team's projects slowly to go because, its easy to go from novice to advanced in terms of code writing,legibility and patterns. We also don't have deep ecosystem requirements to ts/python in most of our work. It is verbose but I don't mind that on token spend if it gets done with with validation/error handling which it obnoxiously enforces. It runs cheap, ecosystem is good for platform eng, standard library does a ton out of box.

Can anyone recommend a strong Go design/development agent skill?

Language space is hot right now: https://agentlanguages.dev/

Only in so far that it is the language that I most desperately want to stop reading and writing myself.

Yeah, I use go and it's great. Most of the time the generated code is good quality also.

If a language is simple, it' easier to generate good code.

Just use rust

Go was designed as a systems language. They turned it into an applications language too, I'm guessing because turns out the greenthreading was uniquely good for that. But now it's awkward. The pointers and errors are not how you want an app lang to work. And LLMs struggle with error handling even more than humans.

Even as a systems lang, the error syntax is the worst part of Go. Can they at least put the ?/! syntax like in Rust instead of this "if err != nil" spam every other loc?

Yeah, no. Its good because LLM likes to copy paste things instead of doing code reuse which is the true go way of doing things. Imo, its hard to review Go code, probably why Go is yet to have a single correct Raft implementation.

I never seen k8s cluster that doesn't have some go process that segfaults once in a while because someone forgot to check `err`.

Only good thing got going for it is its vulnerability scanner. Which will be working overtime with all that "AI-assisted software engineering"

This seems like a cope, if you aren't writing the syntax who cares and everything here is even better with a stronger type system like Rust, F#, Scala, TypeScript.

99% of my projects are in NodeJS as web apps, so Javascript is king, my coding agents are in Node too, plain, boring, beautiful javascript, not typescript. Yesterday I needed a Rust project and my agents delivered so no need to change from JS

Boring is better. Perfection is the enemy of good.

Going to start writing Perl again then.

I'm firmly in the Go camp too but this just reads as unnecessary glazing

> Go solves this through unyielding consistency.

What? Why is the word "unyielding" used here? What was the point of generating this AI article on the google blog post?

all my LLM coding is in go these days

No it isn't. The best LLM software engineering language hasn't been invented yet. As a human, spaghetti code sucks and goto's are considered harmful. I can't reason above what my puny human brain can keep in context. Phone numbers are hard to remember, and that's only 7-10 digits. LLMs have no such problems, and as such, should be able to write more performant code given fewer constraints. Given a problem statement, an LLM could "hand" optimize assembly for the specific CPU the code is to run on, eg that exact Intel CPU's speculative decoder pipeline length.

In my opinion, the by far biggest problem Go has is called ...

Google.

Now one can say that a programming language and its design or usefulness is - or should be - decoupled from the company developing is. I am not opposed to this, in theory, but Google goes way too much on my nerves these days. And I am hardly the only one here.

I am not saying this is a rationale used by many other people either, mind you, but Rust has been taking strides (not that I am a huge fan of it either but for different reasons) and it seems to me as if Rust has finally now more momentum than Go, which I find interesting. Again, this may be a correlation rather than any causation, but I can not help but notice it.

says google

Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.

“…requires opinionated simplicity…”

Of course it can’t just be simplicity, it has to be “opinionated” simplicity. Rolls eyes.

lol "Why Go is really good - an article by Google"

i thought we all landed on Python. brb, rewriting backend

Because Go is an absurdly verbose language that hates to the core the idea of expressivity because it prides itself on being dumb.

Let me share a hot take. I am deliberately taking this somewhat to the extreme, so please attack the idea not the person. Looking for thoughtful replies and good counterpoints, rather than language zeal.

Let's assume that you need to write a program with a given set of requirements, and that you have a magic wand that can instantiate a high quality implementation of the program in any programming language instantaneously and for free. My hot take is that you would not want to choose Go, and you would likely want to choose Rust.

The Go implementation will have higher memory and CPU consumption due to garbage collection, while still being subject to memory bugs. The Rust implementation would be as efficient as possible on the given hardware with minimum memory/CPU, and it would be immune to memory bugs.

In my view, the biggest challenge with Rust, and where Go wins, is the relative difficulty of writing in Rust as the language is significantly more complex. With LLMs this is becoming a non-issue, and we are getting ever closer to having this magic wand (I'd argue that for smaller programs the wand already exists today). The article advocates that Go has excellent readability. I agree that Go has trivial syntax, but given that it's so verbose, I actually find it easier to read Rust code. Its higher expressivity allows you to see the higher level intention of a piece of code more easily.

Many of the other benefits the article mentions for Go are equally applicable to Rust: compiler error messages are super detailed and a great help to coding agents, auto-formatting, a great language server, and a package ecosystem.

[dead]

[flagged]

[flagged]

[flagged]

[dead]

[dead]

[dead]

[dead]

[flagged]

[dead]

[dead]

Nice try