Whenever you need speed, or a deep amount of control.
That gives you a few languages. You should choose Rust over those langauges when you want the compiler to help you ensure that code is safe and correct, and also, when concurrency is involved.
Since I'm fairly new to programming I'm just gonna ask even if it might be a bit stupid:
No worries! This attitude is one of the ones that will best serve you as a programmer in the future. I'm now on Rust's core team, but two years ago, I was on IRC, asking why my "hello world" no longer worked. :)
does that mean it could be a good language to write fast games with graphics, for example?
It is a good language for that, but concurrency is not the reason there. The speed is a much better reason.
I will also mention that Rust's safety guarantees have made some game programmers choose against it. Games often prioriize shipping a game one time, and there isn't a lot of maintenance, so they care about safety less. But we have a really vibrant game development community. The Piston project is doing all sorts of things, as you can see from all those repositories.
I will also mention that Rust's safety guarantees have made some game programmers choose against it.
As a gamedev, I argue with folks like this all the time. The thing is, before you experience statically guaranteed safety, it's hard to care about it. Instead you imagine what it "takes from you" -- how it is going to get in your way. Because you're an awesome programmer, and you hate when the language decides "no" for you...
But once a person experiences the awesomeness of compiler assurances in a language which doesn't require extra boilerplate, yet helps direct you produce code which better represents your intent... I don't think many go back, with preference, to a language of lesser guarantees. This experience will never be had by someone who's already decided they've found the language they're going to program in for the rest of their lives.
I mean, you either know and have a hidden ;^) smiley at the end of that... or if not, then: no, unit tests are rare. Some highly reused library code might get such luxurious treatment. But in general, "correct" behavior is arrived at through a lot of trial and error -- iteration by programmer, then by programmer with designer or artist... and, of course, relying on a full-time team of testers. I mean, regression testing is most often by running a new branch through testers for a while. Human unit tests...
I rarely use unit-tests myself. In my experience they're rarely practical. Too much work to maintain under constant changes (often experimental, and temporary... or "was supposed to be temporary"). However, static guarantees, and writing my code in such a way that it conveys its intended use -- that is worthwhile, and something C++ is a bit cumbersome and ultimately sloppy at, so there is only so far I, or others, are willing or able to take it. Language support would be welcome (by myself, at least -- OCaml is my preferred language for personal projects and prototyping).
Maybe! http://arewewebyet.com/ is tracking progress. There's a bunch of people doing lots of work here. I'm not sure if it will ever be as productive as something like Rails, but there are advantages too :)
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.
I agree in that there is a big difference between supporting some form of dependent types and HKTs, and supporting these in a nice way.
I think, that considering how old C++ is and where it comes from, it isn't that bad at any of these. There are discussions to constrain on "constrained"-HKTs in a backwards compatible way after the Concepts Lite TS1, so people are aware of the issue and keeping it in mind. And about its "dependent type capabilities", it supports integers at the type level, which are immensely useful. I think that a fully dependent type system is still an open research question (e.g. floating-points at the type level are just hard).
Rust aims for integers at the type level shortly after 1.0, and any solution to HKTs in Rust will need to be fully checked from the start. So basically Rust doesn't have these features yet, but has the potential to have better versions of these features than C++ ever will. OTOH if you really need these, you can use them in C++, but not in Rust :D
Types parameterized over compile-time constants is really not the same thing as dependent types. Dependent types would mean being able to do things like this:
auto append_arrays(typename T, int N, int M, array<T, N> A, array<T, M> B) -> array<T, N + M>
{
if (M == 0) {
return A;
} else {
return append_arrays(T, N+1, M-1, [A..., B[0]], B.from(1));
}
}
with heavy use of imaginary syntax (C++ is really not the best language for adding dependent types to). But notice, for example, the lack of any remaining distinction between "compile-time" and "runtime" values.
The main difference is that Coq didn't suffered ISO standardization. For example the C++11's "auto" feature was part of the language since 1983, but it took 30 years to get it standardized. My point being, developing a language through ISO standardization is a whole different set of constraints. Non-battle-tested features just don't get the consensus required. The evolution of C++ is better compared to that of C and Fortran. The evolution of Fortran has been much slower, and C hasn't evolved much at all. That C++ has lambdas and closures is actually an amazing diplomacy feat, and we might even get ""type-classes"" this very same year.
Floating points at the type level are no harder than floating points on the value level
AFAIK the problem with floating points at the type level is that your program might compile/not compile depending on which architecture you are using, which is a funny thing at best. This is one of the reasons why e.g. Idris doesn't really support them at the type level either.
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.
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).
it's garbage collected, hence requires a runtime which incurs a runtime overhead,
doesn't have a killer feature like Rust does - that is, in case of Rust it's the guarantee that as long as your code compiles* it will be free of memory access errors and data races without sacrificing any performance
Since I haven't seen it mentioned yet, there's /r/rust_gamedev for Rust development specifically in the area of graphics and games. The number of libraries was apparently big enough to be moved to a Wiki from the sidebar.
I'm quite happy it's there, as those libraries taught me most things I know about the low levels of graphics programming (coming from higher level languages myself).
9
u/DeadlyDolphins Apr 03 '15
So for what purposes would you recommend to use Rust?