That tells you absolutely no information a stacktrace doesn't. It's actually worse than just passing the err! Like, foo knew you failed performing foo, that's w

That tells you absolutely no information a stacktrace doesn't. It's actually worse than just passing the err! Like, foo knew you failed performing foo, that's why you have the error, because foo failed. You don't need to reiterate that foo failed while performing foo, because the machine and user already know foo failed. See how annoying that kind of repetition is. I've seen people that do that and it sounds nice until you end up with Failed foo on x: failed bar on x: failed doing baz on x: failed to do quux". You've created a worse stacktrace! I now have to search for a string and hope I can guess where the %s (or v or q) was instead of just grabbing the line number. Or I do none of that, pass errors around directly, and just use the stacktrace. The issue with your claim is that we only care about errors in two places, where we create them (like where the file was unable to be read) and where we handle them (when they are either swallowed bc the behavior was expected or passed to the user). You don't care about them in all the intervening code, and exceptions handle that better. > And why not have the most basic conditional take the role of that syntax? Because it bloats your code and you end up with in practice more lines spent on verbose, cookie cutter error returning than actual logic! Like, you don't need additional human readable context except in very particular cases. Go proves this in practice as almost everyone just returns the unmodified error most of the time, and it works great. Except for the annoying syntax.