4 ms·

The borrow checker is a static analysis tool that is 100% sound, unlike the tools for C/C++

flukus 6y ago
The borrow checker is 150% sound, it complains about errors but also complains about a lot of things that could have been perfectly fine in reality. There are plenty of times when multiple mutable references would be perfectly safe for instance. Valgrind might not catch 100% of errors, but at least what it catches are actual errors I care about.
- smallnamespace 6y ago
  That's an interesting (and correct!) objection — in stats terms, it's the choice between having false positives (your type checker rejects some valid programs) vs. false negatives (Valgrind didn't catch these cases). If you're writing safety-critical software though, being forced to restructure your code to satisfy the type checker (which, in this case, is kind of a simple proof assistant) seems like a sane tradeoff.
- adrianN 6y ago
  Valgrind only catches the errors that your test suite triggers.
- xfer 6y ago
  Valgrind is not a static analyzer, You should use some C static analyzers to compare the false positive rate. You can use various dynamic instrumentation based tool to detect other classes of bugs that are not caught by the borrow checker in Rust.
- Ar-Curunir 6y ago
  You're talking about completeness: the borrow checker rejects some valid programs (any type system will do that). Soundness is talking about catching incorrect programs; the borrowck doesn't allow a single invalid program through.
StillBored 6y ago
And it only catches a trivial minority of actual security problems, which can occur in a lot more ways than use after free/etc. IMHO, Rust simply isn't good enough at catching all types of bugs to justify rewrites at this point, and its likely when you look at some of the work being done at the processor manufacturing companies that they don't believe it either. Consider: https://en.wikichip.org/wiki/arm/mte https://en.wikichip.org/wiki/arm/mte, https://en.wikipedia.org/wiki/Intel_MPX https://en.wikipedia.org/wiki/Intel_MPX, and https://lwn.net/Articles/718888/ https://lwn.net/Articles/718888/ There are quite a number of these in the pipeline, which make some of what rust does redundant.
- saagarjha 6y ago
  Uh, not at all. Rust’s compiler probably catches like half of all bugs that currently lead to security issues in memory-unsafe languages. And the things you mentioned are similar band-aids, not fixes.

The borrow checker is 150% sound, it complains about errors but also complains about a lot of things that could have been perfectly fine in reality. There are plenty of times when multiple mutable references would be perfectly safe for instance. Valgrind might not catch 100% of errors, but at least what it catches are actual errors I care about.

smallnamespace 6y ago
That's an interesting (and correct!) objection — in stats terms, it's the choice between having false positives (your type checker rejects some valid programs) vs. false negatives (Valgrind didn't catch these cases). If you're writing safety-critical software though, being forced to restructure your code to satisfy the type checker (which, in this case, is kind of a simple proof assistant) seems like a sane tradeoff.
adrianN 6y ago
Valgrind only catches the errors that your test suite triggers.
xfer 6y ago
Valgrind is not a static analyzer, You should use some C static analyzers to compare the false positive rate. You can use various dynamic instrumentation based tool to detect other classes of bugs that are not caught by the borrow checker in Rust.
Ar-Curunir 6y ago
You're talking about completeness: the borrow checker rejects some valid programs (any type system will do that). Soundness is talking about catching incorrect programs; the borrowck doesn't allow a single invalid program through.

StillBored 6y ago

And it only catches a trivial minority of actual security problems, which can occur in a lot more ways than use after free/etc. IMHO, Rust simply isn't good enough at catching all types of bugs to justify rewrites at this point, and its likely when you look at some of the work being done at the processor manufacturing companies that they don't believe it either. Consider: https://en.wikichip.org/wiki/arm/mte https://en.wikichip.org/wiki/arm/mte, https://en.wikipedia.org/wiki/Intel_MPX https://en.wikipedia.org/wiki/Intel_MPX, and https://lwn.net/Articles/718888/ https://lwn.net/Articles/718888/ There are quite a number of these in the pipeline, which make some of what rust does redundant.

saagarjha 6y ago
Uh, not at all. Rust’s compiler probably catches like half of all bugs that currently lead to security issues in memory-unsafe languages. And the things you mentioned are similar band-aids, not fixes.