I would certainly argue against the claim that explicit error handling is far overkill.

Where I agree: It forces you to think about all of the possibilities your code might generate. (This is more of a C question than it is with other languages)

However, when abstracting blocks of code away, you don't always need to handle the error immediently or you may want to handle it down the stack.

You're giving up a lot of readability in order for the language to be particular.

> It forces you to think about all of the possibilities your code might generate.

Except it doesn't actually. You can totally just ignore it and pretend errors don't exist. Lack of sum types/Result, and pointers as poor mans optional, really hinder's Go's error handling story.

> It forces you to think about all of the possibilities your code might generate

I’ve seen way too much Go code which never even tested the err value to believe that until something like errcheck is built in to the compiler.

I do agree that this is a plus for the explicit model but that’s been a better argument for Rust in my experience since there’s better culture and tooling around actually checking errors. I’m sure there are plenty of teams doing a good job here, but it always felt like the one lesson from C they didn’t learn well enough, probably because a language created by experts working at a place with a strong culture of review doesn’t really account for the other 99% of developers.

Rust handles this much better.

Error handling is still explicit, but it gives you the tools needed to make it less tedious.