Criticizing the Rust Language, and Why C/C++ Will Never Die (2015) | Hacker News Reader

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

viva64.com

41 pointsfedericoponzi48 comments

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.

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.

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

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

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

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

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

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.

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

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

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

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.

If anyone would like to see some Rust deployment, take a look at this page.

https://www.rust-lang.org/en-US/friends.html

Scala was already popular before Lightbend (Typesafe). Its backing was academic (EPFL).

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.

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.

Maybe, but while COBOL was/is used in a few big mainframes C/C++ is used on the billions of devices everywhere, throughout the entire stack. Upgrading/deprecating them is not an easy task.

But Rust has fairly good interop so its feasible to move on, leaving the old code in place where applicable.

Given that consumer devices have a notoriously higher turnover rate than business machines (international or otherwise), all legacy languages will eventually trend toward COBOL-like retention curves.

You're making the flawed assumption that all consumer devices have a brand new stack of software written for them, which is absolutely false. Every popular OS kernel in use today is primarily written in C and C++. Most consumer devices are running some flavor of a *nix kernel (mostly Linux, with a healthy smattering of the BSDs as well).

People have been predicting the death of C and C++ for decades now and those two languages are as strong today as they ever were. BASIC and Pascal were supposed to kill them in the 80s on microcomputers. Java was supposed to kill them in the 90s, now people think Rust will do it, but history shows that to be pretty unlikely. C and C++ have an immense amount of inertia that is unlikely to be stopped any time soon.

  > You're making the flawed assumption that all consumer 
  > devices have a brand new stack of software written for 
  > them, which is absolutely false.

Except that, in practice, Android, iOS, and Windows Phone all had brand new stacks of software written for them. :P

  > People have been predicting the death of C and C++ for
  > decades now

Except that Java did kill C++ in the business application space. And Perl did kill C in the system administration space. New languages have been driving these two languages into ever-more specific niches for decades.

Also, I'm not sure why you're talking about C and C++ as though they're the same language. C's biggest long-term strength is ubiquitous platform support, and those platforms do not support C++. I see C as being unassailable in this space. But C++ is doing its damnedest to cling to the low-level application niche, and while it's going to continue to dominate there for the foreseeable future Rust is going to give it a run for its money.

In the meantime, Rust doesn't need to kill C++ to be successful. Rust's best niche--that is, safety-hardened low-level applications--is more than lucrative enough to sustain it, especially with a major player like Mozilla proving its utility. And thanks to this same safety, Rust is seeing use in niches that C++ has never gained traction in, such as being a language for writing extensions for dynamic language runtimes (traditionally a task for C).

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

The go results are inaccurate because "go" is not searchable and most people write "go" instead of golang. Try searching for "backend go" in indeed.com and you'll see what I mean.

Rust hit 1.0 18 months ago while everything else on that list is between 5-33 years old. Give it time.

Rust is beginning to be evaluated by large tech companies for production use (I can attest). When companies start using it and blogging about it, other companies will catch on and do the same. My money is on this number rising. Rust is something truly special, and I'd be shocked for it not to gain widespread usage.

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.

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.

This article is mostly poo with a few bits of goodness sprinkled in to detract from the stench. Now, directly to your comment, I usually evaluate on the ability to get things done. Often that means libraries. Linking to C/C++ libraries is relatively easy so I'd say there is a lot of potential. If you go back in time to 1996, how many jobs were there for Java? I doubt that many, probably took a few years...even with Sun pushing it. C/C++, even Fortran are going to be around for a long time. Languages like Swift get a good kick in the rear by sheer force of Apple's market share. Rust has only the user community to adopt it. Adoption is fairly easy, market penetration is tough (lots of adopters). It'll either happen or it won't.

That isn't a programming language's potential. Those job posts reflect current market demand, not potential. How much demand will there be for Rust programmers three or four or ten years from now, not just today.

Anyway, if you're going to take a purely mercantile approach to evaluating programming languages, you should consider the salaries these employers are offering rather than the number of job listings. Consider supply as well as demand.

I also prefer data, but this data isn't useful. Sure, there are a lot of companies looking to hire C++ programmers, but why? Is it because of growth in the demand for C++ application development? Or is it because C++ developers are moving on and the companies are having trouble replacing them? There's probably a mixture of both, but I believe we're going to see a continuing slide towards the latter.

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

This is an old article [2015] by a guy who is paid to attack Rust by a company that makes static analysis tools for C/C++.

But yeah, if you don't have haters, you're doing something wrong.

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

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

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.

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.

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

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

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

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

What is dead may never die!

(sorry, couldn't help myself :P)

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

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.

Previous discussion: https://news.ycombinator.com/item?id=9531822

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.

  > it restricts how you can access the machine in the name is spurious "safety".

Yet, you can also get around any of these things at any time.

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.

That makes it a wonderful systems language. Systems need to be stable and correct, not just fast. Rust has good performance, so it's got fast down. The restrictions that it introduces increase stability and correctness at the added cost (high to start, should drop as time goes on) of increased developer effort to get it correct (compared to C, one of the best footguns ever invented).

And the ability to create "unsafe" blocks allows you to minimize the amount of bullets that end up in your feet.

Reply on news.ycombinator.com