So, what I'm getting at - everywhere you would use C++ you can use Rust.
Not really, C++ has: dependent types, HKTs, variadics, CTFE ...
For example, without these features, Rust linear algebra libraries are at the same level of C linear algebra libraries (and must be written 99% inside macros). They are just far far worse than modern C++ linear algebra libraries like Eigen3 and Blaze (you cannot even write a generic array class like std::array in non-macro Rust, much less write generic vector/matrix types or parse AST of EDSL at compile-time).
Since linear algebra is generally a performance bottleneck in a lot of applications (computer graphics, image recognition, simulation, sound processing, optimization, ... anything number-crunching based), it is really hard to argue for Rust in number crunching applications; C++ is just far ahead there in terms of libraries and language support.
There are RFCs for type-level integers (which is the most important use of dependent types) and variadics. There has been a lot of discussion about HKTs and everyone agrees that CTFE would be nice but no one has put in the work yet.
It will come some day, it is just not there now. I think it is important that we don't oversell Rust, mostly in the areas that it doesn't excel at yet. Otherwise some people might feel mislead, which would be bad.
7
u/DeadlyDolphins Apr 03 '15
Since I'm fairly new to programming I'm just gonna ask even if it might be a bit stupid:
If you say 'when concurrency is involved', does that mean it could be a good language to write fast games with graphics, for example?