[aflag]

To the second point: I think the issue is that you don't want to handle the errors in a function, but just propagate it, you still need to write error handling code, whereas in languages with exceptions you can just not do anything and let the exception propagate. Hence, the extra verbosity. Not checking for error is not an option in go.

[tapirl]

What is the way you recommend?

[aflag]

The only way to do it in go is to always handle errors, even if you just want to pass them through. It’s one of the downsides of the language. My recommended way is to use a language with exceptions. They have downsides too, of course. It’s always a trade off, but I personally think the upsides of exceptions outweigh the downsides. At least the better implementations of them do.

[tapirl]

Go supports exceptions: panics.

[aflag]

That's not a particularly nice implementation of exceptions and all libraries treat panics as invariant checks, things that should never happen. So, if you want to treat expected errors (eg. file not found) using panic you simple won't be able to go very far, unless you create some functions to convert all errors into panics. But, even then, panic is not great. They are not typed, so you never know what panics could be raised from a function and using a single deferred function that has to handle all errors whereve it is you want to handle them is quite awkward. Obviously, the reason for those design choices is that panics are really not exceptions.

[tapirl]

Yes, panics are not totally the same as exceptions. You can view them as simpler and less powerful exceptions. The Go culture is almost different from Java form every perspective. Go prefers explicit errors over exceptions.

[aflag]

Exactly, that's the criticism. Many find exceptions better than explicitly handling errors, even when you just want to propagate them.