Hmmm...

  and (2) a way to cut down on if err != nil { ... }
  boilerplate that pervades all Go code.
Am I weird in liking the explicit error handling? :/

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.

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

[1] https://github.com/golangci/golangci-lint