
Criticizing the Rust Language, and Why C/C++ Will Never Die - afiskon
http://www.viva64.com/en/b/0324/
======
steveklabnik
I left a comment on Reddit that I'll adapt here. It's really intended at the
Rust community specifically, but I think the message is still worthwhile
anyway:

Not everyone is going to like Rust. That's totally okay.

I've seen language communities, especially newer ones where people are
particularly passionate, essentially turn into... this is a bit strong, but
mini-cults. Where if you don't like the language, you're obviously an
illliterate pleb who needs to learn how to code. This ends up creating an
insular, backwards, dangerous culture. I'd prefer a culture of "we're doing
cool stuff, I hope you like it, but reasonable people may not, and that's
okay."

I'm not really speaking about any particular language here, please don't try
to 'figure out who I'm talking about' or something.

While it's true that the author may have only breifly tried Rust, and not
tried to understand design choices, this is going to be the first of many,
many blog posts like this as we grow after 1.0. The vast, vast majority of
programmers haven't even tried Rust yet. Flamebait blog post titles are a
standby of today's programmer culture. We shouldn't get too hung up on it, and
instead, focus on doing cool stuff with the people who do get it.

[http://www.reddit.com/r/rust/comments/35pn5a/criticizing_the...](http://www.reddit.com/r/rust/comments/35pn5a/criticizing_the_rust_language_and_why_cc_will/cr6mspj?context=3)

~~~
cicero
I've been programming for 35 years, and I remember when object-oriented
programming advocates seemed cult-like. As it turned out, O-O is a very useful
tool, but it is not the ultimate programming paradigm. Time has shown that the
early adopters of O-O were mostly justified in their enthusiasm, but tended to
overstate the benefits of the technology. The O-O naysayers had concerns about
performance, which is an issue in some O-O languages, but one that C++ solved.
They also had concerns that O-O was hard to understand, but that is something
that has been mostly solved through education. These days, the expectation is
that a good programmer understands O-O.

Today, I see similar reactions to leading edge technologies and languages that
are difficult to understand, whether they be FP, Rust, or Haskell. Time will
tell whether these things break into the mainstream as did O-O, C++, and Java.
I personally think that Rust is onto something, but it is too early to know
how much impact it will have on the mainstream. Who knows, 10 years from now,
we may see a dominant OS and application ecosystem written completely in Rust
that has a level of quality seldom seen today. Or maybe we will see some of
the ideas in Rust incorporated into a future version of C++. Or maybe Rust and
its ideas will prove to be too impractical and will fade away.

I hope to have the time to learn and use Rust soon, but I certainly understand
those who prefer to wait and see. What I don't care for is a knee-jerk
reaction against something because it is unfamiliar.

~~~
azth
> Today, I see similar reactions to leading edge technologies and languages
> that are difficult to understand, whether they be FP, Rust, or Haskell.

I wouldn't lump all three together just because they may happen to be somewhat
difficult to understand. I see your point regarding FP (and Haskell happens to
be an FP language). However, Rust is a multi-paradigm language, just the way
C++ is. Time and time again in my day job, I see issues in our code that Rust
would have prevented at compile time (and we're not using C++).

~~~
cicero
I didn't mean to imply that Rust was only FP; I was just listing examples of
current leading edge technologies and languages.

------
putzdown
It's true that C/C++ will never die. Not everyone loves them, but they're both
good languages and they both have their place. Part of that place is due to
mere tradition, mere established-ness, but part of it is real merit in terms
of speed and directness.

It's true that Rust aficionados tend to come across as religious zealots. Most
"up and coming" language advocates do. This is a case where zealotry is
understandable and maybe necessary. When you've got a good thing that's an
underdog in a world ruled by the familiar, the status quo, zealotry is the
only way to break through the complacency.

It's also true that between awkward English, poor structure, and a lack of
rigor in argumentation, this article comes across as drum-banging rather than
thoughtful. I'd like to see an article that respects Rust, respects C/C++, and
offers a measured, well-argued case for how they compare and what their
prospects are in the long term when "establishedness" becomes less relevant
(i.e. when Rust, through becoming more widespread, becomes less hampered by
not having a large community or job base).

~~~
sanderjd
As someone who is gung-ho and hopeful about Rust, but an outsider, I would
also like to see that measured, well-argued article.

I thought this article had some truth in it, but in general I'm always
frustrated by the implication (which pops up from time to time) that languages
with similar goals are mutually exclusive and newer ones must kill the older
ones or themselves die. C++ is a great language which has been on a tear of
improvement for the past decade or so, and suggesting that something will, or
even should, kill it is silly. But it's just as silly to suggest that it is
pointless to target the same goals as C++ while attempting to improve on some
of its weaknesses.

I think it is likely that Rust will not be the rocket-ship of growth that Go
has been, because while Go has attacked a niche by largely upending its ground
rules, Rust merely provides some (arguably) better trade-offs within a
fundamentally similar paradigm. A better comparison will perhaps be Scala and
Java, and that's something to aspire to – Java isn't going anywhere, but there
are lots of great things written in Scala and plenty of opportunities to use
it professionally.

Certainly, it will be interesting to see where or if Rust finds its place in
the types of large and enduring projects that it takes to really get a
language off the ground. I think a particularly interesting area could be the
ever-expanding database sector. It's clear (perhaps to the chagrin of many)
that there is room for many different database products attacking different
trade-offs, and they are often written in C++ (or C) for performance reasons,
but have high bars for robustness and concurrency for which Rust really may be
a boon.

I do think a lot of Rust's adoption will hinge on its performance story, and
that was the argument in this article, and others along these lines, that is
the most compelling. To be in the running for projects that would otherwise be
written in C++ (like the database projects I mentioned), Rust will need to
have credible and competitive benchmarks. I think it has made many good
choices about the fundamental trade-offs that have a huge impact on efficiency
(like defaulting to value types), but that it remains to be seen if pervasive
safety comes at too large a cost.

------
jpgvm
It doesn't help that the only language they could think of to compare Rust to
is D.

While D is alright it was never really slated to be the "next systems
language" in the way Rust is being positioned.

The other part of the argument that comes across as really weak is criticism
of Cargo. That would make sense if the alternative had better tooling. However
if you have ever tried to assemble libraries and a decent build process for
them in a large C++ project you would know that Cargo is almost like a gift
from god.

Claiming that Rust is "simple" because it doesn't have inheritance is also a
straw-man. Inheritance is far from the only means of polymorphism and it's
presence has little bearing on the overall power of the language. In fact I
would argue Rust's trait system is actually the more powerful of the two, but
that is just my opinion.

Overall the author comes across as trying to find reasons to dislike Rust for
the sake of disliking it, as if they feel threatened by it's very existence.

------
moonchrome
>OK, but doesn't it imply that I do not need Rust at all because I could write
90% of my code in Go and the rest 10% in C? Only silver bullet seekers and
airy-fairy (t)he(o)retics will use Rust just for the sake of feeling contented
about having 100% of a program written in seemingly one language.

Have you actually tried to do that or understand what Rust unsafe code means ?
Interfacing between different run-times and memory management systems is
complicated (and often slow), rust unsafe is simply giving up on compiler
verification.

He misses the point on premature optimization entirely.

>For Android, it's also hardly probable, but for a different reason: there is
way more than one architecture there, so JVM will do much better

And yet people write C++ code for Android, or is he arguing that Rust won't
replace Java on Android (that's a pretty big straw man)

>I can't but remind you for one more time that the source of troubles is
usually in humans, not technology . If your C++ code is not good enough or
Java code is painfully slow, it's not because the technology is bad - it's
because you haven't learned how to use it right. That way, you won't be
satisfied with Rust either, but just for some other reasons. Isn't it easier
to learn how to use more popular tools and start liking them?

Different tools require different amounts of effort to get things "right" and
it's not simply a matter of "learning things" \- humans have limited brain
power - there's only so many things you can be aware of at any time - good
tools reduce the number of those things required to get the job done - C++ is
bad at this.

I agree with some of his points about the ergonomics and the
implementation/tooling but I also feel like those are just growing pains - now
is the time you start working on Rust for your weekend github project and
start paving the way for actual real world use by early adopters which is at
least a year off from this point.

~~~
semi-extrinsic
There's a lot of the "write X% in slowlang and (100-X)% in fastlang" thrown
around, but I have to say, I've not seen too many such projects around.

~~~
ThatGeoGuy
Actually, in the CHICKEN Scheme community, this is done quite often, though
you don't see it nearly as much because of how transparent it ends up being.
Mostly stuff is written in Scheme / R5RS when possible, and C bindings to a
faster library or implementation are exported using the bind egg when speed is
of critical importance.

This is obviously not the norm, as the bind egg is very good, but it's
definitely out there. Makes me wish that there were other languages which
offered something similar to bind, but alas CHICKEN is the only one I know of
thus far.

------
mkpankov
Note the translation is done by a company which makes C++ static analyzer for
a living.

This might be the case of conflict of interest and/or heavy bias.

~~~
astrodust
It also means they know what they're talking about.

Many of the points are valid, but it's important to remember Rust is not even
released. Java 1, Ruby 1, Perl 1, Python 1 were all pretty terrible compared
to their current manifestations.

~~~
EugeneOZ
They know only 1 part of the bridge, but without second part is not the
bridge, but shameful biased grunt "oh oh, will we still make money on C++ or
we need to learn something new to keep our income?". And question is answered
before they company existed. They even dare enough to recommend others don't
learn Rust in favor of C++ - so biased recommendation makes whole grunt even
more pointless.

Don't get me wrong, I understand difference between constructive criticism and
biased grunt of grumpy C++ programmer.

------
dicroce
I have made my living as a C++ programmer for 20 years.... C++ is not going
away any time soon, but Rust looks pretty cool... I see no reason to bash it.

------
jononor
I note that there are no arguments that C/C++ is better than Rust, except that
it has been used for longer (and thus has more tools & knowhow around it).

~~~
lambdaelite
That C/C++ have a formal standard and have an entire tool ecosystem is a huge
advantage over Rust for mission critical and safety critical areas (not that
Rust would be used for SC applications).

~~~
outworlder
> "is a huge advantage over Rust for mission critical and safety critical
> areas"

There's no C/C++. They are entirely different languages (even if C is supposed
to be a subset).

Not exactly suitable for mission critical systems. The fact that they are used
for that is more due to the fact that they can interface with hardware at a
fairly low level and the amount of engineers with C (and nowadays, C++)
knowledge.

The 'formal' standard doesn't help you much when there's so much undefined
behavior.

Tool availability is a fair point.

~~~
Alupis
> There's no C/C++. They are entirely different languages (even if C is
> supposed to be a subset).

C++ is a subset of C, not the other way around.

> the fact that they can interface with hardware at a fairly low level

That's certainly one reason. Others include raw performance (think real-time
safety-critical applications), no funny abstractions, tighter memory
footprint, more flexibility, etc.

> and the amount of engineers with C (and nowadays, C++)

While I believe there are a number of C++ engineers out there, I'd wager that
the number of competent C language engineers has dwindled over the years.
Sure, everyone learns some C, but to know it well enough to write embedded
real-time safety-critical systems is a whole different game. (not to mention
the number of Java engineers has greatly outpaced even C++ engineers, thanks
to University teaching Java, Android's dominance, and the lower barrier to
entry).

> The 'formal' standard doesn't help you much when there's so much undefined
> behavior.

The formal standard defines what is undefined. Your safety-critical code
shouldn't rely on some compiler-specific quirks or some magical code, but
rather it should stay within the bounds of well-defined behavior.

~~~
outworlder
> C++ is a subset of C, not the other way around.

I can't see how this statement could possibly be true.

> no funny abstractions

Really? Maybe I suck at C++, but I can't meaningfully reason about template-
heavy code. Not about the run-time performance, nor resource consumption. STL
and Boost are beyond funny if you ask me.

> The formal standard defines what is undefined. Your safety-critical code
> shouldn't rely on some compiler-specific quirks or some magical code, but
> rather it should stay within the bounds of well-defined behavior.

Agreed. But take a look at the specification and you'll be amazed on just how
much stuff is left for the actual implementation to figure out.

~~~
lambdaelite
> But take a look at the specification and you'll be amazed on just how much
> stuff is left for the actual implementation to figure out.

Which is why the coding standard for a critical project will disallow the use
of things that can lead to undefined behavior.

------
duaneb
TL;DR the implementation is currently slow and there's a lack of tooling.

No shit. C++ has been around for 30 years now.

------
AnimalMuppet
There's a real point hiding in the article, and not quite stated explicitly:
If a language (call it X) exists and is widely used, because it's really
useful for certain things, and another language (Y, say) comes along, then for
Y to replace X, Y has to be _significantly_ better than X _at the things that
X is good at._ Otherwise Y gets viewed as "kind of interesting, but not worth
the investment to make the jump", and languishes in obscurity.

------
serichsen
COBOL will never die, either.

------
barosl
> the source of troubles is usually in humans, not technology

And this is exactly the reason why Rust even exists. I find it amusing to see
the author use it to defend the C++'s side.

------
azth
> This is a huge mass of fast, debugged, and time-proven code.

Like OpenSSL...

------
VeejayRampay
Regarding speed, I am not sure it really is the bee's knees.

The existence of LLVM and the likes, the fact that Javascript got a HUGE
speedup in the past 5 years seems to be an indication that it is by essence a
factor that can be tuned eventually. I doubt a "slow" language will ever get
to be C in that regard, but I also doubt C will ever provide the kind of ease
of mind that a more inherently modern and secure language like Rust offers out
of the box thanks to its memory management model. And at the end of the day,
in a web-centric world, the latter might well be what programmers and users
alike happen to care more about.

~~~
duaneb
It's a little silly to quibble about speed when the language is still being
designed. There is plenty of time to optimize the language; there's not much
technical barrier to matching the speed of c/c++, especially when allowing
unsafe code.

However, something I've noticed from the land of C++ is some peoples' issue
with the idea that thread safety is difficult. In fact, they appear to
downright bristle at the idea that they might not write perfect code and that
they might lose the ability to run with fast-but-not-correct code. I don't
think this is a conscious reaction, but it seems similar to what's going on in
the article.

~~~
rwj
This is an interesting question, but I'm not convinced it is the case. Many
people have argued that Java, Ruby, (insert favorite language here) will one
day match the speed of C, it just requires more advanced tooling, but that
promise has never been fulfilled. Many abstractions come with a cost, just
look at the jump between C and C++. Perhaps Rust will match the speed of C,
but I don't think it is certain.

~~~
duaneb
> Many people have argued that Java, Ruby, (insert favorite language here)
> will one day match the speed of C, it just requires more advanced tooling,
> but that promise has never been fulfilled.

The primary block to this is memory management. Rust allows a superset of
C/C++ memory management techniques, so there is literally no technical reason
you shouldn't be able to port a c program to the equivalent rust program.
Unlike java, go, etc., this doesn't break new ground in terms of optimization
but rather verification of existing systems programming techniques.

To put this another way, you could write a rust -> c++ compiler and
"automagically" get the speed of c++, but the same could not be said of Java.

The one area of which I'm unaware is pointer aliasing (in unsafe code,
obviously). I am not entirely sure how well rust can restrict the types to
optimize exclusive access to a memory region ala the c `restrict` keyword. But
there's always inline assembly if that fails.

~~~
steveklabnik
&mut pointers ensure that they are the _only_ reachable alias to a given bit
of memory.

~~~
duaneb
So, it's functionally equivalent to a "restrict" keyword in unsafe mode? (i.e.
you can alias without the compiler being able to prove it as if you weren't
aliasing.)

~~~
steveklabnik
My C is a bit Rusty, so I'll say that they follow
[http://llvm.org/docs/LangRef.html#noalias](http://llvm.org/docs/LangRef.html#noalias)
which says

    
    
        > Note that this definition of noalias is intentionally similar to the
        > definition of restrict in C99 for function arguments.
    

I'm not sure if they just mean 'similar' or if it's actually exact.

If you alias, you might break, as optimizations will assume otherwise.

Oh, and `&mut` pointers are safe to use, not unsafe.

------
pc2g4d
What did everybody make of the benchmarks cited in the article? I couldn't
really understand what they actually represented, or if I should put much
stock in them. I was surprised that Rust didn't come out better in those.

~~~
steveklabnik
A bunch of changes landed right before the beta release some weeks back, and a
bunch of examples broke. We also haven't invested much time in making sure
that the examples have kept up lately. We used to beat C++ in several of them,
but who knows what's happened since.

------
jack9
> As a result, we risk ending up with a huge mess with packages like in the
> Erlang world with its Rabar

This should be "Rebar"

------
oldmanjay
I get that this is a translation but it's very poorly written even considering
that. lots of repetitive conclusion jumping in what I can only assume is an
attempt to baffle the reader into uncritically accepting what appears to be a
largely unsupported opinion.

the only evidence the post seems to offer is that rust is slow because it
showed up 5th in a set of microbenchmarks. everything else is rhetorical
garbage, frankly.

~~~
jcranmer
Correction: a set of microbenchmarks whose own documentation emphatically
states the difficulty of drawing any conclusions from those results.

Comparing different programming languages is notoriously difficult,
particularly since the metric is underdefined. The best programmers might
write faster code in language A compared to language B, but if average
programmers write code that is no faster, does that mean language A is better
than language B?

~~~
igouy
> the difficulty of drawing any conclusions from those results <

The difficulty of drawing general conclusions from program performance
measurements -- not just "those results".

