Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

301–310 of 586 posts

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

#301
post #218

Earlier quoted context omitted.

etcd has had numerous liveness and safety bugs, with one happening as recently as December of 2025. Would you consider that a correct implementation? You may be interested in knowing that the largest managed Kubernetes service in the world (AWS EKS) ripped out etcd for in favor of their homegrown consensus service for large scale EKS clusters: https://aws.amazon.com/blogs/containers/under-the-hood-amazo...

I'd like to know what you base your statement on that the Raft implementations in etcd or CockroachDB are incorrect. Your original paper does not mention those implementations, so where does that claim come from?

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 what they're talking about. Also those bugs have nothing to do with the raft implementation, but instead the state machine implemented on top.

0: https://etcd.io/blog/2025/autonomus_testing_with_antithesis/

1: https://jepsen.io/analyses/etcd-3.4.3

2: https://github.com/etcd-io/raft/pull/113

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

#302
post #30

Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do. Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting? Think about what you are doing and choose appropriately. This was true before LL…

How dare you suggest having fun! Pay attention! We’re trying to have a language flame war here!

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

#304

Earlier quoted context omitted.

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 is bad so "I reach for Rust, Zig..." I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success. Some time has passed and…

What domain is your company in?

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

#305

Earlier quoted context omitted.

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…

To combine both TFA with this comment: I find that LLMs are ~fine at generating/editing gocode, or at least as ~fine as they generate most mainstream languages. But good god, the second it gets to anything concurrency-related, it just loses its mind. As much as it's gotten vaguely ok to try to let the agents loose on some bits of the codebase, they simply can't even do table stakes stuff with the kinds of concurrency…

I wouldn't be surprised if Java has a much better experience here. After all, java.util.concurrent has many great implementations, and Java's `record`s are immutable, as are it's upcoming value types.

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

#307

I love the sleight of hand this blog post tries to pull off here. It doesn't matter than Go isn't fun to write because the AI is doing it now! Yeah so it sucked for the last twenty years? I know the main thesis is that Go is holistically good at software engineering so its weakness as a programming language is minimized. I've made a similar arguments that coding agents push the burden more into the other aspects of s…

I've never found that Go is not fun to write. On the contrary... Go is pretty refreshing with its simplicity. I found myself to be immensely productive writing Go.

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

#308

I love the sleight of hand this blog post tries to pull off here. It doesn't matter than Go isn't fun to write because the AI is doing it now! Yeah so it sucked for the last twenty years? I know the main thesis is that Go is holistically good at software engineering so its weakness as a programming language is minimized. I've made a similar arguments that coding agents push the burden more into the other aspects of s…

It pulls no such sleight of hand, and you have invented a wholesale strawman.

It's also simply poorly informed. Go is a fantastically enjoyable language to program in. In many ways that has been a bit of its curse compared to languages like Rust (which is legitimately a not fun language to write it, and which AI tools are also very good at writing), because keeping the language simple has hobbled some edge cases.

I don't write a lot of Go as my professional life has pushed me more to Rust, but Go and Object Pascal are easily the two most enjoyable languages I've ever developed in.

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

#309
post #51
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…

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?

The best way to write concurrency in any language is a single threaded polling loop. Goroutines and messages are just as bad as all the other alternatives, which is to say they are a miserable way to write code.

But Go is also perfectly good at single threaded polling loops.

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

#310

I love the sleight of hand this blog post tries to pull off here. It doesn't matter than Go isn't fun to write because the AI is doing it now! Yeah so it sucked for the last twenty years? I know the main thesis is that Go is holistically good at software engineering so its weakness as a programming language is minimized. I've made a similar arguments that coding agents push the burden more into the other aspects of s…

On the list of languages/ecosystems that make me want to rip my hair off, Go is way below.

Javascript takes the throne on that one.

Post reply on HN