It's not true in Rust. In Rust, objects cannot be concurrently accessed from multiple threads unless they are explicitly marked as thread-safe (with the Sync trait), or wrapped in a a Mutex, which ensures that the safety variants are upheld.

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.

And in the last quadrant, you can use non-raw threads like the Task or Parallel APIs and still have threading issues in C#.

I'm trying to learn Android and some libraries give zero indication of what thread your callbacks will be called on.

Maybe there's a convention somewhere that says "On Android, you can't assume anything about callbacks, so always assume you're on some anonymous worker thread and lock everything or dispatch to a thread you own"

But I have not come across it yet.

Yes that is the convention.

You cannot assume anything about process or thread lifetimes on Android, as the simple act of rotating the screen will restart your application, and it can be killed at any moment and restarted later, due to memory pressure, or because the use has switched applications.

So whatever was the state of your application can be completely different when the callback is supposed to be invoked later on.