Hacker News new | ask | show | jobs
by Jweb_Guru 4310 days ago
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.

1 comments

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.

* Pending some in-the-works reforms, and not including implementation-specific features like labels as values (https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64).

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.
Why wouldn't you expect Rust program performance to be distinct from interpreted program performance?
We haven't parallelized and optimized our implementations of those benchmarks yet. I wouldn't read too much into that.