Yes, but that is definitely not achieved by checking for errors every second line.

I think checking for errors every line makes my go programs easier and faster to produce at a higher level of quality.

Some languages achieve error checking by type transforms and pattern matching, which are much more effective and efficient than error checks after every function call

Sure, but is writing the error check by hand what creates the benefit? Or is it having the error check?

It is thinking about what to do for each operation that can fail. This thought is what separates the applications that recover when the network glitch is over vs. the applications that need to be restarted.

The value here is the few seconds of human attention given to the error at hand. The thought is irreplaceable. Like others mention, 90% of the, end up if err != nil { return nil, err } but thinking about it will, in my experience, make the system more robust to failure. At the very Least for your process you will decide on a goal of carrying on in the face of failures and repairing when things work again vs. just bailing out and letting something else worry about it.

What if the return nil, err was the sane choice at the time of writing but there are changes downstream that mandate a new error handling mode there? Also, there are plenty of “writing this code at 3AM” where I would question the validity of such thoughts.

I used to prototype in PHP and nowadays I prototype in JS.

I also ship JS in production and it's a painful experience compared to rust or haskell.