That's true, but it's also true than when people evaluate a problem, they tend to want to imagine the maximally scaled, most robust, "final" version thereof. A

That's true, but it's also true than when people evaluate a problem, they tend to want to imagine the maximally scaled, most robust, "final" version thereof. And so they tend strongly to solve the wrong problem in practice, often in inappropriate languages. Now, for the record, I happen to love Go and agree with the author about its error handling paradigms. That said, I like the python script at the top of the article a lot more still, because the problem being presented is a routine kind of thing that needs to be solved on a routine, ad-hoc basis a zillion times every day. And we don't want people writing the 80 line Go code to do that, we want them doing it in python. Basically exception-style "I don't know what went wrong, just that it failed, let the user sort it out[1]" code is the correct solution to probably 90% of workaday problems we face. You fall through to precise error handling (and/or frameworks like in Rust that force the handling syntactically) only when you need to write code that survives in the absence of a traditional "operator". But most code doesn't run that way! [1] In this case, the problems are likely bad filenames, bad URL, server down, etc... If your developers are running this script themselves, they'll figure that out on their own.