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
The verbosity of Go is by design. It makes for more readable, dependable, and debug-able code. In languages like python , programmers put way too much logic in one line and don't have an idiomatic standard for how errors should be decorated/handled. Makes for lower quality code.
1
I find that arguments against Go's design are ultimately people complaining that it doesn't have the design of the language they're more familiar with. I'm really glad the Go team refuses to be Frankenstein.
1
It's ridiculous to claim that the verbosity and repetition makes the code more readable, dependable or debuggable. I'm not comparing to a dynamically typed language like Python, or languages with exceptions and class-based inheritance. I'm certainly very familiar with Go, etc.
1
1
If your experience consists of languages with bad type systems like Java and dynamically typed language, then I can see that Go would seem to be a decent programming language. However, if that's your experience, then I don't think you're actually capable of having the discussion.
Go is nearly just Java without class-based inheritance and exceptions. I prefer languages with decent type systems and support for code reuse, without a heavy reliance on exceptions, dynamic casting, boilerplate and verbosity. Not a fan of the Java / Go school of thought, sorry.