I was working at Google when Go was being developed, and was initially interested, but R. Pike is... not someone who's swayed by rational arguments.

It's Go's error handling that I find truly terrible, and I argued with Pike about it at the time.

There are two issues.

The first is that I write a widely-used function which I believe cannot error. Later, it turns out that there is a critical error that can cause an error that (as is often the case) can only be handled at the top level.

Now I have to change, not just every single call site for that function, but the call sites above that, and so on, all the way to the top.

More, if I miss one, or if my colleague was using that call in code that was under review, there's no way to find out that you forget to check the error code.

The second is that having to check an error code for each operation means a huge amount of repetitive boilerplate where you're constantly calling functions, checking an error code, and then returning an error code.

Pike didn't really make any case for his radical stance. He seems to think it's better for an error to pass unnoticed than an exception to propagate to the top and stop the program.

NO. If my program misses an error code, it means we're in a bad state. If I don't even know why my state is bad, the program should crash immediately, and not for example overwrite good data with bad.