Yes it does, but IMO only superficially. Rust has a completely different type system model and also Rust is not aimed at high performance applications, while this seems to be. Many(most?) new languages fade away because nobody is interested in implementing compilers/libraries writing documentation/teaching material/etc etc. I'll be impressed if they can ship something next year.
> Rust has a completely different type system model
What are the differences? It sounds pretty similar to Rust—"rvalue references, move semantics, destruction, references / borrowing" are straight out of Rust's playbook.
Granted, if it's based on C#, it sounds like it'll be more object-oriented than Rust is, which is a difference. Rust has some object-oriented features, but they're much more minimalist than what C# offers; idiomatic Rust prefers composition over inheritance, etc.
> Rust is not aimed at high performance applications
This week has been bizarro week for weird things people are saying about Rust. :)
Rust is about zero-cost abstractions, period. It's right there on the Wikipedia page: "Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable (and sometimes faster) than C++ code that manually takes precautions comparable to what the Rust language mandates." http://en.wikipedia.org/wiki/Rust_%28programming_language%29
Mozilla is explicitly investing in Rust in order to build the fastest browser engine around and has been from day one…
As you mentioned, if they based it entirely on C# , it will be a unified type system. We'll only get more information when they release a standards specification.
>Rust is about zero-cost abstractions, period.
Um.. no? For one, the heap is reference counted - and if you use std::gc its... mark/sweep(not sure?). This obviously means that the programmer has little control over memory allocation other than what can be afforded by not compromising memory safety. Secondly from my initial use of Rust I dont think you cannot protect a chunk of data with a lock and share it (w/o copying) across threads/processes as you would with a systems language like C++.
--
Rust is not aimed at high performance applications - I dont see anything wrong with that statement.
> For one, the heap is reference counted - and if you use std::gc its... mark/sweep(not sure?).
No, the heap primarily uses unique ownership, which is equivalent to malloc/free. Reference counting is an option (and mark/sweep in the future) but idiomatic Rust only uses reference counting where it is necessary.
> Secondly from my initial use of Rust I dont think you cannot protect a chunk of data with a lock and share it (w/o copying) across threads/processes as you would with a systems language like C++.
So are you confirming or denying that Rust is about zero-cost abstraction? Because it sounds like you're saying if you don't use any abstractions, its zero cost :)
Anyway, I don't have anything against Rust. I cheer for their success.
You'll have to take the word of the people aiming rust, really.
Refcounted pointers are just one option in rust. ~Obviously~ you can use anything from C-style pointers and your own custom allocator that calls brk() directly to atomically refcounted and/or mutexed threadsafe smartpointers to manage your memory.
Nuts to that, I expect that Rust could regularly exceed C++ in performance. Ownership as a core concept means that you get pointer aliasing information for free, which has always been Fortran's biggest advantage over C. And correct me if I'm wrong, but C++'s unique_ptr isn't guaranteed to have zero overhead at runtime, as Rust's unique pointers are.
unique_ptr should have similar performance to Rust as designed right now, but the upcoming changes to eliminate zeroing out of moved values should give Rust's unique pointers an edge over those of C++ in 1.0.
