3 ms·
> What? I've almost exclusively heard the opposite: Go makes error handling too in-your-face. People don't like writing "if err != nil" constantly. Do you actu
by jwilm 10y ago
> What? I've almost exclusively heard the opposite: Go makes error handling too in-your-face. People don't like writing "if err != nil" constantly.
Do you actually have to look at the value you err, or can you just pretend like it's not there? (genuinely asking, I thought it was the latter).
> I wish it were more acceptable to admit this instead of having to half-assedly argue that your favorite language just so happens to be a perfect fit for the problem.
This is one of the reasons we felt it important to mention. Rather than demand purely technical motivations, we choose to acknowledge the human aspects of software engineering as well.
- rcaught 10y ago> > > Languages like Go make it too easy to ignore errors. > > What? I've almost exclusively heard the opposite: Go makes error handling too in-your-face. People don't like writing "if err != nil" constantly. > Do you actually have to look at the value you err, or can you just pretend like it's not there? (genuinely asking, I thought it was the latter). While Go may not have all the capabilities Rust has at forcing error inspection, it really isn't in the class of languages that "make it too easy to ignore errors". I agree that a lot of it is convention, but multi-value returns, usage of named variables and good practices in the base libs (flowing upwards) can't place it in the realm of easily ignoring errors.
- deleted 10y ago[deleted]
- libria 10y agoThe compiler prohibits declaring variables (and imports) without using them. You can get around this with result, _ := someFunc() or in a (anti) pattern I use sometimes _ = []interface{}{ err1, err2, var1, etc } with underscore being a special variable name indicating to the compiler you understand you're ignoring it. Nice writeup btw. Did generics/GC play any part in the decision making process?