5 ms·

>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

>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. >Finally, the developer leading the effort had experience and a strong preference for Rust. There are plenty of technologies that would have met our requirements, but deferring to a personal preference made a lot of sense. Having engineers excited about what they are working on is incredibly valuable. 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. There's no shame in simply using the language you're most proficient in. Practically speaking, language choice is only a problem for large teams or for projects with language-specific requirements.

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 ago
  The 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?
pcwalton 10y ago
> What? I've almost exclusively heard the opposite Practically speaking, Go makes it hard to accidentally ignore errors if the function you're calling normally returns a value and easy to accidentally ignore them if it doesn't. For example, Go will force you to handle the error when unpacking the result of os.Open(), but not the result of os.Chmod(). There is a popular errcheck tool that does simple static analysis to catch this. By contrast, rustc warns if you drop any error anywhere, and this warning ships on by default with the compiler.
- EugeneOZ 10y ago
  If function in Rust returns any type of result except Result, you can just call it without handling errors. Compiler will raise warning only if Result wasn't handled. And even in this case you can just add "let _ =" before call to suppress warning. I'm pretty sure you know it.
  - deleted 10y ago
    [deleted]
  - masklinn 10y ago
    > If function in Rust returns any type of result except Result The conversation was specifically about ignoring errors. In Rust, errors are conventionally reported using Result hence it warning on unuse — AFAIK the only type opted into that by default, its variants being specifically called Ok and Err, and its currently exclusive support in `try!` and `?` > And even in this case you can just add "let _ =" before call to suppress warning. You can even disable the warning entirely, can you imagine that? Incidentally, you can use that exact same feature to ignore errors from value-returning functions (where you need the actual result) in Go as well, so that's not exactly a slam dunk; and it is an explicit ignoring of the error rather than an implicit one which can (and often is) a mistake rather than a conscious decision by the developer. That is, there is a large difference between _ := os.Chmod(…) where the developer is explicitly stating "I don't care about an error" and os.Chmod(…) where the developer might not have noticed that an error is possible. In Rust, the latter is will warn by default because fs::set_permissions returns an io::Result<()>.
EugeneOZ 10y ago
> Having engineers excited about what they are working on is incredibly valuable. And for me it was one of weak points of this article. "We use Rust because our engineers want to play with a new toy" is a weak argument and soon will be used by opponents of Rust as their proof.
- allengeorge 10y ago
  But it's the truth - so why not admit it?
  - EugeneOZ 10y ago
    What is truth? That they make decisions just to play with new toy? It's their problem, really, not a thing to be proud of, not an argument to be mentioned in article.
    - allengeorge 10y ago
      In my opinion you're seriously underestimating how much "I like this language" and "I'm comfortable with this language" is involved when decided how to code up new projects - especially at companies without an approved-language policy. I also didn't get the impression they were "proud of it" - they were simply honest in acknowledging it as a factor.
      - EugeneOZ 10y ago
        Really, I born yesterday and has never started new projects yet. Sometimes people should get rid of "I'm comfortable with this language" just to try out new things. And this argument is good for side-projects.
mkawia 10y ago
Go promotes the pattern of dealing with errors ,which to be fair I think is an improvement on exception based handling. But rust compiler forces the user of a function to handle error .it's impossible to 'val ,_ = getValOrErr()' in Rust. You just can't ignore an error.

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 ago
The 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?

pcwalton 10y ago

> What? I've almost exclusively heard the opposite Practically speaking, Go makes it hard to accidentally ignore errors if the function you're calling normally returns a value and easy to accidentally ignore them if it doesn't. For example, Go will force you to handle the error when unpacking the result of os.Open(), but not the result of os.Chmod(). There is a popular errcheck tool that does simple static analysis to catch this. By contrast, rustc warns if you drop any error anywhere, and this warning ships on by default with the compiler.

EugeneOZ 10y ago
If function in Rust returns any type of result except Result, you can just call it without handling errors. Compiler will raise warning only if Result wasn't handled. And even in this case you can just add "let _ =" before call to suppress warning. I'm pretty sure you know it.
- deleted 10y ago
  [deleted]
- masklinn 10y ago
  > If function in Rust returns any type of result except Result The conversation was specifically about ignoring errors. In Rust, errors are conventionally reported using Result hence it warning on unuse — AFAIK the only type opted into that by default, its variants being specifically called Ok and Err, and its currently exclusive support in `try!` and `?` > And even in this case you can just add "let _ =" before call to suppress warning. You can even disable the warning entirely, can you imagine that? Incidentally, you can use that exact same feature to ignore errors from value-returning functions (where you need the actual result) in Go as well, so that's not exactly a slam dunk; and it is an explicit ignoring of the error rather than an implicit one which can (and often is) a mistake rather than a conscious decision by the developer. That is, there is a large difference between _ := os.Chmod(…) where the developer is explicitly stating "I don't care about an error" and os.Chmod(…) where the developer might not have noticed that an error is possible. In Rust, the latter is will warn by default because fs::set_permissions returns an io::Result<()>.

EugeneOZ 10y ago

> Having engineers excited about what they are working on is incredibly valuable. And for me it was one of weak points of this article. "We use Rust because our engineers want to play with a new toy" is a weak argument and soon will be used by opponents of Rust as their proof.

allengeorge 10y ago
But it's the truth - so why not admit it?
- EugeneOZ 10y ago
  What is truth? That they make decisions just to play with new toy? It's their problem, really, not a thing to be proud of, not an argument to be mentioned in article.
  - allengeorge 10y ago
    In my opinion you're seriously underestimating how much "I like this language" and "I'm comfortable with this language" is involved when decided how to code up new projects - especially at companies without an approved-language policy. I also didn't get the impression they were "proud of it" - they were simply honest in acknowledging it as a factor.
    - EugeneOZ 10y ago
      Really, I born yesterday and has never started new projects yet. Sometimes people should get rid of "I'm comfortable with this language" just to try out new things. And this argument is good for side-projects.

mkawia 10y ago

Go promotes the pattern of dealing with errors ,which to be fair I think is an improvement on exception based handling. But rust compiler forces the user of a function to handle error .it's impossible to 'val ,_ = getValOrErr()' in Rust. You just can't ignore an error.