> Tying locking to ownership seems to have worked in Rust I'm not sure whether I would call it "locking to ownership". But the thread safety guarantees that Ru

> Tying locking to ownership seems to have worked in Rust I'm not sure whether I would call it "locking to ownership". But the thread safety guarantees that Rust provides through the type system (`Send/Sync`) are probably the main reason why I would consider using it also for applications which would otherwise favor something along C#, Java or Kotlin to be used. Those languages are for me super productive, and by using them you don't have to worry about memory safety either. However they provide no safety net against threading issues. And unfortunately threading issues are far too commmon - basically everytime I see an entry to mid-level engineer using threads there will exist at least one issue which will cause some pain later on (because it's invisible, will break in weird ways, and will be hard to find). With Rust the compiler will tell people that something is lacking synchronization. There will obviously still be issues - e.g. if someone tries to be clever with atomics and misses the correct dependencies and ordering. Or just because some architecture is not perfect and things deadlock. But there are a lot less of the "oh, I didn't knew this required synchronization at all" issues.