
Rust Language, and Why C/C++ Will Never Die (2015) - ghosthamlet
https://www.viva64.com/en/b/0324/
======
kibwen
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.

~~~
xiphias
benchmars game is great, but sadly not well maintained anymore. Rust has it's
flaws, but it's not runtime speed (much more compilation speed, IDE support,
distributed compilation support).

~~~
igouy
> benchmars game is great, but sadly not well maintained anymore.

?

rustc 1.32.0 as-of Sat, 19 Jan 2019

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/rust.html)

------
fhrow4484
Wow that's a long article, I tried summarizing the main points. I think some
of them have merit, but for the "technical reasons", I don't think I agree on
most.

Here are the points:

1 - there's a ton of existing c++ programs

2 - other have tried replacing c++ and failed (D for instance)

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.

Technical reasons:

4 - rust is not that fast

5 - c++ has all these static and dynamic sanitizers which makes rust not that
safer compared to c++

6 - if 90%/10% rule true, you could write most of your code in Go/Java and the
hot parts in C, instead of most code in Rust and hot parts in unsafe Rust.

7 - premature optimization "rant"?

8 - language verbosity complains around pointers (Box Rc, Arc)

9 - a few more reasons in conclusion, including issues with cargo pulling out
code from git repos

~~~
saagarjha
> rust is not that fast

I thought Rust was pretty competitive with C++ in this respect?

~~~
htfy96
I have to say that most "Rust is fast" articles I read stop at comparing
microbenchmarks written with not much care on performance. I really want to
see some comparisons in highly-optimized cases like linear algebra library
(Eigen) or game engines with things like stack-local allocators or even using
alloca() built upon EA STL/Folly.

------
pornel
Since 2015 Rust has grown and matured:

The article questioned whether Rust's design made sense. It looks like it's
holding up. Major pieces of software have shipped. Projects analyzing
language's soundness have found some bugs in libstd, but not any fatal flaws
yet.

The article complained about Rust's speed. In the benchmarks game it used to
be on par with Go, now (as far as the game goes) it's clearly faster than Go,
Java, Fortran, Ada and Swift.

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's getting
there.

The predicted huge mess of crates.io hasn'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.

The 2018 edition has shipped a new borrow checker that's easier to work with,
more powerful and properly namespaced macros.

Of course C/C++ isn't going anywhere, but it looks like Rust is here to stay,
too.

------
staticassertion
I'm reluctant to comment because the first iteration of this 'series' was
fraught with blatant errors, from what I recall.

> Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem
> to make sense except in the heads of the most frantic Rust fans.

I'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.

> for example Vala, Cyclone, Limbo, BitC. How many of you have even heard of
> these languages?

I'm aware of Cyclone and Vala, not the other two. Vala isn't even a little
memory safe, so not sure why it's mentioned. Cyclone was a research project
from my understanding, and that's it.

> By the way, most of the critics have never seen C++ code in production.

Not true.

> 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:

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.

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/which-programs-are-fast.html)

Here's the up to date benchmarks.

> 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.

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.

> But these are actually two dialects of one language, which doesn't look much
> different from the "Java + C" or "Go + C" combos.

Practically, there is a world of difference, given the lack of 0-cost FFI in
eithe rof the mentioned languages.

The rest of the article is just disconnected conjecture, I stopped reading. If
anyone thinks there's value to finish it though, let me know, I'll circle
back.

edit: It occurs to me that I'm not reading "The next in a series" but actually
an extremely dated article that wasn't accurate in 2015 and isn't accurate
now.

~~~
yholio
> 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.

So the reason Rust is slow is because C++ has features that allow programmers
to write faster implementations of the same algorithms? I think that's the
point he is making.

~~~
staticassertion
Not really, no.

His point was that fundamentally Rust will have overhead by being safe, and
that it's necessary to drop into unsafe to match the performance of C++.

He takes this further, stating that if you're going to drop into unsafe for
hot code, why not just use Java/Go and FFI into C++.

This is misleading or incorrect for a few reasons.

* Rust isn't considerably slower than C++ (again, the benchmarks are total nonsense and way out of date)

* The performance differences are not a matter of safety features (such as bounds checking array accesses), but separate features like constexpr, int generics, and SIMD.

* His statement on Go/Java ignores that Go and Java will pay a significant cost for calling out to C/C++ for the "hot code"

As an aside, Rust now has explicit SIMD, and there's progress being made on
`const fn` (the contexpr equivalent) and int generics.

------
bsder
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 _WILL_ use it. If game developers flip,
Rust is going to displace C++.

Embedded, unfortunately, is not a good canary. I _still_ 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 (<1M flash; <256K RAM). Development productivity on
those platforms is gated by way more factors than choice of programming
language.

~~~
dleslie
Game development isn't what it was ten years ago; better tools have basically
reshaped how games are made. C# is a serious contender for most-used language
in game development, because the gains in productivity thanks to related tools
easily make the performance impact worthwhile. Besides, hot points can always
be rewritten in something faster.

Or rather, many game developers already switched to C#. Most every major
engine has C# bindings to some degree.

~~~
steveklabnik
The latest news out of Unity is really interesting in this regard; they
switched from C++ to a restricted subset of C# for their hot loops, in my
understanding.

~~~
mwkaufma
Yes, it's much like asm.js -- the code works as plain C# but can also be fed
through their "burst compiler" to produce optimized native binaries:
[https://unity3d.com/learn/tutorials/topics/scripting/using-b...](https://unity3d.com/learn/tutorials/topics/scripting/using-
burst-compiler)

------
jonathanccast
C (and, to a lesser extent, C++) absolutely _will_ die. The way the languages
are managed guarantees this.

It's a myth that garbage collection is slow, and it'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.

Furthermore, while C and C++ require low-level attention to detail in managing
memory, they _prohibit_ many low-level manipulations that you might want to
use them for, if you're implementing e.g. an operating system kernel or a
language runtime, by assigning them 'undefined behavior'. 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's. (Haskell _also_ has raw pointers, it _also_ allows arithmetic
on them, it _also_ allows them to be converted to and from integers, and, in
practice, any _portable_ , defined-behavior low-level C code is going to end
up using operations remarkably similar to what Haskell allows.)

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.

The problem here is that C and C++ long (10 years or more) ago abandoned the
original X3J11 mandate to 'keep most existing programs working', in favor of
aggressively using undefined behavior for optimizations. You can'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 'optimization'.

~~~
solarkraft
> C is too high-level for system code

Aren't most systems written in C?

~~~
pjmlp
Modern computers aren't PDP-11 like anymore.

Multicore vector based CPUs with branch prediction, GPGPU, NUMA
architectures....

Some of those features are exposed as compiler intrinsics or C dialects for
GPGPUs (e.g. OpenCL).

However none of those features exist in the abstract hardware model of ISO C.

------
brianberns
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.

------
crimsonalucard
So basically C/C++ will never die because of ubiquity.

It's like gasoline and oil. Both will always be the dominant energy paradigm
because of ubiquity and because of habit.

~~~
maxxxxx
"Never" and "always" are dangerous words. Things sometimes change very
quickly.

------
IWeldMelons
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.

------
xiphias
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 / implicit vectorisation support, and a lot of
it is taken care of by LLVM.

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).

~~~
igouy
> Rust has Rayon (which is not yet used in the Benchmarks game examples)

Yes it is!

Since or before May 11th, 2017 —

[https://web.archive.org/web/20170511062152/http://benchmarks...](https://web.archive.org/web/20170511062152/http://benchmarksgame.alioth.debian.org:80/u64q/program.php?test=mandelbrot&lang=rust&id=4)

------
winterthedeep
(2015)

------
bjourne
I really wish people would just forget about unsafe ("unsafe" 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 "die" and be replaced
with high-level languages; Lisp, Python, Ruby, Javascript, etc.

I guess the fanboys will complain for me calling Rust unsafe. You can write
"safer" 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'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.

Offering safety and programming ergonomics for performance is a crappy trade.

~~~
dmitrygr
And how, might I ask, are you going to write your runtime for all these safe
languages?

~~~
bjourne
[https://en.wikipedia.org/wiki/Bootstrapping_(compilers)](https://en.wikipedia.org/wiki/Bootstrapping_\(compilers\))

~~~
dmitrygr
Won't work for any of the languages mentioned. Somewhere underneath it all you
need a runtime witten in a bare metal language

~~~
pjmlp
Rust, Go, Lisp do have certainly bootstraped compilers, with the runtime also
written with them.

For Python and Ruby, it is a matter of someone actually taking the effort of
doing it, which no one does because it would only be proving a point that
anyone with major in compiler design already knows it is possible, just with
lots of hard work.

