What you're saying makes sense, but I still don't think it's right. Imagine the classic broken bank-balance update algorithm from concurrency 101. It's safe Rus

What you're saying makes sense, but I still don't think it's right. Imagine the classic broken bank-balance update algorithm from concurrency 101. It's safe Rust to individually wrap every operation with a lock instead of wrapping the entire transaction [0]. Both Rust and Python prevent data races as narrowly defined by the Rust docs [1], but semantic bugs like that can easily sneak into your code if you aren't careful. Not to mention, Rust chose not to do anything about the memory fence problem. You're probably mostly fine on x86, but acquire/release semantics and all that nonsense still apply when writing concurrent algorithms in Rust (you'll often get lucky if you have something like a queue/channel and use message passing, since implementations of those often have a few fences internally, probably the fences you need for semantic correctness in your own algorithms). You're a lot more likely to see that sort of problem crop up in embedded work. [0] That's obviously a bad idea, but more intricate concurrent algorithms are tricky to write in Rust for the same reason they're tricky to write in other languages. You get a bit of help from the compiler which you wouldn't really in Python if you design things to leverage the type system and prove the invariants you need to uphold, but the compiler doesn't know about any of those invariants aside from data races. [1] https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html