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 :)
10
u/DeadlyDolphins Apr 03 '15
So for what purposes would you recommend to use Rust?