5 ms·

> virtually never happens Ah yes, like it "never happened" in the Kubernetes project? - https://github.com/kubernetes/kubernetes/pull/60962 https://github.com

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

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.