I wrote a lot of Go from like 2010 to 2013 or so.
A few days ago I read an article from someone clearly experienced in general software good practices, who masterfully laid out every complaint I had when I left Go.
I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.
I have the opposite experience here, I find golangs error handling to be too abstract at times. I need to know what error and in what situation a function can return an error. An abstract error doesn’t help with that and an exception even less so. I need to dive into a functions source far too often to try to understand in what situation an error might occur and what that error would be if it is even typed.
If you fine error handling annoying and only handle it high up in the call chain your codebase is either brittle or returns generic unusable errors and you have to rely aggressively on runtime tracing which is very expensive.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...