341–350 of 586 posts
These have been my and friends' observations since LLM-assisted coding started picking up steam. Go's simplicity, consistency, stdlib and tooling seem to make it very reliable for LLM generation, and it was especially true during late 2025 / earlier this year when frontier models weren't as strong; might not be as noticeable now.
I disagree. LLMs fail to produce bug free concurrent code even for very simple cases. Golang lacks the ability to build descent abstractions, not even mentioning the wild west of additional tools and libraries needed for non trivial micro services. For me it is a red flag, that LLMs allow people to produce more bad Golang code faster. This is only optimization for companies which can afford enough software developers…
Go's generics are getting a fairly important improvement soon though! Generic methods, finally! It should help open up some more ergonomic patterns: https://tip.golang.org/doc/go1.27
Earlier quoted context omitted.
Go is heavily opinionated on style, design, and semantics. Its design was around being as concise as possible…which means token efficient. Yeah Go is my preferred language to code with AI. Second up is type script. Followed by Java, then Python.
Go design is not around being concise as possible, in fact it's the complete opposite. One of the cores behind Go is to make language simple, even if at the expense of more verbose code. Two main examples of this is the infamous 'if err != nil' and how you handle filter/map/funcional operations.
Earlier quoted context omitted.
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 wha…
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…
Earlier quoted context omitted.
Just reading the abstract, it talks about finding a number of bugs (across millions of lines of code) but I didn't see any claims that there would be fewer bugs in a different language. Go obviously does not stop you from writing buggy code. Neither does rust or zig or whatever. Does go make it more likely to have bugs? Or a specific class of bug? Like, the real world is about trade offs.
Uber has fairly large golang and java codebases so they have more of an apple to apples comparison here since they are both GC languages of a similar performance class. And if a large population tends to make more mistakes with 200hp sedan A vs 200hp sedan B, there is probably something up with the design of sedan A.
Earlier quoted context omitted.
Go design is not around being concise as possible, in fact it's the complete opposite. One of the cores behind Go is to make language simple, even if at the expense of more verbose code. Two main examples of this is the infamous 'if err != nil' and how you handle filter/map/funcional operations.
Yes but it’s err not error. The variable and method names are meant to be concise and highly readable without the CS fluff of Java naming hell.
On the other hand, being able to write 'list.filter(v => v.selected)' (or something similar) instead of:
listFiltered := []Item{}
for _, item := range list {
if item.selected {
listFiltered = append(listFiltered, item)
}
}
I wouldn't take language advice from a Product Manager and Chief Evangelist from anywhere - and especially not Google. Having said that: my opinion is that LLMs thrive by working in a tight loop. Unlike a human, they thrive with more and tighter constraints (and the better models are obviously far better in this regard). I want to ditch the things that made writing code easier due to the limitations of humans, and em…