Hacker News new | ask | show | jobs
by Manishearth 3890 days ago
> you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it.

Explicit vs implicit. In Rust/Haskell you are forced to do _something_ about the nullability. If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails.

On the other hand, in Java, you can get an NPE where you didn't expect it because nulls move around easily and there's nothing in the type system to prevent that. That's the difference.

> I'm surprised that so much new rust code does this

Also, in my experience, unwrap() in Rust is mostly confined to irrecoverable errors in applications, and example blog posts (where the focus is on getting something done and not worrying about good error handling).

> defeats a core purpose of rust

What purpose? Whatever unwrap provides is still possible via a match+panic. Which is _more_ explicit, but they're both still explicit.

1 comments

> If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails.

If you use Optional.get() without Optional.isPresent(), how is that any different? It's not as nice as pattern decomposition, but it's still fundamentally the same, and on top of that, transform functions are provided so that most of the time you can do null-safe operations.

The difference is that Optional itself can be null, and in Java everything can be null.
It can be, and it's annoying, but that's still a step forward. It's trivial for a good static checker to treat all Optional references as if they were annotated with your favorite @Nonnull annotation.
But in Java you'd never use a library that calls System.exit when it reaches an unexpected null
See my other comment: https://news.ycombinator.com/item?id=10452408

In Rust you'd rarely write a library that panics on unexpected nulls.

(Also, panic != abort, yada yada)