3 ms·

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

by jtaft 5y ago

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.

arnsholt 5y ago
Sure, but the crucial difference is that all the unwraps in your code are then hooks that a linter can find, or simply grepping for unwrap in your codebase and do a manual audit of those pieces of code. In my experiments with Rust that's been a very nice way of working: first build a very barebones version getting the basic happy path right, and then getting all the tedious stuff right afterwards by eliminating all the unwraps. By making it explicit, you now have a concrete thing you can audit specifically, rather than every pointer access in your entire program and every pointer you pass off to a library.
pornel 5y ago
It did. It really makes a huge difference. 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.
- moldavi 5y ago
  Doesnt Rust have implicit panics on indexing out of bounds? I wonder if any codebases lint those away.
  - masklinn 5y ago
    > Doesnt Rust have implicit panics on indexing out of bounds? 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 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.
  - pornel 5y ago
    It has both optional and panicking ways to index, but it steers users away from using indexing in the first place. The `for` loop is based on the Iterator trait. Iterators typically optimize better than indexing, and can't panic.
  - baby 5y ago
    It’s really hard if you don’t start linting them early on because they creep on your codebase. There are a set of functions that will panic on you surprisingly. Indexing is one example, copy_from_slice is another one, honestly it’s too bad that there are such functions in the library but at least clippy can find them.
masklinn 5y ago
> I don’t think rust got rid of the null dereference problem. 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.

by jtaft 5y ago

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.

arnsholt 5y ago

Sure, but the crucial difference is that all the unwraps in your code are then hooks that a linter can find, or simply grepping for unwrap in your codebase and do a manual audit of those pieces of code. In my experiments with Rust that's been a very nice way of working: first build a very barebones version getting the basic happy path right, and then getting all the tedious stuff right afterwards by eliminating all the unwraps. By making it explicit, you now have a concrete thing you can audit specifically, rather than every pointer access in your entire program and every pointer you pass off to a library.

pornel 5y ago

It did. It really makes a huge difference. 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.

moldavi 5y ago
Doesnt Rust have implicit panics on indexing out of bounds? I wonder if any codebases lint those away.
- masklinn 5y ago
  > Doesnt Rust have implicit panics on indexing out of bounds? 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 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.
- pornel 5y ago
  It has both optional and panicking ways to index, but it steers users away from using indexing in the first place. The `for` loop is based on the Iterator trait. Iterators typically optimize better than indexing, and can't panic.
- baby 5y ago
  It’s really hard if you don’t start linting them early on because they creep on your codebase. There are a set of functions that will panic on you surprisingly. Indexing is one example, copy_from_slice is another one, honestly it’s too bad that there are such functions in the library but at least clippy can find them.

masklinn 5y ago

> I don’t think rust got rid of the null dereference problem. 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.