[vaylian]

There are different reasons why a program can crash. Nullpointer exceptions are one of them. Out-of-memory situations are another. Rust protects you against the former, but not the latter. But at least in my experience I only encountered crashes when I disabled safety checks by calling .unwrap().

[jononor]

unwrap() does not disable safety checks, it just means you ignore/disregard error handling. It will panic and abort the program, but not cause a safety issue.

/pedantic

[amalcon]

This is actually an interesting distinction. The way that Rust defines "safety" is a little jargon-ish. It's probably more useful than the (highly impractical) colloquial meaning, but still different. In a rust context, "safety" means that the program is protected from a very specific set of things.

One might expect that set to contain things like crashing (panic! and friends) and leaking memory (forget). It does not, and is not intended to.

[atoav]

I think safety is about risk managment. Having a seatbelt on in a car is safer than not having one. This is despite the fact that most regular people really don’t desire crashing their car. By putting on a seatbelt you pay a small prize to weaken the impact of a existing risk (crashing your car).

Rust’s idea of safety is similar: it tries to reduce the impact of common risks that happen during programming. It won’t save you from logical errors — just like a seatbelt won’t save you when you decide to maneuver your vehicle into a flaming pit of lava. The only thing that would save you in that situation is not maneuvering into flaming lava pits.

That beeing said rust has a very straightforward implementation for Unit Tests and Integration tests which could help you dealing with remaining risks.

Of course you can always live on the edge, ignore seatbelts and do things like calling unwrap() on results that might not retun Ok(value) at all times. But that will bite you sooner than later.

What Rust is really good at IMO, is to make risks clear at any givrn moment in time. The routes your program can take are very well represented, especially because of the ownership model. Once you understood it you can make very strong assumptions about which part of the software is manipulating which data. These strong assumptions also help mitigating risk. It is harder in Rust to do things just wrong than in most other languages and it is still fast

[dullgiulio]

But the parent's point remains: a Java NPE and a panic because of unwrap are really equivalent. Not really unsafe in the C sense, but equally bad as unhandled crashes.

[staticassertion]

There's one really major distinction - you can `grep` for `unwrap`. You could grep for null, but that won't tell you if an NPE elsewhere is possible, and it won't hit every single case (like 3rd party libs returning null).

Making bugs grep'able is huge.

[jononor]

Greppable also means it is trivially lintable. And the standard linter Clippy defaults since two years to disallow unwrap()

[Yoric]

Assuming that nobody catches the NPE by accident or error (according to my experience in Java, it's a pretty big assumption), yes, they pretty much are.

The big difference is that, in Java, you typically get your NPE because you didn't know/didn't check that your pointer could be `null` – in other words, the default behavior of the language is to NPE. In Rust, the default behavior of the language is to inform the developer that they need to check. They may decide to explicitly assert that the pointer is not null, causing a crash if it is, but that's a conscious choice.

For instance, in my Rust code, pretty much every occurrence of `unwrap()` or `expect()` contains a comment explaining which invariant guarantees that the call will succeed. I don't think I have ever seen any comments associated to a member access in Java.

[Yoric]

Not exactly "disabled safety check": `unwrap()` is an assertion check (that may sometimes be optimized away by the compiler). You're still checking safety, but you're doing it in a much more terminal manner.