A lot of people complain about Go's repetitive err checking pattern, but it's very familiar if you've ever written systems code in C. If you aren't checking return values and errno from every system call (and able to log them), you're code is going to be impossible to debug.
Conversation
Replying to
The issue with the approach in Go is not that the errors need to be handled from each call. The issue is the language is inexpressive, overly verbose and forces massive amounts of duplicated code for this. It doesn't have a way to return a result or an error or to work with that.
2
4
It forces always returning both a result and an error, and it does that via a hard-wired multiple return value feature rather than a type like a tuple which would lend itself to less code repetition. Avoiding exceptions doesn't imply having this kind of verbosity / repetition.
2
2
It's only convention that either the result or error is returned via the multiple return value, and you have to check for that every time by copy-pasting or open coding it over and over. It lacks the ability to factor it out and reuse higher-level error handling code / patterns.