Does anyone has the same thought with me? The complexity of Rust is close to C++ and around equal to Java.And as many people's tought, if you don't advocate to use the GC, are there any reason to use a language which is no-simple and not faster than C++????
I think you're asking why you'd want to use Rust over C++?
First, to establish what we're not losing by using Rust:
* It can be as fast as C++ (in essentially all cases--all but compile-time metaprogramming related situations, after some in-the-works reforms are implemented).
* It can be as deterministic as C++ (usable in hard realtime systems).
* It has great FFI-level C compatibility.
Advantages over C++:
* It is substantially safer than C++. Outside of unsafe blocks, it is memory-safe and many other forms of undefined behavior are absent, including data races (unlike not only C++, but Java, Go, and most other mainstream languages that support multithreading).
* In a number of cases, it could potentially be faster than C++ by utilizing Rust's much stricter aliasing semantics.
* It should be able to compile much faster than C++, and it can infer much more thanks to its type system.
The above are things that I don't think can be shoehorned into C++ backwards-compatibly. I'm not including features like ADTs because I see no reason C++ couldn't have them.
There are plenty of reasons not to choose Rust over C++, including language immaturity, implementation immaturity, library immaturity, ecosystem immaturity, and lack of familiarity. But language feature for language feature, it offers substantial benefits.
Currently Rust, Scala, Go and Haskell are all about equally fast, according to http://benchmarksgame.alioth.debian.org/ . C, C++ and Ada are still the fastest. It's intersting to me that all the new languages are about equally fast.
I'm not talking about current benchmarks, but theoretical speed. As a language (not an implementation, set of libraries, etc.) Rust will allow for programs to run as fast as C or C++ in all situations.* Ada, Scala, Go and Haskell may be able to do better in isolated situations, but in general this is not true for them. A lot of the time, this doesn't matter, but it's very important when you want to be considered a serious competitor in the domain of systems languages.
1) Even though the benchmarks game only shows a handful of tiny programs, Rust programs have only been contributed for half the tasks. (There are Dart programs for more of the tasks.)
Incidentally, some of those Rust programs are written for multicore:
binary-trees Rust ≈ CPU Load 96% 86% 92% 92%
fannkuch-redux Rust ≈ CPU Load 100% 100% 100% 100%
regex-dna Rust ≈ CPU Load 59% 79% 80% 59%
2) Your "about equally fast" covers what others regard as enormous differences :)
Well, none of those are clear wins over any of the others. They're somewhere in between the hyperoptimized compiled languages and the interpreted ones, and very distinct from them.
> And as many people's tought, if you don't advocate to use the GC, are there any reason to use a language which is no-simple and not faster than C++????
Rust was designed to be memory-safe. That means, unless you explicitly mark a section of code as "unsafe", it isn't possible to have segfaults, have buffer overflows, use memory after freeing it, etc. A very significant amount of software bugs - famously, Heartbleed, but also a huge proportion of other security bugs in everything from servers to web browsers - can't happen under Rust code. The point is to have a much more secure programming language, as in resistant to attacks, while still being as fast and as usable as other C-style languages.
The reason Mozilla are developing this is for Servo, a new browser engine which should be far safer than existing ones - although it's also useful for pretty much any other code, as it wipes out entire classes of bugs with not much effort. If you write in a C-like language today, you could pick up most of Rust (lifetimes included) in a couple of days of playing with it.
