Hacker News Reader

Comment by nemo1618 | Hacker News Reader

>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.

View on HN

> 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.

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.

> 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<()>.

There's a plenty of ways how function can report about error - with None, 0, -1, false, or even "error", can you imagine it?

I like Rust's way to handle errors with Result, but I hate your tone, so discussion is over.

Think as an author of a function that does something that can fail .

the signature ;"fn risky_shtuff() -> Result<Response , Err)"

Rust guarantees to you as the author who ever uses this function HAS to handle both cases (even if it's an unwrap).

However Rust doesn't stop you form making functions that instead return Option ,bools or even strings ,but you'd be actively working against very strong convention.

if function doesn't return anything (void) as pcwalton saying, it doesn't matter. So or we are talking about returning value or not.

> 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.

> > > 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.

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?

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.

> 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.

But it's the truth - so why not admit it?

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.

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.

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.

Reply on news.ycombinator.com