Hacker News Reader

Comment by phibz | Hacker News Reader

I feel like this misses the biggest advantage of Result in rust. You must do something with it. Even if you want to ignore the error with unwrap() what you're really saying is "panic on errors".

But in go you can just _err and never touch it.

Also while not part of std::Result you can use things like anyhow or error_context to add context before returning if theres an error.

View on HN

> But in go you can just _err and never touch it.

You can do that in Rust too. This code doesn't warn:

    let _ = File::create("foo.txt");

(though if you want code that uses the File struct returned from the happy path of File::create, you can't do that without writing code that deals somehow with the possibility of the create() call failing, whether it is a panic, propagating the error upwards, or actual error handling code. Still, if you're just calling create() for side effects, ignoring the error is this easy.)

Any sane Go team will be running errcheck, so I think this is a moot point.

I think it’s still worth pointing out that one language includes it as a feature and the other requires additional tooling.

Which can also be said about Rust and anyhow/thiserror. You won't see any decent project that don't use them, the language requires additional tooling for errors as well.

Not exactly:

- https://github.com/kubernetes/kubernetes/pull/132799/files

- https://github.com/kubernetes/kubernetes/pull/80700/files

- https://github.com/kubernetes/kubernetes/pull/27793/files

- https://github.com/kubernetes/kubernetes/pull/110879/files

- https://github.com/moby/moby/pull/10321/files

- https://github.com/cockroachdb/cockroach/pull/74743/files

Do we have linters that catch these?

Reply on news.ycombinator.com