There's a difference between handling and propagating errors, most Go-code I've come across/written is pretty much using exceptions, but with 10x the noise and none of the convenience. Which might be fine, different languages have different goals; maybe simplicity is more important. But pretending it's somehow superior isn't fooling anyone.
An exception interrupts the entire flow of the program.
In go if something is truly exceptional then you can panic, but most of the time an error is non-fatal outside of a particular request (request not just related to a web request).
I agree, many people do errors incorrectly, but `try` does not make them suddenly correct either.
It's quite healthy for the community to have this discussion because this is introducing not just a new built-in function/expressiony thing, but also a means of flow control.
Unconditionally returning on errors all the way has exactly the same effect. Arguing that it's wrong isn't very constructive given that everyone seems to be doing it.
panic() is just another symptom of the same disease.
Exceptions are a very useful tool, and so is pattern matching and support for multiple returns. There is no one true way to handle errors.
