given a function fn that can fail, it will return a result and an error e.g.

    result, error = fn(...)

calling this function should yield to the caller two possibilities, somehow: a success value _or_ a failure error

the important thing is that in both cases, the control flow is visible in the source code as written

    result, error = fn(...)
    if there was an error, ...
    if it was successful, ...

when an expression fails, you want to see the consequence in-line

the success path and the failure path are equally important

with robust and potentially high volume code, the most important feature is good behavior in failure domains. disk full, do you abort or continue once the cron job frees some space; cant alloc memory, do you abort or return a static 503 page? bad contents in some file, do you exit or log the error and carry on? does a bad pyc file generate a good error message or crash python. this robustness is the famed second 90% of the project. normal go looks a cerain way when it is handling these errors.