> It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety". I explained in

> It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety". I explained in the other comment why this isn't really an issue. Note that most "basic datastructures" exist in the stdlib already, so you don't have to use unsafe code to do this in practice. 100% guaranteed memory safety by your definition is an unattainable goal. In safe rust code you do indeed have guaranteed memory safety, and you're able to extend this by writing unsafe rust code with which you supply your own guarantees of safety. Safe Rust and unsafe Rust are best viewed as separate languages with smooth FFI between them, see http://doc.rust-lang.org/stable/nomicon/meet-safe-and-unsafe.html http://doc.rust-lang.org/stable/nomicon/meet-safe-and-unsafe.... > splitting a vector and updating each element by a separate thread - IIRC that used to be a problem, maybe it has been fixed already? This is scoped threads and is possible. Crossbeam and scoped_threadpool both have solutions for this. > This also means implementing concurrent algorithms using the (limited) API That's what you should be doing for thread safety. Like you mentioned, that's what you do in C too. Rust does indeed have CAS atomics. > I have multiple threads, and I only care about the last result (i.e. they can all write to the same memory location) This sounds like a use case for monotonic (relaxed) atomic ordering? Not sure. Note that "the last result" itself doesn't mean anything, due to the way the cache works. There's no global clock (hooray for distributed systems!). The fact that Rust makes you think about this is a good thing. You can stick a Lamport clock in there, but that involves using more atomics and won't be as fast as relaxed ordering.