It's rarely the case that you need to know exactly where the error originated. You just need to check if the error wraps a network error or EOF error for example.

If you do need to know specifically what the error was then the API provides public error types.

No, "the API" doesn't. I have encountered many libs that just do fmt.Errof, and just like that application code does too.

So go doesn't do error handling well at all. Give your stdlib a stringly error maker, that's what will creep in everywhere. It doesn't matter if there is a section for creating (somewhat) typed errors - half of go code doesn't bother and together with the poor type system you can't even be sure which type of error you got.

I wouldn’t bother replying further. Clearly they’ve got a very strong opinion on this. Multiple people have pointed out the issues with their line of thought but they continue to persist. They’ll understand if they reflect on it, maybe.

Yea. Actually, they should get hands on with error handling other than go or your run of the mill exceptions.