Yes for multi-threaded code, although not quite for multi-processes code, which is what one should be writing when the goal is security.

Then you are back into the same synchronization issues as in every other language.

Yeah, it solves only the 99.9% case.

So Firefox will return to be a single executable after Rust migration is fully done? After all that is not needed it seems.

Rust does not compile if you don't use the techniques you described?

> Rust does not compile if you don't use the techniques you described?

Yes, exactly.

https://kkimdev.github.io/posts/2019/04/22/Rust-Compile-Time...

Of course, you can bypass this by using 'unsafe' code, where you are explicitly telling the compiler that you have manually verified Rust's safety guarantees.

This is why a significant portion of Rust's community gets agitated with (possibly unnecessary) use of 'unsafe' in popular libraries.

Then I stand corrected and applaud the creators of Rust for haven taken these measures for writing thread safe code, because it is supereasy to get threading wrong, even for the most experienced developer.

Interestingly enough, this was the raison d'être of the Rust project at the beginning, while zero-cost abstraction and memory-safety without GC (and the borrow-checker) weren't part if the initial goal. When Rust was first released as a research project it had green threads and a GC (interestingly close to Go actually), but it was already designed with data-race freedom in mind.

Both Java and C# are designed for memory-safety but not thread-safety; Rust is.

Considering many of the software problems we face have some connection to thread-safety, Rust is the way to go.

I would consider that the way to go is multi-processes instead, and secure every critical module on their own OS sandbox.

Threading seemed a good idea that went wrong.