3 ms·

I don't buy the argument that Go makes error handling explicit. It is too easy to forget to check for an error in Go. Did you know that `fmt.Printf` can also fa

I don't buy the argument that Go makes error handling explicit. It is too easy to forget to check for an error in Go. Did you know that `fmt.Printf` can also fail? Do you explicitly check for `err` when using it? Probably not, because what Go calls explicit error handling is merely a convention, not something supported by the language, e.g. [[nodiscard]] from C++ or #[must_use] from Rust. And who thought reassigning `err` multiple times was a good idea? That again strikes a lack of functionality in Go. What saddens me is that these kinds of matters will never be fixed in Go. Go has a stubborn anti-feature mentality and while it does help preventing feature creep, it overall harms the language in the long run. For a language created and maintained by Google this is a huge missed opportunity.

makapuf 5y ago
There has been a go2 proposal for better error handling, so there is no issue trying to improve things or adding needed features. But things go slowly and must be discussed and vetted before being accepted because the language has few features and they will stick so the filter is quite high. See generics, it took a long time but its coming.
- tsimionescu 5y ago
  The proposal for better error handling was rejected, as far as I'm aware. Generics needlessly repeated the mistakes of Java and C# in coming out years too late.
  - makapuf 5y ago
    I kind of agree, it's better to have generics from the start (we'll see if there are difficulties added), and the error handling was rejected. But the fact that those proposals have been proposed, discussed, studied and for one of them accepted show that the language can evolve.
thiht 5y ago
> Did you know that `fmt.Printf` can also fail? Do you explicitly check for `err` when using it? Probably not, because what Go calls explicit error handling is merely a convention I was curious about this and it’s true, I didn’t know these functions could err, TIL. The Godoc states: > It is conventional not to worry about any error returned by Printf
xh-dude 5y ago
I’m not sure the mentality is exactly “oops, oh well, leave it broken forever” [0]; it is intentionally ponderous. As a stop-gap, linters [1] can get excellent insight from ASTs. The stability of Go is something I value a lot, so I don’t mind stop-gaps like this too much on balance. [0] https://github.com/golang/go/issues/20148 https://github.com/golang/go/issues/20148 [1] https://github.com/golangci/golangci-lint https://github.com/golangci/golangci-lint

makapuf 5y ago

There has been a go2 proposal for better error handling, so there is no issue trying to improve things or adding needed features. But things go slowly and must be discussed and vetted before being accepted because the language has few features and they will stick so the filter is quite high. See generics, it took a long time but its coming.

tsimionescu 5y ago
The proposal for better error handling was rejected, as far as I'm aware. Generics needlessly repeated the mistakes of Java and C# in coming out years too late.
- makapuf 5y ago
  I kind of agree, it's better to have generics from the start (we'll see if there are difficulties added), and the error handling was rejected. But the fact that those proposals have been proposed, discussed, studied and for one of them accepted show that the language can evolve.

thiht 5y ago

> Did you know that `fmt.Printf` can also fail? Do you explicitly check for `err` when using it? Probably not, because what Go calls explicit error handling is merely a convention I was curious about this and it’s true, I didn’t know these functions could err, TIL. The Godoc states: > It is conventional not to worry about any error returned by Printf

xh-dude 5y ago

I’m not sure the mentality is exactly “oops, oh well, leave it broken forever” [0]; it is intentionally ponderous. As a stop-gap, linters [1] can get excellent insight from ASTs. The stability of Go is something I value a lot, so I don’t mind stop-gaps like this too much on balance. [0] https://github.com/golang/go/issues/20148 https://github.com/golang/go/issues/20148 [1] https://github.com/golangci/golangci-lint https://github.com/golangci/golangci-lint