I don’t think rust got rid of the null dereference problem. Just traded it for something slightly different. ie, calling unwrap when no value exists causes the program to panic.
In Go some common types are forced to be nillable, and you can't express "this is never nil". In Rust, "never nil" is the default, even for slices and by-reference types, so right of the bat for the majority of types nullability disappears entirely. You can't make a mistake of `unwrap()`ing something that doesn't support unwrapping.
`unwrap()` is the laziest/worst way of handling optionals, but it's still better than Go's behavior. `unwrap()` is local and explicit, so you can find and review every potential failure point (unlike e.g. finding every use of a nil map in Go). And of course Rust has plenty of better, graceful ways of handling optionals, so you can also ban this method entirely with a lint.
It does yes. A fair number of other constructs can panic as well.
> I wonder if any codebases lint those away.
Clippy has a lint for indexing so probably.
For the general case, it's almost impossible unless you're working on very low-level software (embedded, probably kernel-rust eventually) e.g. `std` assumes allocations can't fail, so any allocation will show up as a panic path.
https://github.com/Technolution/rustig can actually uncover panic paths, but because of the above the results are quite noisy, and while it's possible to uncover bugs thanks to rustig it requires pretty ridiculous amounts of filtering.
The `for` loop is based on the Iterator trait. Iterators typically optimize better than indexing, and can't panic.
Yeah it did.
> Just traded it for something slightly different. ie, calling unwrap when no value exists causes the program to panic.
That betrays an absence of familiarity with option types.
First of all, an optional pointer is strictly more work, so you're not going to use an optional pointer when you don't have to, meaning most of your pointers will be non-optional and statically checked so.
This means when you do encounter an optional pointer, there's a reason for it. At which point you get to put your thinking hat on and wonder whether that's applicable to your situation:
* sometimes you don't care because it's a one-off or something and you just unwrap() and go on your merry way
* sometimes the pointer is set by construction but the typesystem is not expressive enough to understand that, usually by the second or third time you get around that code and don't remember why the unwrap's there you'll switch to `expect` or `unreachable!` in order to document your assumptions or logic (which is also helpful when those break and the code panics
* and most of the time there's a good reason why the pointer is nullable and it applies to your situation and you probably want to handle it properly and you do.
Plus `unwrap()` and friends are easily greppable so you can review them with little trouble, or flag them during review, or whatever.
In language with nullable pointers (and only that), you've got none of this.