With generics, it would be possible to write a library implementing 2-track, functional error handling, which would allow for a form of automatic error propagation. The if err != nil statements would be kept to a minimum. It's precisely the lack of generics in the first place that makes error handling in Go so obnoxious.
one annoying thing about go error handling aside from the copious `if err != nil` statements is that if someone somewhere doesn't handle an error there's no way to find! yes I know about errorcheck or whatever that library is called but I think it's silly you'd leave something like that up to a library.
Comments
well generic's wasn't the things why I stopped using golang. But I think many do because of it.
I stopped because of the error handling. try in rust/scala is just too awesome to go back to basically a tuple that will always need to be handled.
With generics, it would be possible to write a library implementing 2-track, functional error handling, which would allow for a form of automatic error propagation. The if err != nil statements would be kept to a minimum. It's precisely the lack of generics in the first place that makes error handling in Go so obnoxious.
one annoying thing about go error handling aside from the copious `if err != nil` statements is that if someone somewhere doesn't handle an error there's no way to find! yes I know about errorcheck or whatever that library is called but I think it's silly you'd leave something like that up to a library.