the fact that the most popular Go IDE actually has logic to automatically fold and hide the constant error handling boilerplate and that people seem to have no problem with that makes me feel like I'm taking crazy pills.

C++ and Java exceptions have non-local flow and it's hard to determine what function can throw what, so if you do want to add error handling cases you would have to inspect every function to know if it throws or not. Yeah, there's noexcept and checked exceptions but one was a late addition that legacy codebases don't use and the other everyone just does throw new RuntimeException(err) anyway.

In general I agree with you, but Rust is already having this problem by people making liberal use of unwrap.

    Result<usefulresult, Error>

    foo().context("useful info about foo")?

Plus, most things that work like "open" close when their scope closes, so you don't need all that "defer" stuff.

I would have liked a good error hierarchy like Python 2 had, where there was a clear distinction between program-is-broken errors and errors due to external causes. But Rust didn't get that at the beginning, and now it's too late.

anyhow::Error really does a good job of smoothing out the finicky bits of Rust error handling, it feels and reads a lot better than Go code to me.

(And I’m not sure about the local variables idea, because that could become really slow and could effectively duplicate the stack in size, or even more in the case of “suppressed” exceptions).

Those are just objective facts. I, personally, don’t like this feature either. May be with very different language design it could be better, but as it is, it’s ergonomics is awful IMO. And I have problems to imagine how to rework it to make it work.

Java developers are really divided on the topic of checked exceptions, there is no consensus.

Go allows you to do that with panic/recover, although it's not quite idiomatic