Hacker News Reader

Comment by mkehrt | Hacker News Reader

In rust the type system enforces you check the error. In go, it doesn't. (Because rust error types are enums/sums and go error types are structs/products). This seems like a huge difference.

> In many cases it's arguably worse because now 1 token is potentially representing two very different types I want to deal with.

Yes, that's what an enum/sum type is? That's the whole point.

View on HN

In rust it is not possible to use incorrectly, and in go it is, sure. But whether it is possible or not is only one dimension. Does it matter that it’s possible to misuse errors in Go if it virtually never happens?

I just don’t find the point about what is possible interesting. The other trade offs around readability, ergonomics, and so on seem more impactful.

It depends if you find value in exhaustive pattern matching.

From years of using C's switch statements, I'm not going back.

> Does it matter that it’s possible to misuse errors in Go if it virtually never happens? I just don’t find the point about what is possible interesting.

If you knew for sure that it virtually never happened, maybe not. But you don't. At best you know that a few particular individuals you're familiar with never mess it up (but then again, consider the people who "virtually never" write incorrect C). You can't trust random packages you haven't vetted, and you certainly can't trust code written by your junior software engineers.

> The other trade offs around readability, ergonomics, and so on seem more impactful.

Sum types have significantly better ergonomics. `(Result | null, Error | null)` takes four branches to handle properly, whereas `Either Result Error` takes two. And of course things get much worse once you're more than one layer deep, which in a language as procedural as Go you almost always are.

> virtually never happens

Ah yes, like it "never happened" in the Kubernetes project?

- https://github.com/kubernetes/kubernetes/pull/60962

- https://github.com/kubernetes/kubernetes/pull/80700

- https://github.com/kubernetes/kubernetes/pull/27793

- https://github.com/kubernetes/kubernetes/pull/110879

I can find tons of these, just by searching any larger Go project's Github.

Here's one from docker too: https://github.com/moby/moby/pull/10321

What about from CockroachDB? https://github.com/cockroachdb/cockroach/pull/74743 Even the linter missed this one!

Of course it happens, I’ve done it. But it’s obvious, it’s the least interesting aspect of the debate. And I think it is less impactful than e.g making exceptions easy for devs to ignore.

Maybe it is unpopular opinion, but I think the go-compiler in `go build`, `go install`, `go test` commands should check for all unhanded errors and not compile the program if there are any.

It happens in personal projects, small teams and big ones too. The linter errors are too often ignored by developers. Also, it should help embrace in developer the need to explicitly name some error to be ignored.

Kubernetes is a huge project and not idiomatically written, so it would be shocking if it didn’t exhibit everything that can go wrong with Go.

CockroachDB is a better example.

This is a No True Scotsman fallacy. "No REAL Go code fails to handle errors."

OP demonstrated that failing to handle errors does in fact happen in the wild, while in Rust the compiler enforces that you must handle them. The question is whether this difference between the systems has practical implications, and it seems it does. The existence of community idioms that help avoid the problem doesn't change the fact that the languages themselves are meaningfully different.

The question is whether the problem happens a lot or rarely. I’m saying Kubernetes is a bad example of the problem happening a lot because it’s a ton of code (which yes, is poorly written), and CockroachDB is a good example of it happening a lot because there is less code and it’s at a higher quality.

Reply on news.ycombinator.com