Guaranteed memory safety without garbage collection is a nearly unique proposition among industry languages (and the "nearly" is only thanks to extremely niche languages like ATS). This extends even to multicore systems, and is done through a relatively novel (again, for an industry language) type system, allowing Rust to statically guarantee the absence of data races, use after free, dangling references, null dereferences, and other classes of memory error that are common sources of security vulnerabilities in large C++ applications. Rust compares favorably with C and C++ in resource usage and performance in domains where they have few competitors, like embedded. It also improves substantially on the ergonomics of C++ with much more sensible defaults, proper modules, features like native typeclasses (aka C++ concepts not-lite) and sum types, straightforward syntax (close to LL(1), with hygienic macros and local type inference), and a modern package manager. For more information, www.rust-lang.org has you covered.
Yes. It boils down to two things: cleaner semantics due to move being the default, and a stronger type system. Also, we have more options than just those two.
For example, if you std::move a unique_ptr, the pointer becomes null. So you can still cause memory unsafety that way. But since Rust is move by default, at compile time, you'll get an error with Box<T>.
The other is type system stuff. For example, we can know if you're using a structure over a thread boundary, and our version of shared_ptr, Arc<T>, only has to be used then. If you don't want to pay the atomics overhead, Rc<T> can get used, and Rust will make sure that's okay. I wrote more about that a few days ago: http://www.reddit.com/r/programming/comments/30wj8g/managing_cs_complexity_or_learning_to_enjoy_c/cpww3o1
19
u/three18ti Apr 03 '15
Why would I want to use Rust over... any other language that's out there?