The article talks way too high level and is written like a marketing people even the title sounds technical, for example:
"Rust enforces thread-safety of all code and data, even in 3rd party libraries, even if authors of that code didn't pay attention to thread safety. Everything either upholds specific thread-safety guarantees, or won't be allowed to be used across threads."
But this is true. I mean specifically about Send and Sync traits that have to be implemented on types for the compiler to allow them in multi-threaded constructs, like `thread::spawn` or Rayon's parallel iterators.
If you write a library, and use e.g. thread-unsafe `Rc` or not-sure-if-safe raw pointers anywhere in your structs, the compiler will stop me from using your library in my threaded code.
This is based on a real experience. I've written a single threaded batch-processing code, and then tried to make it parallel. The compiler told me that I used a GitHub client, which used an HTTP client, which used an I/O runtime, which in this configuration stored shared state in an object without a Mutex. Rust pointed out exactly the field in 3rd party code that would cause a data race. At compile time.
That doesn't sound too high level to me. Maybe a small quibble is the definition of "thread safety," but a reasonable one would be, "no undefined behavior in the presence of simultaneous access." In other words, no data races. And that's absolutely true and consistent with Rust's definition of safety. Another small quibble might be that, "even if the authors of that code didn't pay attention to thread safety and didn't use 'unsafe'" would be more precise.
There is simply no way you can enforce "thread safety on ALL data", unless you pay unreasonable amount of synchronization costs, which in that case, is a trivial thing to accomplish.
This is as same as some one tell you that you will never loose any money by investing a certain asset.
Rust is a constructive proof that your assertion is simply false. It comes at the cost of some complexity—every Rust type carries thread-safety information with it—but the benefit is that writing correct parallel Rust code becomes very easy.
What you cannot easily do in Rust is dynamically switch thread safety on or off.
"Rust enforces thread-safety of all code and data, even in 3rd party libraries, even if authors of that code didn't pay attention to thread safety. Everything either upholds specific thread-safety guarantees, or won't be allowed to be used across threads."