It’s probably more correct if I say that data types themselves are thread safe or not.

https://doc.rust-lang.org/nomicon/send-and-sync.html

So therefore a function can’t do things that invalidate that type level contract.

Send and Sync are the keywords to search for.

Isn’t anything with Arc thread safe?

No. Just because something’s behind an Arc<T> doesn’t mean two threads can hold it at once. Arc just ensures that it is freed (dropped) when no threads are using it any more. T itself has to be Send+Sync for Arc to be.

To a first approximation, Arc<Mutex<T>> is what you want when you want a blob of mutable stuff to just work between threads, but you still have to worry about terrible performance if you hold the mutexes too long, etc. (Not to mention mutexes are just slower in general than having types which are natively Send+Sync.)

> Not to mention mutexes are just slower in general than having types which are natively Send+Sync

Without knowing the implementation, how would you know this statement is true?

I could just stick the Arc<Mutex<T>> within my abstraction and say it is send+sync and it would have the exact same performance, and that might be the most efficient solution possible on the given hardware.

Telling when a thing is thread safe is hardly the same as telling when something isn’t.

Race conditions within rust are technically impossible :)

Safe Rust prevents data races, but not race conditions in general.

Though arguably, the fact that in order to mutate data from multiple threads, the compiler,forces you to use some synchronization primitive, results in you having to think about how you are going to synchronize access, which should lower the chance of race condition bugs overall.

The analogy I find helpful for this is, you let the cat out your front door and close it. You walk to the back door and close that too.

A race condition (which safe Rust can have) is a normal phenemenon in our world. If we put the cat out the front door, then walk to the kitchen and close that door by the time we reached the back door maybe the cat had run around the outside of the building and come inside again, closing the doors in the wrong order introduced the opportunity for a race - be very careful.

A data race (which safe Rust does not have) is a weird thing caused by the mismatch between how you think the computer works and how it actually works. What happens if Alice tries the put the cat out the front door at the same time Bob tries to put it out the back door? Well, in the real world that cannot happen, either Alice has the cat or Bob does. But for many languages† this sort of nonsense can happen and when it does that's a disaster

† In safe Rust it can't happen, in Java, OCaml and Go it can happen, but it may not be a disaster (the details are different for each, it is a bug though).

Interesting analogy.

That’s why I said inside rust. If you bring in external factors then of course it can/will happen.

Hmmm, no.

https://stackoverflow.com/questions/31912781/why-doesnt-the-...