> Checking and handling all possible error conditions is a GOOD thing.

I agree. But Go seems to have taken the most verbose way to achieve that. Pattern matching should have been the way to go if they did not want to use exceptions. Then again, Go does not have functional constructs, and you wouldn't be able to get far with it. Though it still prevents you from ignoring errors, unlike what exists in the language.

Only if you have a meaningfully different thing to do for each type of error, see my response to the sibling comment.

Yep. Sometimes crashing isn't an option. There are places in network & systems code that have seemingly complicated but darn important many permutations of state that already exist. Sometimes the differentiation between error conditions requires a combination of conditions (i.e., talking to an existing legacy system.)

As for single-threaded map, there are at least two necessary behaviors that handle errors very differently:

1. batch all errors/exceptions/etc and return them as an array 2. return on first error