[cube2222]

Not really, in all the years I've been writing Go, only one library used panics for error handling.

Usually if something panics you don't want to handle it. (Other than at the http handler level, where you can just throw an InternalServerError and log the panic)

First and foremost, you can usually assume libraries won't panic, though it would be nice to have a tool (grep) to check for explicit panics.

[groestl]

If something "errors", you usually don't want to handle it either. Other that at the http handler level.

[cube2222]

Actually, you often do. That's the point really. You should decide if it's an operation you might want to retry, you might also want to just flat out error and do nothing more, maybe you want to provide degraded functionality, like provide some default answer.

I think errors as values cause you to always think about this, which makes you handle errors in a more sensible way, instead of just bubbling up. Sure, 90% of situations you will bubble up, but in my opinion it's still worth it.

[groestl]

You basically said so in your last paragraph, and I agree it's a tradeoff, I just want to reiterate that in my experience, bubbling up and retrying/degrading/failing at the top level (system boundary, client side) makes for a robust (distributed) system you can reason about. Having hundreds of easter eggs in the project where somebody tried to do something smart when encountering an error seems more like a nightmare scenario to me. Old Java enterprise applications are filled with this, and they are rightfully frowned upon. Checked exceptions are the culprit.