> [...] if you wrap the semantics in a library, and use the library, you get the same reliability from it.
Wrong. Rust offers more tools for checking that your library is used correctly than C++ does. First and foremost, the borrow checker – there is nothing comparable in C++, and it's a lot harder/impossible to statically prevent code from modifying shared data after a mutex has been unlocked, for example.
> (This is an unpopular observation in certain places.)
It is unpopular because it is factually incorrect.
(Knee-jerk reactions do not improve the reputation of your language or of your language community.)
A library interface boundary can enforce behavioral restrictions on its clients equally as strong as a compiler's. Clients not handed pointers cannot abuse them. It does demand correctness of the library implementation similar to demands on the compiler. But such correctness in a library formalism is certainly as possible to establish and maintain as in a compiler.
Use of wild pointers in other parts of the client could overwrite library data, but that is a different risk than the data races that are the topic here.
Wrong. Rust offers more tools for checking that your library is used correctly than C++ does. First and foremost, the borrow checker – there is nothing comparable in C++, and it's a lot harder/impossible to statically prevent code from modifying shared data after a mutex has been unlocked, for example.
> (This is an unpopular observation in certain places.)
It is unpopular because it is factually incorrect.