4 ms·

The borrow checker eliminates data races and hard memory errors, such as access violations. Panics are well within the bounds of safety. From the docs: Unlike

The borrow checker eliminates data races and hard memory errors, such as access violations. Panics are well within the bounds of safety. From the docs: Unlike C, Undefined Behavior is pretty limited in scope in Rust. All the core language cares about is preventing the following things: * Dereferencing null or dangling pointers * Reading uninitialized memory * Breaking the pointer aliasing rules * Producing invalid primitive values: dangling/null references, a bool that isn't 0 or 1, an undefined enum discriminant, a char outside the ranges [0x0, 0xD7FF] and [0xE000, 0x10FFFF], A non-utf8 str * Unwinding into another language * Causing a data race <snip> Rust is otherwise quite permissive with respect to other dubious operations. Rust considers it "safe" to: * Deadlock * Have a race condition * Leak memory * Fail to call destructors * Overflow integers * Abort the program * Delete the production database https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

dom0 10y ago
Deadlocks and race conditions are two IMHO typical examples of what many developers consider shortcomings of the platform / language, while they are actually application logic bugs that are hard to catch at a language level for all but the most trivial cases. So this is a very nice listing right there, starting with two things that some people may find surprising, then moving towards things that no one should find surprising :)
- geofft 10y ago
  Note that it's possible to use Rust's typesystem to build things that are deadlock-free and race-condition-free; see, for instance, https://aturon.github.io/blog/2015/08/27/epoch/ https://aturon.github.io/blog/2015/08/27/epoch/ for an API for building lock-free data structures. The assistance you get from the Rust language is much better than the assistance you'd get from C or C++. (Rust has a lot of features other than memory safety!) It's just that Rust doesn't consider it unsafe to build a design that permits deadlocks and race conditions.
- BuuQu9hu 10y ago
  There are languages like E and Monte where deadlocks aren't possible unless there is an actual loop in the data flow dependencies and race conditions are impossible, but they aren't commonly known.
  - dom0 10y ago
    > unless there is an actual loop in the data flow Hence trivial. Making something provably deadlock-free where the message flow is a DAG is a trivial case. > race conditions are impossible I very much doubt that since race conditions are not only a technical issue (i.e. "is updating that counter atomic?"), but largely a specification issue. Recall that issues like lost updates (or all those file system races) are race conditions, as well as the many issues with non-atomic REST APIs.

dom0 10y ago

Deadlocks and race conditions are two IMHO typical examples of what many developers consider shortcomings of the platform / language, while they are actually application logic bugs that are hard to catch at a language level for all but the most trivial cases. So this is a very nice listing right there, starting with two things that some people may find surprising, then moving towards things that no one should find surprising :)

geofft 10y ago
Note that it's possible to use Rust's typesystem to build things that are deadlock-free and race-condition-free; see, for instance, https://aturon.github.io/blog/2015/08/27/epoch/ https://aturon.github.io/blog/2015/08/27/epoch/ for an API for building lock-free data structures. The assistance you get from the Rust language is much better than the assistance you'd get from C or C++. (Rust has a lot of features other than memory safety!) It's just that Rust doesn't consider it unsafe to build a design that permits deadlocks and race conditions.
BuuQu9hu 10y ago
There are languages like E and Monte where deadlocks aren't possible unless there is an actual loop in the data flow dependencies and race conditions are impossible, but they aren't commonly known.
- dom0 10y ago
  > unless there is an actual loop in the data flow Hence trivial. Making something provably deadlock-free where the message flow is a DAG is a trivial case. > race conditions are impossible I very much doubt that since race conditions are not only a technical issue (i.e. "is updating that counter atomic?"), but largely a specification issue. Recall that issues like lost updates (or all those file system races) are race conditions, as well as the many issues with non-atomic REST APIs.