Error handling is the thing I hate the most about go. And none of the serious proposals I've seen would remove your ability to continue using `if err != nil`
I have yet to see a proposal that retains what I love about the status quo: conscientious error handling.
The language’s status quo forces everyone to think about errors more deeply than in other languages and acknowledges that the error case is as critical and worthy of the programmer’s attention.
Doesn't really change that, but significantly reduces the amount of noise from error handling boilerplate. And (most importantly to me) reduces the amount of vertical space taken up by error handling code, which makes it easier to follow the happy flow.
Reduces the vertical space by vastly increasing the horizontal space and inserting line noise into the syntax. I don't even understand what that code would do.
I think the issue is that "easier to follow the happy flow" basically also implies "easier to ignore the unhappy flow", and this is what a lot of people who have come to like Go's approach react against. We like that the error case takes up space—it's as important to deal with correctly as the happy path, so why shouldn't it take up space?
Is it 3x as important? Because currently, for a single line of happy path code you often have 3 lines of error handling code.
And while handling errors is important, it is also often trivial, just optionally wrapping the error and returning it up to the caller. I agree it is good for that to be explicit, but I don't think it needs to take up more space than the actual function call.
In my experience, the important error handling code is either at the lowest layer, where the error initiall occurs, or at the top level, where the error is reported to the user. Mid level code usually just propagates errors upwards.
