7 ms·

Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency shou

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 dozens in Java, C++, and Rust. Antithesis found some more bugs in HashiCorp's Raft implementation recently[0]. I'm sure etcd still has some kicking around. Maybe this is a "don't throw the baby out with the bath water' problem but the general evolution of Go has been lackluster. I reach for Rust, Zig, and modern Java instead depending on the specific needs and constraints. 0 - https://antithesis.com/blog/2026/finding-bugs-in-raft-implementations/ https://antithesis.com/blog/2026/finding-bugs-in-raft-implem...

ramoz 1mo ago
That does not seem like a fair/accurate reference? The antithesis author states: "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft"
- rubiquity 1mo ago
  You're misreading what I said. I didn't say other languages don't have buggy Raft/Paxos implementations, just that Go is yet to yield a single correct one.
  - jibal 1mo ago
    I think you're projecting. You wrote > Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. That says that there are correct (i.e., bug-free) implementations in those languages. The GP noted > "we’ve found bugs in every Raft implementation we’ve tested, ..." which says that there aren't any correct ones. You then wrote > I didn't say other languages don't have buggy Raft/Paxos implementations which is a strawman. The issue is whether there are correct implementations. That there are buggy ones is irrelevant. (FWIW I have no dog in this fight ... I'm just reading here.)
    - rubiquity 1mo ago
      The intersection of the set of Raft libraries Antithesis tested and all Raft libraries in existence do not fully overlap. I personally have worked on multiple proprietary ones that Antithesis would not have access to.
      - 0x696C6961 1mo ago
        Lol "I swear have a girlfriend, she just goes to a different school"
      - jibal 1mo ago
        Even if so, the "You're misreading what I said" charge was bogus and it would be nice if you admitted that. Edit: > What are they implying by citing that? That Raft implementations in all languages have bugs? That's what it says. > I've already pointed out that is false. You claimed that, and it's being disputed. > Please let me know, since you're so comfortable speaking for them. This has veered into bad faith ... I won't comment further.
        overfeed 1mo ago
        Further, they can still edit their comment to correct it, but opting not to.
        rubiquity 1mo ago
        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 make Raft implementations for fun and learning. Again, Go does not have a single Raft/Paxos implementation that is rock solid. I have seen many in C++, Java, and Rust that are doing tens of millions of requests per second in production for over a decade. Is their point that Go is not the only language with this problem? My post already points out the track record is that Go is the problem for writing correct code in highly critical domains.
hintymad 1mo ago
Java has so many excellent concurrency containers, plus robust 3rd-party containers like JCTools. It puzzles me why Go communities do not offer such containers.
- Groxx 1mo ago
  No thread/goroutine handles for fork/join handling from "outside", and no generics for many formative years that influenced tons of habits, then significantly weaker generics (improving very soon[1]), have all led to most concurrent code to be very "intrusive" - you create bare threads and add bare synchronization primitives (or nearly) by hand inside the threaded code to make it concurrent. `errgroup` is as far as a lot of code goes, in terms of sophistication. Java leans heavily in the other direction: a lot of concurrency is added externally, without changing existing code, often in very declarative-flavored ways. E.g. Future<T> serves as a foundation for a ridiculous amount of stuff, while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics. There are very obviously lots of counter-examples for both langs (`synchronized`, rill in Go, etc), and I expect Go to become more Java-flavored in time (it already has moved this direction somewhat, and 1.27 will enable a lot more). But I think it's a fair summary of broad ecosystem habits. 1: https://tip.golang.org/doc/go1.27 https://tip.golang.org/doc/go1.27 (not yet released)
  - hintymad 1mo ago
    It sounds like Go didn't follow the suggestion of pretty much every CS books on concurrency: favor containers over concurrency primitives. > while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics. I understand that Go's concurrency model is based on CSP and fork-joins and the primitives like locks, but they are not mutually exclusive with concurrency containers, right? It's okay if the Go team's core philosophy is that channels are the universal abstraction, but I don't get why the community didn't produce 3rd-party containers as robust as JCTools.
    - 1mo ago
Thaxll 1mo ago
The "world" runs on Kubernetes which is using Raft: https://pkg.go.dev/go.etcd.io/etcd/raft/v3 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, Project Calico, Flannel, Hyperledger and more." One of the most popular distributed DB is Cockroach which is written in go and also uses Raft: https://github.com/cockroachdb/cockroach/tree/master/pkg/raft https://github.com/cockroachdb/cockroach/tree/master/pkg/raf...
- aksss 1mo ago
  That's not remotely what he's saying at all.
  - rubiquity 1mo ago
    Thank you. I don't know why this is so complicated.
  - volkk 1mo ago
    > As another example, Go still has not yielded a correct implementation of Raft or Paxos > are you saying this implementation is wrong? > That's not remotely what he's saying at all. I'm v confused by this thread
  - quietbritishjim 1mo ago
    I don't care for Go myself (especially its concurrency model, which is a total dinosaur in a world where we have structured concurrency) so I'm not saying this to support my favourite language, but: That is literally what the comment says.
- rubiquity 1mo ago
  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-amazon-eks-ultra-scale-clusters/ https://aws.amazon.com/blogs/containers/under-the-hood-amazo...
mrsilencedogood 1mo ago
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 you see in real life.
- rubiquity 1mo ago
  My experience as well. LLMs also struggle with Rust's many abstractions and offerings but you can know that if it compiles it is data race free and work with the LLM to use better abstractions over time. Zig is also good at this but requires more up front design (thread-per-core, static allocation, etc.) and consistent checks to verify rules are followed.
  - bb88 1mo ago
    C/C++ has "compiles but may have undefined behavior". Golang has numerous "compiles but has incorrect behavior" (normally known as footguns). Meanwhile with Rust, if you get past the compilation step, bugs become much much fewer. (You can still have memory leaks, but those are easily traceable). It seems like claude code can code Rust pretty well with Opus, and I've started moving codebases away from Golang to Rust at work with Opus. Spin up an LLM and it cranks on it for a while, and as a benefit, I get easy apis to build on with other languages. And that's the problem with Golang really, not that it's a bad language per se (all languages have footguns), but that the language interoperability story is terrible. Meanwhile Rust and Python/C/C++ go great together like peanut butter and chocolate. And I love it.
    - maleldil 1mo ago
      > You can still have memory leaks And deadlocks. "Fearless concurrency" helps a lot, but logic bugs are still possible.
      - 1mo ago
jeffbee 1mo ago
What primitives are we discussing? Any Go programmer can and should use the `go` keyword and the `sync.Mutex` type from their first program.
- closeparen 1mo ago
  It's pretty easy to get yourself into trouble with channels: deadlocks, send on closed, channel leaks, deadlocks "fixed" thoughtlessly with arbitrarily-sized buffers, etc.
  - jeffbee 1mo ago
    This seems to have little to do with Go's facilities. Any concurrent program has hazards like these.
    - closeparen 1mo ago
      In my experience, shared memory instills the appropriate fear and caution, while the apparent simplicity of channels encourages novice Go programers to take on concurrency projects beyond their abilities and without due care. Been on both the submitter and reviewer side of that plenty of times in 10 years.
    - treyd 1mo ago
      Rust's concurrency libraries leverage the type system to make these issues much harder to encounter.
      - jeffbee 1mo ago
        Rust's std::sync::mpsc contains most of the hazards of Go's channel, and arguably adds some because the Go runtime provides deadlock detection that Rust lacks.
jerf 1mo ago
You seem to be implying, based on the rest of the thread, that Go has some sort of special defect that keeps it from implementing Raft correctly. But the "special defect" that Go has is that it in practice implements the same primitives in practice that almost every other mainstream language does, rather than implementing some sort of super-safe concurrency primitive like Erlang or Pony, or being immutable like Haskell. And even those things are of only marginal utility for Raft, preventing some local issues, but the hard part of Raft is more in the logic and the communication, for which none of these languages have any sort of special support or anything that will particularly help you get it right. Of the languages you listed only Rust provides any assistence over the standard mainstream languages, and like I said, in the context of Raft, it is not necessarily all that helpful. If you want to see something that could potentially impact Raft's correctness, search the last couple of days of the HN front page for choreographic languages [1]. But none of these are even remotely mainstream enough to depend on for anything. Nor do I know if anyone in these languages has implemented Raft. A rather good test case for them, if any of them are looking. That's something that could actually help a Raft implementation's correctness, not just fiddle around the edges of local concurrency issues. [1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=choreogra&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- lokar 1mo ago
  Also, wasn’t this about concurrency? You could, if you really wanted, write a paxos or raft implementation with no concurrency.
HAL3000 1mo ago
> 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 now their company does not exist anymore and we have a lot of their clients. Thank you!
- deleted 1mo ago
  [deleted]
- za3faran 1mo ago
  What domain is your company in?
- sunrunner 1mo ago
  Perhaps that company failed because it chose to port things to Rust and not because of Rust itself? Or any other number of reasons that survivorship bias might be mistaking.
  - yawaramin 1mo ago
    Lol, so Rust is perfect until you actually try to do something with it.
    - sunrunner 1mo ago
      I emphasised too much in that comment perhaps. I was going for because it chose to port things, meaning that maybe that company wasted time working on porting things instead of working on things needed to survive.
- xvedejas 1mo ago
  Where would one ever read that Go is not memory safe? That's just a false claim, and anyone believing it would have probably gone out of business regardless of choice of programming language.
a2ff6eeb0 1mo ago
Yeah, but AI is better at debugging than people are, so what's the issue?
evil-olive 1mo ago
> 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)
tptacek 1mo ago
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.

ramoz 1mo ago

That does not seem like a fair/accurate reference? The antithesis author states: "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft"

rubiquity 1mo ago
You're misreading what I said. I didn't say other languages don't have buggy Raft/Paxos implementations, just that Go is yet to yield a single correct one.
- jibal 1mo ago
  I think you're projecting. You wrote > Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. That says that there are correct (i.e., bug-free) implementations in those languages. The GP noted > "we’ve found bugs in every Raft implementation we’ve tested, ..." which says that there aren't any correct ones. You then wrote > I didn't say other languages don't have buggy Raft/Paxos implementations which is a strawman. The issue is whether there are correct implementations. That there are buggy ones is irrelevant. (FWIW I have no dog in this fight ... I'm just reading here.)
  - rubiquity 1mo ago
    The intersection of the set of Raft libraries Antithesis tested and all Raft libraries in existence do not fully overlap. I personally have worked on multiple proprietary ones that Antithesis would not have access to.
    - 0x696C6961 1mo ago
      Lol "I swear have a girlfriend, she just goes to a different school"
    - jibal 1mo ago
      Even if so, the "You're misreading what I said" charge was bogus and it would be nice if you admitted that. Edit: > What are they implying by citing that? That Raft implementations in all languages have bugs? That's what it says. > I've already pointed out that is false. You claimed that, and it's being disputed. > Please let me know, since you're so comfortable speaking for them. This has veered into bad faith ... I won't comment further.
      - overfeed 1mo ago
        Further, they can still edit their comment to correct it, but opting not to.
      - rubiquity 1mo ago
        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 make Raft implementations for fun and learning. Again, Go does not have a single Raft/Paxos implementation that is rock solid. I have seen many in C++, Java, and Rust that are doing tens of millions of requests per second in production for over a decade. Is their point that Go is not the only language with this problem? My post already points out the track record is that Go is the problem for writing correct code in highly critical domains.

hintymad 1mo ago

Java has so many excellent concurrency containers, plus robust 3rd-party containers like JCTools. It puzzles me why Go communities do not offer such containers.

Groxx 1mo ago
No thread/goroutine handles for fork/join handling from "outside", and no generics for many formative years that influenced tons of habits, then significantly weaker generics (improving very soon[1]), have all led to most concurrent code to be very "intrusive" - you create bare threads and add bare synchronization primitives (or nearly) by hand inside the threaded code to make it concurrent. `errgroup` is as far as a lot of code goes, in terms of sophistication. Java leans heavily in the other direction: a lot of concurrency is added externally, without changing existing code, often in very declarative-flavored ways. E.g. Future<T> serves as a foundation for a ridiculous amount of stuff, while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics. There are very obviously lots of counter-examples for both langs (`synchronized`, rill in Go, etc), and I expect Go to become more Java-flavored in time (it already has moved this direction somewhat, and 1.27 will enable a lot more). But I think it's a fair summary of broad ecosystem habits. 1: https://tip.golang.org/doc/go1.27 https://tip.golang.org/doc/go1.27 (not yet released)
- hintymad 1mo ago
  It sounds like Go didn't follow the suggestion of pretty much every CS books on concurrency: favor containers over concurrency primitives. > while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics. I understand that Go's concurrency model is based on CSP and fork-joins and the primitives like locks, but they are not mutually exclusive with concurrency containers, right? It's okay if the Go team's core philosophy is that channels are the universal abstraction, but I don't get why the community didn't produce 3rd-party containers as robust as JCTools.
  - 1mo ago

Thaxll 1mo ago

The "world" runs on Kubernetes which is using Raft: https://pkg.go.dev/go.etcd.io/etcd/raft/v3 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, Project Calico, Flannel, Hyperledger and more." One of the most popular distributed DB is Cockroach which is written in go and also uses Raft: https://github.com/cockroachdb/cockroach/tree/master/pkg/raft https://github.com/cockroachdb/cockroach/tree/master/pkg/raf...

aksss 1mo ago
That's not remotely what he's saying at all.
- rubiquity 1mo ago
  Thank you. I don't know why this is so complicated.
- volkk 1mo ago
  > As another example, Go still has not yielded a correct implementation of Raft or Paxos > are you saying this implementation is wrong? > That's not remotely what he's saying at all. I'm v confused by this thread
- quietbritishjim 1mo ago
  I don't care for Go myself (especially its concurrency model, which is a total dinosaur in a world where we have structured concurrency) so I'm not saying this to support my favourite language, but: That is literally what the comment says.
rubiquity 1mo ago
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-amazon-eks-ultra-scale-clusters/ https://aws.amazon.com/blogs/containers/under-the-hood-amazo...

mrsilencedogood 1mo ago

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 you see in real life.

rubiquity 1mo ago
My experience as well. LLMs also struggle with Rust's many abstractions and offerings but you can know that if it compiles it is data race free and work with the LLM to use better abstractions over time. Zig is also good at this but requires more up front design (thread-per-core, static allocation, etc.) and consistent checks to verify rules are followed.
- bb88 1mo ago
  C/C++ has "compiles but may have undefined behavior". Golang has numerous "compiles but has incorrect behavior" (normally known as footguns). Meanwhile with Rust, if you get past the compilation step, bugs become much much fewer. (You can still have memory leaks, but those are easily traceable). It seems like claude code can code Rust pretty well with Opus, and I've started moving codebases away from Golang to Rust at work with Opus. Spin up an LLM and it cranks on it for a while, and as a benefit, I get easy apis to build on with other languages. And that's the problem with Golang really, not that it's a bad language per se (all languages have footguns), but that the language interoperability story is terrible. Meanwhile Rust and Python/C/C++ go great together like peanut butter and chocolate. And I love it.
  - maleldil 1mo ago
    > You can still have memory leaks And deadlocks. "Fearless concurrency" helps a lot, but logic bugs are still possible.
    - 1mo ago

jeffbee 1mo ago

What primitives are we discussing? Any Go programmer can and should use the `go` keyword and the `sync.Mutex` type from their first program.

closeparen 1mo ago
It's pretty easy to get yourself into trouble with channels: deadlocks, send on closed, channel leaks, deadlocks "fixed" thoughtlessly with arbitrarily-sized buffers, etc.
- jeffbee 1mo ago
  This seems to have little to do with Go's facilities. Any concurrent program has hazards like these.
  - closeparen 1mo ago
    In my experience, shared memory instills the appropriate fear and caution, while the apparent simplicity of channels encourages novice Go programers to take on concurrency projects beyond their abilities and without due care. Been on both the submitter and reviewer side of that plenty of times in 10 years.
  - treyd 1mo ago
    Rust's concurrency libraries leverage the type system to make these issues much harder to encounter.
    - jeffbee 1mo ago
      Rust's std::sync::mpsc contains most of the hazards of Go's channel, and arguably adds some because the Go runtime provides deadlock detection that Rust lacks.

jerf 1mo ago

You seem to be implying, based on the rest of the thread, that Go has some sort of special defect that keeps it from implementing Raft correctly. But the "special defect" that Go has is that it in practice implements the same primitives in practice that almost every other mainstream language does, rather than implementing some sort of super-safe concurrency primitive like Erlang or Pony, or being immutable like Haskell. And even those things are of only marginal utility for Raft, preventing some local issues, but the hard part of Raft is more in the logic and the communication, for which none of these languages have any sort of special support or anything that will particularly help you get it right. Of the languages you listed only Rust provides any assistence over the standard mainstream languages, and like I said, in the context of Raft, it is not necessarily all that helpful. If you want to see something that could potentially impact Raft's correctness, search the last couple of days of the HN front page for choreographic languages [1]. But none of these are even remotely mainstream enough to depend on for anything. Nor do I know if anyone in these languages has implemented Raft. A rather good test case for them, if any of them are looking. That's something that could actually help a Raft implementation's correctness, not just fiddle around the edges of local concurrency issues. [1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=choreogra&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

lokar 1mo ago
Also, wasn’t this about concurrency? You could, if you really wanted, write a paxos or raft implementation with no concurrency.

HAL3000 1mo ago

> 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 now their company does not exist anymore and we have a lot of their clients. Thank you!

deleted 1mo ago
[deleted]
za3faran 1mo ago
What domain is your company in?
sunrunner 1mo ago
Perhaps that company failed because it chose to port things to Rust and not because of Rust itself? Or any other number of reasons that survivorship bias might be mistaking.
- yawaramin 1mo ago
  Lol, so Rust is perfect until you actually try to do something with it.
  - sunrunner 1mo ago
    I emphasised too much in that comment perhaps. I was going for because it chose to port things, meaning that maybe that company wasted time working on porting things instead of working on things needed to survive.
xvedejas 1mo ago
Where would one ever read that Go is not memory safe? That's just a false claim, and anyone believing it would have probably gone out of business regardless of choice of programming language.

a2ff6eeb0 1mo ago

Yeah, but AI is better at debugging than people are, so what's the issue?

evil-olive 1mo ago

> 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)

tptacek 1mo ago

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.