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.
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.