The anti-exception mind virus of the 2010s did a lot of damage. Go designers finally caved and added panic & recover, but jeez, the damage was done. The whole ecosystem has exception derangement syndrome.
That said, the key insight of the exception craze is that error returns are a normal part of a functions behaviour and as such should not use extraordinary control flow to take place.
Exceptions (panics) are used for things that should never happen or are indicative of a programmer error, like nil dereferences or out-of-bounds array accesses. That is, things where the programmer is not expected to provide reasonable behaviour on the API level if it happens (but perhaps there is a whole-program fault handler to shut down cleanly).
Opening a file that does not exist? Database record not found? Invalid credentials? These should be anticipated by the programmer and can occur at any time. Not exceptions, normal return values. Go requests that you think about these possibilities instead of pretending they can be ignored.
I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me. That said, the typical performance complaints made against the most common implementations of exceptions are valid.
Then you definitely don't understand the tradeoffs after all, and/or don't know the history of error handling.
Exceptions are an outdated concept that's inferior to explicit error returns for 99% of software.
The tradeoffs are super simple here - exceptions require very little of your input but lead to terrible spaghetti due to hidden control flow. Explicit error returns are seemingly the opposite, but their verbosity issues have mostly gone away thanks to modern language improvements, so they're just better, unless you're writing short scripts and the like.
The situation is very similar to static vs dynamic typing - dynamic typing used to make a lot of sense in the days of extremely verbose Java type declarations, but modern static type systems with inference have made dynamic typing basically obsolete.
> That said, the typical performance complaints made against the most common implementations of exceptions are valid.
This also sounds off and outdated to me. If anything, exceptions typically have better performance, so long as errors aren't common. Indeed, if optimized correctly, exceptions have zero cost if not thrown, which can get you better perf than error returns, which have a low, but constant cost.