> However in my opinion Rust made the wrong choice. They chose the "you don't have to think of it" case, which I think is wrong for a systems programming langua

> However in my opinion Rust made the wrong choice. They chose the "you don't have to think of it" case, which I think is wrong for a systems programming language. As someone who has programmed in C++ for over 10 years and in Rust for over 5 years I have to hard disagree on this one. (: Rust made precisely the right choice because by default in gets rid of all of the mental overhead of "is this actually safe to call/move this across multiple threads?" while giving you the tools to bypass it if you actually want to do it the C++ way, and then you have to think about it. (But only if you explicitly choose to!) > If I want to make a bunch of changes to an object atomically (or a bunch of bookkeeping to multiple objects) I still need a manual lock (mutex), and then the internal bookkeeping is deadweight. Then just... don't add any internal bookkeeping to your type? (: Or, depending on the kind of bookkeeping you use, you might not have to pay for it anyway. For example, Rust has atomic integer types which require you to access them in a safe way, however, they also have this method on them: pub fn get_mut(&mut self) -> &mut u32 ...which means that if you wrap that in an outer Mutex you will have an &mut to it, which means that even though the type is thread-safe by default you do not have to pay anything extra to use it if you decide to put it in an outer Mutex and do the synchronization yourself. The overhead of its "built-in" synchronization is then completely gone! Isn't this the best of both worlds? (: > I also might use an object on a single thread for a while and then hand it off to another thread which then has ownership (so still requires no locking). ...so you'll have a &mut reference on that single thread, in which case no locking is required. Am I missing something? > Or even hand it off to a group of threads which then need to use it in a safe way, presumably by calling different functions. Fair enough. But in that case you can just use an UnsafeCell and do it the C++ way if you really want to.