Practically the verbosity isn't a big deal. It's not hard to type and you can always copy and paste. More importantly, as a pattern it's pretty easy to read. T

Practically the verbosity isn't a big deal. It's not hard to type and you can always copy and paste. More importantly, as a pattern it's pretty easy to read. The code and meaning is clear and you can follow it. Maybe some syntax would be nice to shorten it, but it really doesn't bother me all that much. You get used too it. Bigger problems are language warts which lead to bugs, and a nasty one has to do with interfaces and nil: https://golang.org/doc/faq#nil_error https://golang.org/doc/faq#nil_error . Seems like it would be much better for them to fix that. (and there are attempts to do so in issues on GitHub) FWIW the errors package is a nice way to further annotate errors: https://github.com/pkg/errors https://github.com/pkg/errors And at least with distributed systems error handling is a more complicated affair. The boilerplate ends up not being so boilerplate when some errors should be ignored, some retried and some should result in a panic. I guess there's an appeal to a well defined exception type hierarchy for something like that, though how that fits with a language like go isn't at all clear... in practice knowing the type hierarchy is also hard ... what's the difference between Error and Exception ends up being a common bug in python for example. We treat these problems like they have obvious solutions, but they don't. Fixing them the "easy" way ends up turning Go into a very different language, and it will be a sad day when that happens. Folks who enjoy working with Go will just fork a minimalist version, and the folks who complained won't use it anyway and will stick with rust or whatever. At least that's my sense of it.