3 ms·

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 t

by Thaxll 2mo 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 2mo ago
That's not remotely what he's saying at all.
- rubiquity 2mo ago
  Thank you. I don't know why this is so complicated.
- quietbritishjim 2mo 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.
- volkk 2mo 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
rubiquity 2mo 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...
- fl0ki 2mo ago
  etcd is some of the most amateur code I've ever seen, despite being one of the oldest and presumably most mature "infrastructure" projects written in Go. goBGP is arguably even worse. I don't have a third place in mind that's even worth mentioning relative to these two.
  - alfons_foobar 2mo ago
    just curious, what problems do you see with gobgp? (I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)
    - iscoelho 2mo ago
      Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1]. [1] https://elegantnetwork.github.io/posts/comparing-open-source-bgp-stacks/ https://elegantnetwork.github.io/posts/comparing-open-source...
      - preisschild 2mo ago
        Garbage collected languages like Go will always have worse performance than lower level languages like C (frr and bird are implemented in C). Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.
        tsss 2mo ago
        No they won't. They are generally faster in throughput than any non-gc application that isn't heavily hand optimized. Their problems are higher memory usage and unpredictable latency, not speed.
        pjmlp 2mo ago
        Nope, it is a matter of skill as well. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
formerly_proven 2mo ago
Now there's three of them https://github.com/hashicorp/raft https://github.com/hashicorp/raft
ablob 2mo ago
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, and they can make mistakes in just the same way. Now; I'm only attacking your argument. I do neither know nor particularly care about the correctness of that implementation itself. There's been better refutations of the claim you replied to in other answers anyway.
- steve1977 2mo ago
  It's not even a qualitative statement about Kubernetes.
  - otabdeveloper4 2mo ago
    Kubernetes doesn't solve any technical problem, so the language it's written in is irrelevant.
    - Yasuraka 2mo ago
      I have a bunch of volumes that I'd like to get automatically attached and mounted to nodes on which their respective workload runs (which are automatically scheduled) who automatically fetch and mount their config files and secrets from a HA DB on demand. I also need some internal loadbalancing and integrations with something like certbot for all of my web workloads. Id also like to make sure that I get metrics and logs from every workload in some form. Thats basically it for starters, what non-technical solution do you propose?
      - otabdeveloper4 2mo ago
        If k8s works for you, then go for it. But k8s was invented so that "dev" and "ops" teams could play nicely when they are different org structures, with their own budgets, deadlines, etc. If it solves some technical issue then that's incidental.
literalAardvark 2mo ago
etcd is notoriously unreliable and one of the biggest problems in k8s. I didn't know Go just isn't a good language for it, but now that I know I'm no longer surprised at etcd being problematic.
- preisschild 2mo ago
  Having maintained multiple etcd clusters for self-managed kubernetes the last few years I disagree with the "problematic" characterization. Sure it may not be the best fit in a scenario where you want a cluster spanned over the entire globe (thats why GKE uses paxos-based Spanner instead of it) , but even spanned across an entire continent (in europe via glass fiber) it works quite well for me. Its one of the least problematic parts of the stack.
- Manfrednotfunny 2mo ago
  I'm running big k8s cluster and my small ones at home for 8 years, never had an etcd issue. Could you elaborate?

by Thaxll 2mo ago

aksss 2mo ago

That's not remotely what he's saying at all.

rubiquity 2mo ago
Thank you. I don't know why this is so complicated.
quietbritishjim 2mo 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.
volkk 2mo 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

rubiquity 2mo 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...

fl0ki 2mo ago
etcd is some of the most amateur code I've ever seen, despite being one of the oldest and presumably most mature "infrastructure" projects written in Go. goBGP is arguably even worse. I don't have a third place in mind that's even worth mentioning relative to these two.
- alfons_foobar 2mo ago
  just curious, what problems do you see with gobgp? (I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)
  - iscoelho 2mo ago
    Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1]. [1] https://elegantnetwork.github.io/posts/comparing-open-source-bgp-stacks/ https://elegantnetwork.github.io/posts/comparing-open-source...
    - preisschild 2mo ago
      Garbage collected languages like Go will always have worse performance than lower level languages like C (frr and bird are implemented in C). Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.
      - tsss 2mo ago
        No they won't. They are generally faster in throughput than any non-gc application that isn't heavily hand optimized. Their problems are higher memory usage and unpredictable latency, not speed.
      - pjmlp 2mo ago
        Nope, it is a matter of skill as well. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages

formerly_proven 2mo ago

Now there's three of them https://github.com/hashicorp/raft https://github.com/hashicorp/raft

ablob 2mo ago

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, and they can make mistakes in just the same way. Now; I'm only attacking your argument. I do neither know nor particularly care about the correctness of that implementation itself. There's been better refutations of the claim you replied to in other answers anyway.

steve1977 2mo ago
It's not even a qualitative statement about Kubernetes.
- otabdeveloper4 2mo ago
  Kubernetes doesn't solve any technical problem, so the language it's written in is irrelevant.
  - Yasuraka 2mo ago
    I have a bunch of volumes that I'd like to get automatically attached and mounted to nodes on which their respective workload runs (which are automatically scheduled) who automatically fetch and mount their config files and secrets from a HA DB on demand. I also need some internal loadbalancing and integrations with something like certbot for all of my web workloads. Id also like to make sure that I get metrics and logs from every workload in some form. Thats basically it for starters, what non-technical solution do you propose?
    - otabdeveloper4 2mo ago
      If k8s works for you, then go for it. But k8s was invented so that "dev" and "ops" teams could play nicely when they are different org structures, with their own budgets, deadlines, etc. If it solves some technical issue then that's incidental.

literalAardvark 2mo ago

etcd is notoriously unreliable and one of the biggest problems in k8s. I didn't know Go just isn't a good language for it, but now that I know I'm no longer surprised at etcd being problematic.

preisschild 2mo ago
Having maintained multiple etcd clusters for self-managed kubernetes the last few years I disagree with the "problematic" characterization. Sure it may not be the best fit in a scenario where you want a cluster spanned over the entire globe (thats why GKE uses paxos-based Spanner instead of it) , but even spanned across an entire continent (in europe via glass fiber) it works quite well for me. Its one of the least problematic parts of the stack.
Manfrednotfunny 2mo ago
I'm running big k8s cluster and my small ones at home for 8 years, never had an etcd issue. Could you elaborate?