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, 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/raf...

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

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&que...

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"

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.

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.

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

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.

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

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

This is the actual link to the academic paper (https://arxiv.org/pdf/2204.00764)

That article is meh. All of those issues are either addressed or junior programmer mistakes.

Yes, it's a bit of blame the user which will likely get the retort of "but I thought Go was perfect for junior engineers?"

Yes, there are footguns but none of the points therein were compelling.

What concrete arguments are there to believe in your talent hypothesis instead of their tool hypothesis?

A couple more comments like this from you, and I'll be able to say, "cyanmoonx has a history of blaming the talent rather than bad tools". There being a history like that is neither an argument for nor against tools being bad. And also, don't forget that bad tools and bad talent don't rule each other out.

Yes, and that's the case I've seen as well. I would also say rust is also more heavy on symbols, which can make code look kinda hard to parse in places.

But weirdly Opus (N=1) in Claude Code does okay on it. Enough I can reliably have it write software and feel confident it works.

Why would you think so? Rust provide better type system and abstraction mechanisms compared to Go, hence equivalent system should have less lines of code, at least in from my experience.

>> ...there is no debate...

> ...And so many languages have an opinionated formatter these days

The crux of gp's post is for Go, there is no debate as 'go fmt' is the only one that matters. Black is great, but some people prefer Ruff, leading to ...debates about which formatter the team/org should use. Go's batteries-included philosophy makes those discussions moot on so many levels beyond formatting.

what is "Black"? (For hopefully obvious reasons, I couldn't find results with google, lol)

People don't understand exceptional control flow. They think they have to catch them at every point, instead of using them as intended (having a central boundary of error handling where you have enough context whether to retry or abort the operation). So they think Go errors are better.

With exceptions you can

1. Set exception breakpoints.

2. Have real stack traces.

3. No need to write 3 lines of boiler plate every 1 line of code which interacts with outside world.

Ironically this is the case in Go's niche - devopshit, cloud webshit - where the boilerplate error handling makes even less sense since because

1. You are making a network call or OS interactions every 2 lines which can err

2. The consequences of an unhandled exception are actually quite less severe. At worst your request will 500 or the application will restart - which is a consideration you can't escape in these environments.

3. I have seen indiscriminate error handling written by substandard developers which simply concatenates the full wrapped error string to API, leaking full details. At least with exceptions, you can designate different types of exception for 404s vs ayth errors vs bad requests vs Internal errors, and have a central handler which filters out. In go theoretically you can do this, but I have never seen someone utilize errors.As over stringy error handling.

I like Go - it has nice stdlib, nice compiler and runtime, and actually dared to innovate away from the fat-ass LLVM monoculture and made green threads popular. But error handling and uninitialised values sticks out like a sore thumb. It's impossible to read code which does many API/network/OS interactions.

Java already had M:N threads in the early days, aka green threads, because the JVM and Java specifications did not assert what kind of threading was to be provided.

Thus most JVM implementations had a mix of red (1:1:) and green (M:N) threads, eventually only red threads were kept in the surviving implementations.

With Project Loom now both models are officially supported and part of the specification.

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.

  listFiltered := []Item{}
  for _, item := range list {
    if item.selected {
      listFiltered = append(listFiltered, item)
    }
  }

When I worked at OpenConnect (Netflix's CDN) there was a lot of Python too, and I started porting a lot of the tooling to Go. By the time I left (2019), Go was really starting to take off outside of OpenConnect too -- but yes, there's historically a huge amount of Java there.

Likely because Netflix relied on Silverlight for video playback early on. I'd be surprised if they still had C# in their front-end stack (and I say that as a general C# fan, though I use it on the back-end).

Their UI originally was Silverlight which at that time had the best "adaptive streaming" story.

>> why do you think Go is better compared to other languages?

> I didn't say that. :)

I call this the Go paradox.

I simultaneously believe we should reach for it 80% of the time to solve common collaborative problems. And being a poorer language is actually an asset in these cases.

However, in doing so, we get rusty lose our fluency in more expressive, perhaps even better languages.

> Like I said - reports from users.

How does that work? Are they generating the same project in different languages and comparing the results? What does it mean for the code to be "better"?

Ah, I see. I misunderstood.Is the report from an internal source, so it can't be shared? If not, I'd appreciate it if you could send me a link so I can look into it too.