> Note: Further in this text, I am presuming that Rust is a conscious attempt to create a fast and safe language. After all, it was initially conceived by the guys from Mozilla as a tool to develop a browser engine. But if it proves to be yet another just safe language, then I just don't get the whole thing. There is plenty of very different safe languages to choose from to any taste, and if Rust is not meant to replace C++, then (1) why does it need to include an unsafe subset?; and (2) why did the authors throw away lightweight processes from Rust? They are convenient, after all, aren't they? In other words, if I'm wrong in my assumption, then the whole affair just doesn't seem to make any sense at all.<p>> I sincerely hope that programmers will find a way to speed it up in time, but until then, it's going to be of hardly more interest than Scala or Go from the viewpoint of the safety/speed compromise. The question is still open if it is possible at all to make a language both fast and safe or if it is automatically doomed to be twice slower than C/C++ because of the constant checks for array overruns, safe wraps of bindings to C-libraries, and other stuff like that.<p>If it ends up being a factor of 2 slower than C I really don't think that matters. The point isn't to be faster than Ada/Go/Scala/Java/Haskell/OCaml, it's to be as safe as those without GC - primarily for the sake of using it in a Javascript runtime and not having to run two GCs.<p>> Anyway, in any serious project, you use a continuous integration system and run tons of tests when compiling builds. If you don't, then your troubles are much worse than the language's lack of safety because static typing doesn't guarantee correct execution logic!<p>Guarantees are absolutely possible. Most practical programs don't guarantee everything in the type system, but test suites don't guarantee everything either. For a practical program where you have a certain acceptable defect rate, it's not at all clear that a large test suite will be a cheaper way to achieve that than a type system, and my experience is in fact the opposite.<p>> Following its logic, we could rewrite 90% of WebKit or VirtualBox or GCC into Java and get the same result. But it is obviously wrong.<p>Not at all obvious - I suspect not in fact wrong at all.<p>> Well, it depends on the project scale. For Google, even a few percent may help save millions of dollars (see Section 5, "Utilization", in the paper). Or imagine that with a next update, JVM will suddenly start requiring 10% more resources!<p>So maybe C++ is worth using at Google. Most of us aren't Google.<p>> But if we want to follow it word for word, why not use bubble sort instead of quicksort in all of the code?<p>Go ahead. See if I care. See if you care. 99% of the time, bubblesort really isn't a problem. (Not using library functions is a problem, so in practice this would never come up, but it really isn't a performance problem if you do end up using bubblesort)<p>> After all, who will dare to argue that finding a hot spot, rewriting the code (perhaps tons of it) and proving it has become really faster is an easier job than think about performance in advance?<p>What are you talking about? That is absolutely a lot easier. Needing to rewrite tons is extremely rare, at least in a well- or even moderately-structured program.<p>> So, to sum it up, personally I will be investing my time into studying C/C++ rather than Rust in the next 5 or so years. C++ is an industrial standard. Programmers have been using it to solve a huge variety of tasks for over 30 years now. As for Rust and stuff like that - they are just odd toys with vague future. People have been predicting C++'s soon death since the 2000-s, but C/C++ hasn't become less used and demanded for since then. Quite on the contrary, in fact. It is evolving (C ++11, C++14), new tools are released (take CLion and Clang, for example), and the number of vacancies is just huge.<p>If you believe the future looks like the past then sure. Personally I think the Internet will become both more vital and more hostile: the security requirements of a web browser are a canary for things that will become requirements for every program in 5 or 10 years' time. Mozilla started Rust because they couldn't write a safe enough browser in C++. That should be a warning to anyone who wants to continue using the language.