Go is an ideal language for AI-assisted software engineering • Hacker News Board

Re: Go is an ideal language for AI-assisted software engineering

#381

Post by jibal » Wed, Aug 12, 2026, 3:53 AM UTC

FireBeyond wrote: post #366

rubiquity wrote: post #175

Earlier quoted context omitted.

But they are misreading what I said. My original post is clearly about Go. What they wrote is also ambiguous. > The antithesis author states: > "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft" What are they implying by citing that? That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people m…

You're being very mealy-mouthed, even here, it reads as "The pre-eminent Go implementation can't even get it right" and yet the implementations Antithesis tested in Rust are apparently people's random "fun and learning" projects, nothing serious, and certainly not all the proprietary implementations that you've used that are all correct.

Also, it simply isn't true that @ramoz misread what they wrote, as I pointed out in both of my comments.

Re: Go is an ideal language for AI-assisted software engineering

#382

Post by zarzavat » Wed, Aug 12, 2026, 3:57 AM UTC

My calculus is very simple these days:

If I care about performance, use Rust.

If I care about iteration speed, use TypeScript.

If I want a script or numerical code, use Python.

LLMs are better with Rust because the more expressive type system provides stronger guardrails especially when writing multithreaded code. Go is almost the worst conceivable design of a programming language for LLMs: powerful but weak guardrails. Only C and C++ would be worse.

LLMs don't struggle with the low-level lifetimes like humans do. They struggle with the high-level view because of limited context windows. That's why you want a powerful type system to enforce those global constraints. Go ain't it.

Re: Go is an ideal language for AI-assisted software engineering

#383

Post by evil-olive » Wed, Aug 12, 2026, 4:04 AM UTC

rubiquity wrote: post #60

yosefk wrote: post #51

Earlier quoted context omitted.

Uber reported that their Go code has quantitatively more concurrency bugs than code in other languages, and while to me it seems obvious from looking at Go's concurrency model, this is backed by actual data. Is there any quantitative data to back the claim that Go is better in an LLM based workflow than another popular language?

Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code. As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are do…

> Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. Antithesis found some more bugs in HashiCorp's Raft implementation recently[0].

the source you link to contradicts your own claims.

they say:

> we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft

(besides Go, that's 2 in Java and 1 in Rust)

Re: Go is an ideal language for AI-assisted software engineering

#384

Post by tptacek » Wed, Aug 12, 2026, 4:05 AM UTC

rubiquity wrote: post #60

yosefk wrote: post #51

Earlier quoted context omitted.

Uber reported that their Go code has quantitatively more concurrency bugs than code in other languages, and while to me it seems obvious from looking at Go's concurrency model, this is backed by actual data. Is there any quantitative data to back the claim that Go is better in an LLM based workflow than another popular language?

Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code. As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are do…

The Raft bugs are the wrong kind of concurrency --- they're distsys bugs, not multithreading bugs. Not a good example, and a little telling that you'd cite it.

Re: Go is an ideal language for AI-assisted software engineering

#385

Post by gertlabs » Wed, Aug 12, 2026, 4:06 AM UTC

jeanbza wrote: post #27

Definitely agree with this article. At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages. Two additional notes I'll add: - Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://goo…

We've seen a pretty consistent pattern in our evaluations where Go is among the languages that models perform worst with (alongside Python), for reasons unclear. Our coding evaluations are typically measuring the foresight and planning expressed in code that is run in interactive environments/games.

This trend has been there since we started evaluating models using different languages in February 2026 and if anything, the disparity has grown in frontier models. Even Google models prefer Kotlin/C#/Rust for coming up with creative ideas (compilation success is a different story). Data at https://gertlabs.com/rankings

That being said, models love to recommend Go, and Go does have a lot going for it, especially if you are serving a public-facing website. So most of our public facing API handlers are written in Go, and we offload some of our most important binaries to Rust. There are just too many reasons not to use the languages that models think a little more effectively in.

Re: Go is an ideal language for AI-assisted software engineering

#386

Post by beaker52 » Wed, Aug 12, 2026, 4:06 AM UTC

It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making.

What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go.

Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squinted eyes. But the teams I work with are working on sprawling, evolving software where the compiler saying “hey, that’s not a valid Widget” would be extremely useful and save much heartache.

An LLM does a good job of “checking” for other uses and “checking” if everything is going to work correctly, but - supposedly we’ve committed the concept to code so that the compiler can actually verify it - and Go intentionally permits invalid states of structs. This makes Go a fundamentally problematic language choice for the kind of software I work with teams on, LLM or not.

Re: Go is an ideal language for AI-assisted software engineering

#387

Post by AlphaSite » Wed, Aug 12, 2026, 4:08 AM UTC

iscoelho wrote: post #363

gyesxnuibh wrote: post #301

Earlier quoted context omitted.

Having run a fleet of 100s of etcd clusters for 10000s of rps, and the fact that upstream runs tests similar to antithesis and recently partnered with antithesis [0], and jepsen has tested it long ago as well [1]. Etcd's raft algorithm is fine. Someone even did a TLA+ proof on it in the last couple years[2]. Yes there was a correctness issue a few years ago but otherwise the person you're replying to doesn't know wha…

"there was a correction issue" is downplaying it. Etcd is truly the worst example of Raft. Etcd corruption and loss of quorum is extremely common in practice and the GitHub issues sit for years. The design is simple, the performance is modest, yet it still has still never been reliable, despite being marketed as so. I can't speak to whether this is specifically due to their Raft implementation, but I'd argue the enti…

My beef with etcd is that its neither performant nor reliable.

Its very much {reliable, performant, flexible} pick none.

Re: Go is an ideal language for AI-assisted software engineering

#388

Post by wltr » Wed, Aug 12, 2026, 4:32 AM UTC

soupbowl wrote: post #73

wltr wrote: post #48

Earlier quoted context omitted.

Been doing bash scripting for years. Tried Go recently, on my, it’s so much better for everything OS scripting. I regret I haven’t started with Go years ago. All my scripts are rewritten to Go. I kept only a handful, those that are just a few lines and no logic.

Are you using 'go run' or compiling these scripts? Just curious about what you are up to as I was considering moving my scripts from bash to go.

Most of the time I use go build, or precisely make install with custom Makefile. For the one-time ad-hoc tools (vibe coded, by the way), I may use go run. My point is use the simplest tool, if it’s a little bit more complex than a few lines, it’s better in Go than bash. Here, I rather mean it’s better in any real programming language. Just… well, Go is really simple and with some GPT assistance you may be just one prompt and a minute away from automating some routine tasks. I try to automate as much as I can notice. E.g. I have a special script (now program) which moves files and directories from one location (synced documents) to another (archive on a disk). This is just a very simple operation, but doing it automatically feels very different. I’d highly recommend on trying something similar. Previously, I thought bash is good enough for this (and it is!), but Go is just better for me personally. And bonus thing, it works much faster.

Re: Go is an ideal language for AI-assisted software engineering

#389

Post by steve1977 » Wed, Aug 12, 2026, 4:36 AM UTC

ablob wrote: post #318

Thaxll wrote: post #139

Earlier quoted context omitted.

The "world" runs on Kubernetes which is using Raft: https://pkg.go.dev/go.etcd.io/etcd/raft/v3 Are you saying that this implementation is wrong? "This Raft library is stable and feature complete. As of 2016, it is the most widely used Raft library in production, serving tens of thousands clusters each day. It powers distributed systems such as etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Pr…

Surely the King is doing it, so that must be the correct way. Look, the King even wears clothes and is totally not naked at all. That the world runs on Kubernetes is no qualitative statement about the correctness of its Raft implementation. You can say that it's clearly good enough to not matter most of the time, but that is a different statement. No matter who you look at, they're just cooking with gas like you do,…

It's not even a qualitative statement about Kubernetes.

Re: Go is an ideal language for AI-assisted software engineering

#390

Post by fragmede » Wed, Aug 12, 2026, 4:41 AM UTC

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.