
Criticizing the Rust Language, and Why C/C++ Will Never Die (2015) - federicoponzi
http://www.viva64.com/en/b/0324/
======
naasking
It's interesting that his own points argue against his own conclusion. For
instance, "I can't but remind you for one more time that the source of
troubles is usually in humans, not technology", doesn't jive with the
conclusion that C/C++ are here to stay, nor does it agree with his point that
he was annoyed with the restrictions Rust placed on him.

If humans are the problem, then a language that restricts these problematic
human urges in a way that maximizes safety and extensibility is an important
solution. C/C++ does only one of these, and not very well either. Any solution
that strikes a better balance will replace C/C++ eventually, and I think Rust
is on the right track.

~~~
rkangel
I was going to make that exact point. Language design philosophy has shifted.
It used to be a question of giving programmers all the tools and trusting them
to do it right.

History (the list of CVEs if nothing else) has shown that even the best and
most well-intentioned programmers will shoot themselves in the foot on
occasion if handed a gun.

Modern language design has shifted to prioritise preventing such footguns,
while retaining as much programmer power as possible.

Humans _are_ the source of troubles, and so we give them tools that help them
not make mistakes. That's what will actually get Rust adopted (if that
actually happens): companies will weigh off the extra productivity (fewer
bugs) against the cost of switching.

~~~
saosebastiao
I totally agree, simply because all tools have learning curves. It is one
thing to learn a language, but it is another entirely to learn a language +
debugger + profiler + static analyzer + IDE + build system + package manager +
test framework + test runner, etc.. (Just typing this is giving me
Node/javascript anxiety...)

Rust has done an amazing job packing almost all of that into rustc + cargo,
and while there is a learning curve it is nothing like the learning curve
necessary to produce code of similar quality in C/C++.

------
kibwen
As I remarked when this article originally came out last year, there's a
certain delicious irony in a hit piece on Rust coming from a company that
makes its money writing static analysis tools to try and plug the safety holes
in C++. :P

~~~
dman
There is irony all around including in the rust communities own positions -
relying on jemalloc and llvm while claiming that reliable software cannot be
written in C/C++.

~~~
dead10ck
Show me where anyone involved in Rust in an official capacity has claimed that
"reliable software cannot be written in C/C++"

------
wyldfire
> take, for instance, the inevitable "stop the world" issue during garbage
> collection. ... 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

...and then he goes on to show a boxplot graph of (likely) CPU-bound
benchmarks. C++ pays a penalty (~1.7x?) and so does Rust (~2.5x).

Well, who cares about CPU?! Yes, okay, lots of you. But if you really care,
you rewrite that inner loop of your C++ system in C. And if you really,
really, care, you rewrite that inner loop in assembly (or corresponding
intrinsics). So, hey, here's what I care about: latency! Many systems designed
in C/C++ are thus because until recently it was just about the only game in
town for predictable low latencies (refer to the "stop the world GC" paragraph
above).

Also, there's no other language out there offering both memory safety and the
ability to do things like I/O and system control with memory-mapped registers.

Linking your rust code against C libraries and executables is not-super-
painful. So phase-in of rust code is easier than other languages described.

> On the one hand, it's not bad to make programmers ponder if their variables
> are stored in the stack or heap and if they can or cannot be handled by
> several threads at a time.

Indeed! All the C/C++ static checkers in the world can only hint "Hey this
might not be safe, but WTF I have no idea..." only to be declared
[FALSE_POSITIVE, IGNORE].

BTW authors of static checkers (like the translators at PVS-Studio) have a
vested interest in unsafe languages like C/C++.

~~~
bvinc
The benchmarks are from The Computer Language Benchmarks Game. I used to think
this was a good way to compare programming language performance. But if you
look into the results in detail, it's really not that simple.

If you look at rust vs C, you'll see many cases where rust is on par with C,
or beats C.

When you start comparing WHY some rust version of a program is twice as slow
as the C version, usually what you'll find is that someone has not spent the
same amount of effort optimizing that program. Or in some cases, you'll see
the C program using SIMD instructions, which you could do in rust, but it
isn't stabilized yet.

What you won't find, is some intrinsic reason that the safety of rust is
causing it to be slower than C. To just look at the benchmark totals and make
that assumption would be wrong, and that's exactly what the author did.

~~~
steveklabnik
Also, that screenshot is from a long, long time ago.

------
Cshelton
It's hard to follow this author's arguments because so many of them are simply
wrong and off base.

I've used Rust since 1.0 stable release, I have yet to write a piece of unsafe
code. Almost all of my code has run at speeds similar to C/C++. If something
in Rust is slow, then it is a bug. Of which the Rust contributors are very
good at getting rid of. The new MIR stuff will change a lot.

This guy also makes many blunt assumptions on what other programmers will do.
He says no sane programmer will write a webserver/service in Rust. Uhhh.. yes
they will and do. When they need to benefits that the Rust lang comes with,
they will/do already.

This guy clearly doesn't like Rust, which is fine. Most programmers have a
language they really dislike that is popular. Nothing wrong with that.

As for "replacing" C/C++, no, in the near future it won't It may never. But
the fact of the matter is old programmers will....grow older, retire and be
gone. Young programmers just getting started in their career/education will
look at the ecosystem of tools available to them and make their own choices on
what to use. Which in turn has the potential to make C/C++ go the way of
COBAL. Rust isn't the only language either. Many new languages will arise in
the next few decades that will completely displace some of the most popular
languages now. That's how it is. I frankly do no see C++ being used for new
programs 20 years from now. Unless it is a new subset of C++ that does not
resemble anything like C++ today...which for that matter...is a new language.

Sure, C/C++ programs will be around for at least a few decades. But will
anyone new program in them? Highly doubtful. Rust is just one of the first
displacing languages. And this is not a bad thing. We SHOULD rewrite many of
the things that we heavily rely on. They have to evolve and not be tied down
to something written decades past. System kernels will be re-written. Linux
itself, eventually, will effectively be re-written. (Yes...it will take a
while, may be something else, not called Linux...Redox perhaps?)

If it were up to this author, all language developers would only be working to
make C++/C faster/safer.(The author calling C++ "safe" is laughable, he even
counters his own argument elsewhere in the article about humans being the weak
point. ) No. We have to reject that. Just as Henry Ford said, "If I asked
people what they wanted, they would say 'faster horses'".

~~~
rkangel
> I've used Rust since 1.0 stable release, I have yet to write a piece of
> unsafe code

Yes, he conflates 'unsafe' with 'fast'. Speed doesn't necessarily require
unsafety. Very occasionally it does, but Rusts approach to checking everything
at compile means that mostly it doesn't.

------
nickpsecurity
I'm not upvoting this toward the front page because, although the writer makes
some smart observations, the piece largely doesn't apply to Rust due to key
misconception:

"You know, it's like the "Chicken or the Egg" dilemma. On very rare occasions,
this problem does get resolved (relatively representative examples are Go and
Scala) - mostly thanks to investments of time and money from some large
company (Google, Typesafe) who for some reason finds it worthy to popularize a
new language."

Which is exactly what happened with Rust. A large company put significant
resources into language, compiler, libraries, and community. Already meant his
write-up didn't apply to Rust if that was a precondition of its truth. It then
of exploded in usage and available code. It was also deployed at Dropbox for
mission-critical apps. So, many things he says it will need to prove something
are already there. Amazing thing is the article from 2015 was disproven by
Rust ecosystem by 2016.

~~~
vvanders
Agreed.

I think the freetype alternative that made the front page of HN the other day
puts the performance argument pretty well to bed. The rest seems to be things
that the author doesn't agree with(exceptions) or "You're just not using it
right"(to paraphrase the last bullet point at the end).

So far I've been using Rust in every side-project where I'd use C++ and you
know what I don't miss? Crashes/stack corruptions/etc because of an off-by-one
error. 90% of the C++ code you write is not the inner loop, that said if I
want to use modern C++ stuff I'd still be hitting the heap for std::vector.
Rust's iterators are an awesome way to keep everything stack based in a nice
ergonomic way.

Most recently I wrote a packet library over an AX.25 radio link in Rust. With
about 1:1 code:unit test radio most stuff _just worked_. I've almost never
seen that in a production C++ library. C++ isn't going away but for me Rust is
here to stay.

------
greydius
C and C++ will eventually die in the same way that COBOL has died. That is,
they'll never go away, but there will be fewer and fewer people able and
willing to use them.

~~~
tkinom
I prefer data on evaluating a programming language's potential:

Search indeed.com for

C++ : 4287 jobs.

golang : 71 jobs

Java : 6817 jobs

Rust : 7 jobs

~~~
PopsiclePete
Trust me. You would _not_ enjoy roughly the 92% of Java jobs out of that
number. My Java work was easily the most corporatish "enteprise" soul-sucking
nightmare that I'm glad to be out of forever. I bet the majority of the Golang
jobs are fun, in small teams though. I know which one I'd rather work on.

~~~
AnimalMuppet
How much of that is Java's fault, though? Would those jobs be any less
horrible if that software was written in COBOL or C++ plus CORBA? Probably
not.

------
dcu
So Rust has started to receive criticism which means it's becoming popular. As
the creator of c++ says:

    
    
        "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

~~~
falcolas
How about "the ones that are evangelized to the point of annoying everyone
else"?

~~~
AnimalMuppet
They're in the second category - the ones nobody uses. Once people start using
them, they'll move into the first category.

(Note well: This does not mean that no improvement is possible, or that all
languages are equally bad. It merely means that the perfect language has never
been written, and likely never will be. If people are using it, they will run
into limitations, problems, and areas of frustration. Then - hello, human
nature - they will complain.)

------
sickbeard
I always chalked it up to the "I'm old" sentiment. There hasn't been a
language that has actually caused us to think of writing a different kind of
software. Sure we write nicer easier code but the software remains the same in
the end, buggy, full of problems and not maintainable. These are the problems
we should be solving.. the result of what WE code, not how pretty it looks in
the ide.

------
zaphar
He considers Racer to be insignificant. And while It's true that it doesn't
yet do everything an IDE usually does it's also true that Racer is exactly the
path that Languages should be taking in the future. Locking all of that logic
up in an IDE in ways that it can't be factored back out makes automated
refactoring and analysis tools harder to build.

It locks people into editors they may prefer not to use and just generally
splits your user base up in ways that are unnecessary.

Providing a build your own IDE api is a superior approach that more and more
languages are moving over to.

~~~
kibwen
Going forward there are indeed plans to continue to develop suitable
interfaces for IDEs/tooling in the Rust compiler itself, to further facilitate
easy integration (for example, the ability to typecheck incomplete fragments
of code). Mozilla has a vested interest in making the programming experience
as pleasant as possible, since it intends to have more and more employees
using the language as time goes on. :)

------
legulere
> Wikipedia tells us that there were a lot of other attempts besides D to kill
> C++ - for example Vala, Cyclone, Limbo, BitC.

Vala pretty much is a DSL for writing GTK+ programs. Cyclone is a safe dialect
of C. Both don't really have anything to do with C++.

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

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

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.

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

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.

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

Not at all obvious - I suspect not in fact wrong at all.

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

So maybe C++ is worth using at Google. Most of us aren't Google.

> But if we want to follow it word for word, why not use bubble sort instead
> of quicksort in all of the code?

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)

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

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.

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

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.

~~~
gsnedders
> 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

That's not actually the reason why Rust doesn't have a GC, nor it the reason
why Servo doesn't have a GC. (It's worthwhile remembering that Rust predates
Servo, and it has always been a goal to not require a GC.)

The reason why there's such a big desire to avoid GC is to have predictable
memory layout and to avoid the overhead of the GC. In a browser, having
predictable memory layout is important to be able to control memory usage, as
well as for performance.

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

With the proviso that Rust predated Mozilla's involvement and any attempt to
write a browser in it, I totally agree. The fact that no browser vendor has
managed to write a secure piece of software is pretty damning—these aren't
small applications written by small teams, these are big applications written
by very well funded development organisations which absolutely have the budget
to do plenty of work to ensure their products are secure.

------
GreaterFool
What is dead may never die!

(sorry, couldn't help myself :P)

~~~
dllthomas
That is not dead which can eternal lie. And with strange aeons even death may
die.

------
rkangel
This title needs editing with a [2015] tag.

The original was written in April last year and some of the things it talks
about are out of date.

~~~
ben0x539
Previous discussion:
[https://news.ycombinator.com/item?id=9531822](https://news.ycombinator.com/item?id=9531822)

------
jbb555
Rust isn't a proper systems language, it restricts how you can access the
machine in the name is spurious "safety". A small number of people are making
a lot of noise about it, but it's not going anywhere.

~~~
adrusi
Maybe it doesn't line up with your definition of a systems language, whatever
that is. But in practice it's works in places where you would otherwise need a
systems language, like writing device drivers. Don't get too worked up over
semantics.

