Rust Language, and Why C/C++ Will Never Die (2015)

Per HN guidelines, this article should have its publication year of 2015 in the title (the article itself seems to not include a date, but one can find the various submissions on Reddit where this was originally discussed). In fact, it's old enough that it even predates the Rust 1.0 release. I haven't gone ahead and read it in full again this time, since the irony of a company selling C++ static analysis software denouncing the utility of Rust is not lost on me, but it would be interesting to see someone with time on their hands go through and see how things have changed in the past four years. In my skimming I noticed it criticizing Rust's results on the benchmarks game, which indeed have improved to C++ levels since then.

Wow that&#x27;s a long article, I tried summarizing the main points. I think some of them have merit, but for the &quot;technical reasons&quot;, I don&#x27;t think I agree on most.<p>Here are the points:<p>1 - there&#x27;s a ton of existing c++ programs<p>2 - other have tried replacing c++ and failed (D for instance)<p>3 - no one will use Rust until it has cool IDE stuff and production ready libraries: a chicken and egg problem that Go was able to solve with Google support.<p>Technical reasons:<p>4 - rust is not that fast<p>5 - c++ has all these static and dynamic sanitizers which makes rust not that safer compared to c++<p>6 - if 90%&#x2F;10% rule true, you could write most of your code in Go&#x2F;Java and the hot parts in C, instead of most code in Rust and hot parts in unsafe Rust.<p>7 - premature optimization &quot;rant&quot;?<p>8 - language verbosity complains around pointers (Box Rc, Arc)<p>9 - a few more reasons in conclusion, including issues with cargo pulling out code from git repos

Since 2015 Rust has grown and matured:<p>The article questioned whether Rust&#x27;s design made sense. It looks like it&#x27;s holding up. Major pieces of software have shipped. Projects analyzing language&#x27;s soundness have found some bugs in libstd, but not any fatal flaws yet.<p>The article complained about Rust&#x27;s speed. In the benchmarks game it used to be on par with Go, now (as far as the game goes) it&#x27;s clearly faster than Go, Java, Fortran, Ada and Swift.<p>The article questioned whether anyone sane would write web servers in Rust. There are some nice web frameworks now. AWS officially supports Rust in Lambda. Futures-based ecosystem for async programming is growing. It&#x27;s getting there.<p>The predicted huge mess of crates.io hasn&#x27;t happened yet. crates.io is lucky to have npm a few steps ahead of it, so it can proactively prepare for growing pains that are coming.<p>The 2018 edition has shipped a new borrow checker that&#x27;s easier to work with, more powerful and properly namespaced macros.<p>Of course C&#x2F;C++ isn&#x27;t going anywhere, but it looks like Rust is here to stay, too.

I&#x27;m reluctant to comment because the first iteration of this &#x27;series&#x27; was fraught with blatant errors, from what I recall.<p>&gt; Rewriting it is way, way too expensive, risky, and, honestly, doesn&#x27;t seem to make sense except in the heads of the most frantic Rust fans.<p>I&#x27;ve met hundreds of rust developers at this point and at no point in conversation has anyone ever expressed that we should be working to rewrite every C++ project in Rust.<p>&gt; for example Vala, Cyclone, Limbo, BitC. How many of you have even heard of these languages?<p>I&#x27;m aware of Cyclone and Vala, not the other two. Vala isn&#x27;t even a little memory safe, so not sure why it&#x27;s mentioned. Cyclone was a research project from my understanding, and that&#x27;s it.<p>&gt; By the way, most of the critics have never seen C++ code in production.<p>Not true.<p>&gt; Rust is safe indeed but, unfortunately, far from fast. By the moment of writing this article, it is comparable to Java, Go, and Haskell regarding performance:<p>Old benchmarks, no discussion of why those benchmarks are the way they are. Benchmarks without analysis are just meaningless charts. Old benchmarks are even worse.<p><a href="https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;which-programs-are-fast.html" rel="nofollow">https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;...</a><p>Here&#x27;s the up to date benchmarks.<p>&gt; or if it is automatically doomed to be twice slower than C&#x2F;C++ because of the constant checks for array overruns, safe wraps of bindings to C-libraries, and other stuff like that.<p>There are a lot of really interesting reasons why Rust is slower in some benchmarks, like lack of constexpr or int generics, which at least one C++ benchmark uses heavily.<p>&gt; But these are actually two dialects of one language, which doesn&#x27;t look much different from the &quot;Java + C&quot; or &quot;Go + C&quot; combos.<p>Practically, there is a world of difference, given the lack of 0-cost FFI in eithe rof the mentioned languages.<p>The rest of the article is just disconnected conjecture, I stopped reading. If anyone thinks there&#x27;s value to finish it though, let me know, I&#x27;ll circle back.<p>edit: It occurs to me that I&#x27;m not reading &quot;The next in a series&quot; but actually an extremely dated article that wasn&#x27;t accurate in 2015 and isn&#x27;t accurate now.

The question about C++ vs Rust boils down, to me, when the game developers finally decide to switch. Game developers are not wedded to languages, if something is 25% more productive they <i>WILL</i> use it. If game developers flip, Rust is going to displace C++.<p>Embedded, unfortunately, is not a good canary. I <i>still</i> program all of my devices with C and not C++. C++ simply brings nothing to the table for the end user of an embedded device (&lt;1M flash; &lt;256K RAM). Development productivity on those platforms is gated by way more factors than choice of programming language.

C (and, to a lesser extent, C++) absolutely <i>will</i> die. The way the languages are managed guarantees this.<p>It&#x27;s a myth that garbage collection is slow, and it&#x27;s furthermore a myth that manual memory management is easy. So C (and, to a lesser extent, C++) will continue to lose ground for new projects to languages that take the requirement to manage memory off the programmer.<p>Furthermore, while C and C++ require low-level attention to detail in managing memory, they <i>prohibit</i> many low-level manipulations that you might want to use them for, if you&#x27;re implementing e.g. an operating system kernel or a language runtime, by assigning them &#x27;undefined behavior&#x27;. The C or C++ abstract machine, according to the actual language standard enforced by the compilers, is not noticeably closer to even the PDP-11 abstract machine than, say, Haskell&#x27;s. (Haskell <i>also</i> has raw pointers, it <i>also</i> allows arithmetic on them, it <i>also</i> allows them to be converted to and from integers, and, in practice, any <i>portable</i>, defined-behavior low-level C code is going to end up using operations remarkably similar to what Haskell allows.)<p>So C (in particular) is too low-level for application code, but too high-level for system code; there is no realm where C is advisable for a new project. That leaves maintaining existing programs.<p>The problem here is that C and C++ long (10 years or more) ago abandoned the original X3J11 mandate to &#x27;keep most existing programs working&#x27;, in favor of aggressively using undefined behavior for optimizations. You can&#x27;t keep breaking your existing programs without convincing some of their maintainers that re-writing in a new language is a better option, and without new programs that means that C and C++ will, inevitably, die, when the last program written in them is either abandoned or re-written after the compilers (yet again) break them with a new &#x27;optimization&#x27;.

I think a more important question is whether Rust will supplant C++ for new development at some point. Obviously, no one is going to rewrite the existing C++ code base from scratch.

So basically C&#x2F;C++ will never die because of ubiquity.<p>It&#x27;s like gasoline and oil. Both will always be the dominant energy paradigm because of ubiquity and because of habit.

I do not like Rust, but the argument about the lack of a big corporation to back the new language does not seem to hold water.

The Rust - C++ speed comparison is sadly quite bad. On a modern machine, some of the benchmarks from the benchmarks game ran faster in Rust than in C++. It usually depends on the explicit &#x2F; implicit vectorisation support, and a lot of it is taken care of by LLVM.<p>Also if you look at the C code, the multi-threaded optimizations are quite hard to write in C, while Rust has Rayon (which is not yet used in the Benchmarks game examples).

(2015)

I really wish people would just forget about unsafe (&quot;unsafe&quot; as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to &quot;die&quot; and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc.<p>I guess the fanboys will complain for me calling Rust unsafe. You can write &quot;safer&quot; programs in Rust just like you can in C++. They are however not as fast as those using unsafe parts of the language. You will never get the same kind of total safety as you get in, say, Python because Rust doesn&#x27;t do overflow checking. It does in debug mode, but you are strongly encouraged to distribute binaries in release mode since the speedup is substantial.<p>Offering safety and programming ergonomics for performance is a crappy trade.