3 ms·

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

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.

go_explore_5 3y ago
It depends if you find value in exhaustive pattern matching. From years of using C's switch statements, I'm not going back.
consilient 3y ago
> 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.
nulld3v 3y ago
> 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/60962 - https://github.com/kubernetes/kubernetes/pull/80700 https://github.com/kubernetes/kubernetes/pull/80700 - https://github.com/kubernetes/kubernetes/pull/27793 https://github.com/kubernetes/kubernetes/pull/27793 - https://github.com/kubernetes/kubernetes/pull/110879 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 https://github.com/moby/moby/pull/10321 What about from CockroachDB? https://github.com/cockroachdb/cockroach/pull/74743 https://github.com/cockroachdb/cockroach/pull/74743 Even the linter missed this one!
- philosopher1234 3y ago
  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.
  - pqb 3y ago
    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.
- earthboundkid 3y ago
  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.
  - lolinder 3y ago
    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.
    - earthboundkid 3y ago
      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.

go_explore_5 3y ago

It depends if you find value in exhaustive pattern matching. From years of using C's switch statements, I'm not going back.

consilient 3y ago

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

nulld3v 3y ago

> 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/60962 - https://github.com/kubernetes/kubernetes/pull/80700 https://github.com/kubernetes/kubernetes/pull/80700 - https://github.com/kubernetes/kubernetes/pull/27793 https://github.com/kubernetes/kubernetes/pull/27793 - https://github.com/kubernetes/kubernetes/pull/110879 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 https://github.com/moby/moby/pull/10321 What about from CockroachDB? https://github.com/cockroachdb/cockroach/pull/74743 https://github.com/cockroachdb/cockroach/pull/74743 Even the linter missed this one!

philosopher1234 3y ago
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.
- pqb 3y ago
  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.
earthboundkid 3y ago
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.
- lolinder 3y ago
  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.
  - earthboundkid 3y ago
    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.