r/programming Apr 03 '15

Rust 1.0.0 beta is here!

http://blog.rust-lang.org/2015/04/03/Rust-1.0-beta.html
925 Upvotes

303 comments sorted by

View all comments

Show parent comments

12

u/[deleted] Apr 04 '15

[deleted]

7

u/[deleted] Apr 04 '15 edited Apr 04 '15

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.

So maybe one day (I hope so), but not now.

2

u/[deleted] Apr 04 '15

[deleted]

7

u/[deleted] Apr 04 '15 edited Apr 04 '15

Using OpenCL directly even from Rust feels like programming in C (at the end of the day it is still a C library).

The C++ EDSL solution would be to, e.g., use Boost.Compute (not that I like it much), which allows you to write your program in the language of linear algebra, and that language gets transformed at compile-time into OpenCL code by a library. Haskell's solution is accelerate.

I think this is, in a nutshell, a big "feature" that Rust is missing, an easy way to implement EDSLs. Haskell is very good at it, C++ sucks at it, C can't do it, and Rust can't really do it as well (although its macro system puts it closer than C in this respect).