DEV Community

What Does C++ Do That Rust Doesn't?

Ben Lovy on December 21, 2019

I want to preface this by saying these are my two primary languages. I have a healthy respect for both and plan to focus on both regardless. I kn...

Read full post

Arswaw • Dec 21 '19

As soon as I saw your question, I thought I'd bring up this Quora answer from Mario Queralt. He describes how just moving on from C++ is essentially impossible, and it is Rust that is the dead language.

quora.com/Why-is-the-Rust-programm...

Jason C. McDonald • Dec 21 '19 • Edited

Interesting take. I was going to say something quite similar: Rust will always lack the precedence of C++! Between C and C++, there are stable, reliable implementations of nearly every algorithm, data structure, and design pattern known to computer science. Countless libraries offer reliable means of working with hardware, graphics, sound, GUI, system...the list is practically endless.

Could Rust have that in 20 years? Sure, maybe. But until then, C++ is utterly irreplaceable. I have bigger problems to code for than to reinvent everything that exists.

Erebos Manannán • Dec 21 '19

Unfortunately I think you're right to some extent, at least in the sense that this is what most people do think, and that it always takes time to make big shifts anyway.

There might be good algorithms for C & C++, but at the same time they are known to repeatedly fail in creating stable and safe programs .. it's not an insignificant amount of serious security flaws out there caused basically by the fact that the software was written in C/C++.

One of the biggest hurdles for languages tends to be the fact that the library ecosystem takes a long time to grow, but Rust seems to provide reasonably easy ways to use C APIs, and make libraries that can be called from C, so that's less of an issue for sure. Also Rust does bring something significantly better to the table for that safety.

Also many decisions about programming language choice are made either by executives who can just see Java and C/C++ are popular among enterprises, or by people starting their own hobby project and picking something they know.

My personal hunch is that it's just two things:

Rust's syntax is a bit hostile. It uses unfamiliar characters etc. to signify unfamiliar concepts, so someone new to Rust will not understand Rust code by looking at it, even after some basic tutorials. However the unfamiliar concepts are pretty much what makes Rust so strong so it should be worth learning.
People are flawed beings, they have biases. PHP took a long time to rise, and will unfortunately take a long time to die. PHP programmers have invested significant time and effort into learning this and they don't want to face the reality when you tell them that the design flaws in the language are not quite so common in many other options, instead falling back on propaganda style mantras about how PHP 7 is faster (was never really an issue with the language) and fixed most problems (no it really didn't)

I've been personally very excited to see several viable C/C++ killer options grow lately, and I'd like to see them learning from each other and finally take down one of the bigger class of problems the IT industry has - C/C++ programs & programmers 😄

Btw. Personally I see Zig being a more likely option as a winner in the end since it doesn't introduce radically new syntax and hurdles for developers, instead it's basically "a better C that even compiles C better". Incredibly interesting project and cool guy behind it.

Ben Lovy • Dec 21 '19

The Zig page is a phenomenal read. Might be time to install the compiler.

William • Dec 22 '19

The security flaws you refer to are not a failure of C or C++. They are a failure of idiots using well made tools.

Ben Lovy • Dec 22 '19

So what's the remedy for idiots?

Ben Lovy • Dec 22 '19 • Edited

Maybe rust gains the high-ground in 10 years, and gets thrown back down in 15 by a new language to fix all the things someone sees as a problem with Rust

Or we just all stick to C++40! Very fair point.

The Linux kernel, said to be written in C, is in fact written in C, C++, Assembly, Objective-C, and possibly more under the "other" category that are programming languages and not meta languages.

Of course, any sufficiently complicated task will require a rich set of different tools fitted to different parts of the problem, but to me the C++ needs are also met by Rust.

(assuming we haven't wiped ourselves out by then)

Oof. Altogether too fair :)

PartialEq seems to be exactly like operator==, just with a different syntax

Yep, more or less. The benefit to me is in using them. If you were to write a binary search tree, your Node might look like this:

template <class T>
struct Node
{
    T val;
    Node *left;
    Node *right;
}

Now you can build a Node<int> or Node<double> or whatever, but in your insert() method you will assume that T overloads both ==/<. Is there a way in C++ to tell the compiler about this? In Rust, you constrain it:

struct Node<T>
where
    T: PartialEq + PartialOrd
{
    val: T,
    left: Rc<RefCell<Node<T>>>,
    right: Rc<RefCell<Node<T>>>,  // or whatever pointer type
}

Now this code won't compile unless your T is an appropriate type. It serves as both documentation and stronger static analysis. As far as I'm aware, all you get is the failiure to build when your code attempts to use a method like operator== that doesn't exist for your current T class.

Any unimplemented cases of operator== default to a standard implementation

This is precisely the behavior I feel is inferior to Rust, which will fail to compile with a friendly message telling you to implement it specifically instead of guessing and failing.

the programming community in general has to see that SomeLang has better features than SomeOldLang.

I think this does cut to the core of my question. From my (completely novice) perspective, that seems to me like what we are working with. General consensus, though, is clearly that that's not the case. I understand the arguments for C++'s proliferation - it's of course not going anywhere, but I want to understand more about why Rust isn't actually as cracked up as it seems.

Ben Lovy • Dec 22 '19 • Edited

Thanks, this is a great response, but I do think we've mismatched on a few points. First:

Arguing over which programming languages are the best and likely to beat others isn't going to be productive

That's not at all the spirit of this post, though I see how it could be taken as such. These are my two favorite languages. I do very much like Rust, and I very much like C++, and will continue to work with both for years to come. This question is more a thought experiment about inherent technical merit and domain fitness than about changing the landscape of software development.

Operating systems are also written in (or at least contain) C/C++

They do, yes, but what I'm drilling for is whether there is something inherent in C/C++ that Rust could never possibly replace, or whether this ubiquity is historical. The redox experiment is doing a solid PoC already, imagine what it'd look like with another 20 years of ecosystem development.

Templates aren't directly about inheritance, but rather about generalization

I also agree it's a bit confusing how I wrote it up, but I do think I understand what templates are and how to use them - they're a core mechanism for building abstractions. I brought up Rust macros and OCaml Functors for the same reason, they're how to build toolkits for programmers and grow in a sane way. The equivalent in Rust is just the fact that you are able parameterize a type, you don't need to write template <typename T> first. Classes and structs drive OOP C++ programming, but when comparing to how code is crafted in Rust the generic programming properties of C++ are a more direct fit. For that the core mechanism is templates.

Rust traits go a little further. For instance, when you use that type, as far as I know there is no way to specify that you expect the type to overload operator==. In Rust, you constrain T to types that implement PartialEq, and that alone feels worthwhile to me. I don't know of the equivalent for C++ beyond just using it correctly. I don't fully understand them, but I think C++20 concepts may address this, but I'm not sure what the answer is in C++11 (or earlier).

All in all, I agree. Languages are preferences, and at the end of the day it doesn't matter what you use as long as it gets your job done well.

Tarun Elankath • Aug 12 '20

Ridiculously late reply, but I just came across this now. C++ 20 now has formalised concepts that can apply constraints to generic types, so this gap has been addressed.

Rust AFAIK is still missing fold expressions and variadic templates. Once you get used to these features, you wonder how did you live without them. Also, I like exceptions and method overloading. C++ also has std::error_code for those who wish to have exception less functions. The C++ FS library provides both throwing and non-throwing variants of their API.

As a polyglot programmer (forced to be one thanks to several projects), I found Rust to be the MOST complicated language - yes, even more complicated than modern C++ to learn. I learned C++ seriously only after C++ 17 and frankly all the hoopla about it being difficult was overhyped. I am actually a bit faster in C++ than in Java.

The Rust borrow checker twists my head and my code and I don't appear to focus on the problem I am attempting to solve anymore. I prefer the clean, easy, automatic memory management of modern C++ and simply following recommended safe programming practices via Core Guidelines. I can run static analysers independently of my main programming flow to avoid breaking my immersion and they catch all my bugs without interrupting me. Coding Rust gives you anxiety sometimes - you need to please the Emperor. Also, Rust compiles slower than C++.

Also Rust ecosystem is perennially in Churn - what compiled some months ago no longer compiles today. Libraries keep breaking. Stuff keeps changing all the time. C++ is well-specified and standardised language with a stable and well-defined standard library with multiple implementors. And you have a stable ecosystem with well documented libraries. And admittedly cargo is quite good but, I only started using C++ after CMake/Conan/Vcpkg won the build/packager tools war, so I never faced the old autotools+make headache that folks used to complain about.

Rust doesn't have a spec and still has only one implementation and is backed by a foundation that kicked out many of the engineers working on rust.

Frankly, Rust sounds like a lot of hype and fluff to me. But I am just an average programmer joe who is likely bad at predictions.

Maniflames • Dec 21 '19

Interesting takes in both the post and the comments. To me Rust was about having enough control of memory without worrying too much about runtime errors that are hard to debug compared to C++. I don't think one thing will 'kill' the other. Most languages evolve into a language that has a great ecosystem for doing 'x'. Rust doesn't have that yet in my opinion but I do believe that it will. I guess we'll see in a few years :)

Ben Lovy • Dec 22 '19 • Edited

The EOL date is officially set (I haven't paid attention - we might've passed the date as well)

Python 2 EOL is in 10 days - Jan 1, 2020 :) Great example.

The code examples are much appreciated, this is indeed what I was missing:

template <typename NA, typename NB>

However, that still kinda feels like, well, a "clunkier Rust trait". Which I absolutely concede is a matter of opinion. My concrete criticism is that C++ will still happily instantiate your template with whatever you ask for, and then fail at the first offending method call. Your type has been existing fine in your running program until then. Rust is able to prevent nonsensical types from being instantiated in the first place, so you never get to a runtime condition where you're looking up these template operators at all.

Ben Lovy • Dec 22 '19

In terms of lines of code, it's one line shorter.

That's not necessarily what I'm getting at in terms of programmer ergonomics, but it is an interesting observation, thanks for pointing that out. I think it will take me a little longer to find an example to illustrate the mismatch here in functionality.

Runtime?

My turn to pull the half-asleep card - definitely didn't mean runtime, just successful instantiation. Control flow advances to the offending method call with an object that will not succeed, and the equivalent Rust kicked out the error at object creation itself.

Ben Lovy • Dec 22 '19 • Edited

Isn't that just different placement of the error

Yep, 100%. The difference is conceptual, not practical. The Rust Node<T> is not generic over any type T, it is only generic over types T that implement ==. Any attempt to instantiate it with a type that does not is actually a type error. Traits further qualify and constrain types. In C++ it's not a type error, it's a method resolution error. As a programmer, when building this object, I do really mean to say "generic over types that can be compared for equality", not "generic in general and I promise later I'll tell you how to do it", even though where we get in the end is functionally equivalent. As it's being used, an inadequate T class is actually not part of the "type" of this object.

That feels to me "more correct", or at least more expressive. Practically, though, yeah, maybe it doesn't make a difference.

C++ is kinda simple like thta: if you don't use it, you don't pay for it

Rust strives for this as well, the difference here being that any type used in this object will use it, and the compiler is capable of making sure everything is in order before even starting down that road.

Daniel Smith • Dec 23 '19

Isn't that just different placement of the error

I don't think this is completely true. It is at least simpler to constrain generic types more strictly than the current implementation requires in Rust. You may wish to add extra constraints on the type to give yourself implementation flexibility without needing to break callers. For example, if the current implementation only requires equality but I only want to accept types that implement ordering, that's pretty trivial in Rust. I would guess you could use some if 0 trick in C++ to use the operator but not impact the implementation, but that obscures intent at a minimum.

Daniel Smith • Dec 23 '19

Conversely, (stable) Rust does not have the equivalent of SFINAE. Specialization is available in nightly, which is pretty similar. I've seen this come up comparing Abseil Swiss Map and Hashbrown maps. The former will usually do the most efficient thing by default, but the latter requires the subtle RawEntry API to do things like lookup or insert without copying unless I'm actually inserting.

AngularNodeJS 🚀 • Dec 23 '19 • Edited

Javascript and Web ASM is going to kill this debate of what language to use in the near future as the JS Engine will move out of the browser and become native with cross-platform support and access to native OS APIs.

When in doubt, always bet on Javascript!

I coded in C++ for 10+ years, I don't miss it, it's too low-level and suffer from having to write tons of your own code. Rust, I've been told is not a simple language to learn for most web programmers. So forget adoption from web developers.

I personally wouldn't waste my time learning Rust as much as I don't care for C++ and how unproductive that language is. I'll just wait it out and be super productive in JS writing native cross-platform code compiled to Web ASM.

Here is a nice talk about what's coming: youtube.com/watch?v=Qn_4F3foB3Q

Ben Lovy • Dec 23 '19 • Edited

Interesting take.

not a simple language to learn

Nor is C++, but lots and lots of people have anyway.

forget adoption from web developers

Perhaps, but I don't think web developers make or break the issue here. AssemblyScript and such projects do seem interesting, but I am curious if they will be adequate to completely replace lower-level languages used to produce WASM today. WASM is a low-level concept, and having a more granular level of control in the source language is often a good thing here. Writing all your WASM in a language that lacks facilities for this might work for some domains, but I'm not convinced you can blanket-replace C++/Rust here with something like JS. I could very easily be wrong, but while JS can product WASM, can it actually produce highly optimized, tightly controlled WASM?

I don't think every developer will need this, most applications will be perfectly happy without it, but I do think some of us will.

All that said, too, while I agree WASM is game-changing tech, it still only addresses a subset of where C++ proliferates today. I think this is only addressing one part of the tool.

AngularNodeJS 🚀 • Dec 23 '19 • Edited

Yes WASM bytecode will be highly optimize, both using static analysis and dynamic branch-prediction as done in V8 Engine and SpiderMonkey JS Engine. Even right now execution time for hot-optimize JS is close to C++ code.

Here is a talk from Google JS vs C++: youtube.com/watch?v=aC_QLLilwso

The Moz technical committee along with other peoples are working on defining low-level system APIs that will be uniform and standardize. We will get true cross-platform support.

The main point is, we will finally have cross language interoperability. I will be able to use Python modules, or C/C++ libs with my JS code and likewise other language will be able to use NPM module. Basically everything will be compiled down to a WASM package, module or whatever they end up calling it.

JS with WASM will never replace something like C/C++/Rust for low-latency system coding, but how many people code drivers? or ultra low-latency systems? The typical developer will want to code some application or server most of the time. Most all will go with the easier dominant programming language to code in. Even the hype train at Mozilla for Rust has died and they stop pushing Rust as the language for the web.

WASM is going to be game changer, both in and out of the browser. Most likely you won't notice any changes, as new build tool and do the compiling for you.

Ben Lovy • Dec 23 '19 • Edited

Points all well taken, but I want to code drivers! And compilers, and kernels. If I could do so in Rust, I'd be much happier than in C or C++.

There are many, many types of programming.

I will be able to use Python modules, or C/C++ libs with my JS code and likewise other language will be able to use NPM module.

Right with you there. WASM is a game changer. I'm just not sure that makes Rust a waste of time...maybe even the opposite.

AngularNodeJS 🚀 • Dec 24 '19

Let me take that back What I meant to say is, knowing what's coming, there is no reason to switch to different programing language. They will all run at "almost" the same speed as WASM bytecode.

Sure if you want to re-write the OS in Rust, then that might be a project you want to take on. It won't be any safer or bug free.

Whatever you do, never ask Linus why Linux is coded in C and not C++ :-D

harmful.cat-v.org/software/c++/linus

Swastik Baranwal • Dec 25 '19

Nice post, I think Rust cannot really replace C++ because it's there for many years but Microsoft is forking Rust to make a new programming language so I think Microsoft is/will ditching C++ which uses a lot of things from C++. Like most Windows Applications are written in it.

Jussi Lind • Feb 25 '20

In my opinion it will be C++ that'll evolve and replace itself. Microsoft and Google have created tons of "cool" programming languages that they always ditch even themselves after a while. What's the point?

Swastik Baranwal • Feb 26 '20

It's like saying that we don't and shouldn't use C but it is needed to run on all hardware.

Ben Lovy • Dec 25 '19

Agreed, replacement is not likely or even probably warranted, but symbiosis could be.

Swastik Baranwal • Dec 25 '19 • Edited

I think Microsoft is trying to combine Rust and C++ into one which would be amazing.

林子篆 • Dec 21 '19

If really have to let me complain Rust, then that would be the feature: lifetime, unless 'a > 'b already be introduced into Rust. Except that, I think C++ allows we have full control of memory management(so we have several ways to do that, but I think this against with safe guarantee of Rust) which is very important in a very very special case, and of course not really matter for most users; I think that's why I use Rust most of time XD.

Jason C. McDonald • Dec 24 '19 • Edited

Full control = you can hurt yourself more easily
Features = more ways to hurt yourself
Safety = limits on what you can do

Features with safety built in are a bit like railings around the Grand Canyon rim. They keep you safe, but you can't rappel down to study the cliff face. For that, you'd have to climb over the railing...at which point, if you don't do it right, the safety feature kinda adds to the ways you can hurt yourself.

Or you just can't get over the railing, and there goes the geologic survey.

It's always a tradeoff, innit? XD

Jason C. McDonald • Dec 24 '19

Sorry to cross-post to another of my own articles, but I've been pondering this for a few days, and the conversation keeps reminding me of this:

A Trendy Article From 2048

Jason C. McDonald ・ Jan 23 '18 ・ 5 min read

#culture #coding

Ben Lovy • Dec 26 '19

This was a fun read!

After all, Linux is still written in Rust, and it works great despite that language's terrible error handling.

Just curious - is this an actual commentary on your thoughts about Rust error handling in today's context, or merely a commentary on how our understanding should be expected to evolve? At least comparing to C++, Rust's Result is a solid win over try/catch for me.

Jason C. McDonald • Dec 26 '19 • Edited

It's more of an ironic statement. Since Rust's error handling is reputed to be so cutting-edge now, like try/catch was in its day, I'm imagining that it could be considered "clunky" and "terrible" in 30 years.

Ben Lovy • Dec 22 '19

Kill/replace hyperbole

I definitely didn't intend for this post to head that direction, either, it's an unproductive and uninteresting conversation. I'm more curious about why I might be incorrect about my assumption that, all else equal, Rust could plug in to any situation where C++ is currently deployed and hold its own.

_sin.ns • Aug 11 '20

Rust carries the elegance of Haskel, capabilities of Scala and modern C++ and power and speed of C yet some concepts (e.g. ownership) are of its own and are unheard of in any other language. With due respect to C++ and the community around it, the question must be the other way around "what's in Rust which is not in C++"... Success of a language in modern times is a function of the depth of support by corporate houses and not just community enthusiasm...

If a language is capable, it will eventually find it place... Rust's engineering team is a world class group of language engineers not to mention the vibrant community which loves Rust and can trade anything for it.

For a non opinionated view, see this answer from D-language architect, another powerful language: qr.ae/pN212s

MurrayVarey • Dec 21 '19

How much of modern C++ is a response to languages like Rust, I wonder.

Ben Lovy • Dec 21 '19

I think it's a back-and-forth.

Jariullah Safi • Dec 21 '19

I see it more as modern c++ and rust both being responses to modern complaints, rather than one informing the other (well, other than the obvious influences on Rust like how Rust strives to have its abstractions as lightweight as C++'s).

MurrayVarey • Dec 23 '19

Absolutely. I've not used Rust much, but it's definitely good for C++ to have some quality competition.

ShalokShalom • Dec 23 '19

C++ is already known to the people. People are afraid if new stuff. Thats it

Jussi Lind • Feb 25 '20 • Edited

Well...I tried to study Rust, but soon gave up. It's just too different and the ecosystem is not there. Has nothing to do with being afraid.

When talking about C++, people should realize that C++11 is completely different than the legacy C++. There's not much benefit in Rust in my opinion anyway.

ShalokShalom • Feb 25 '20 • Edited

So you dont know the language and you think you can say it has no benefit to Rust, despite that industry legends say so and there is actual evidence for it?

100% guarantee of no occorance of the most security relevant issues is no benefit?

Increased understanding of how a proper memory management can look like neither?

Jussi Lind • Feb 25 '20 • Edited

I have never had any issues with the "unsafe" memory management of C++. Rust advocates make it sound like every C++ application does nothing but crashes and leaks. Of course that's not the case. With RAII and smart pointers memory management is a non-issue.

Btw: zdnet.com/article/google-programmi...

Fuchsia supports C++ fully. Rust - not so much. This is one example of the ecosystem problem.

I'm not saying Rust doesn't have the features it has. They are just not that valuable FOR ME.

Jariullah Safi • Dec 21 '19

If the existence of Rust eventually causes C++ to become a significantly better language with a sane ecosystem, then we'll all be better for it. Rust doesn't have to replace C++ in order to "kill" it.

Jason C. McDonald • Dec 21 '19

Related.

Retraction of an Obituary

Jason C. McDonald ・ Dec 28 '18 ・ 8 min read

#culture #coding

S. Sharma • Dec 25 '19

Not a Rust or C++ programmer, but I’ve seen similar comparisons between Go and C (and I’ve used both), and there’s this same dichotomy of “C is dead, Go reigns supreme” and “C is still useful, Go is dead/just another language.”
Whatever you can do in Go, you can do it in C probably much quicker (yes there are exceptions, but for the most part this is true), but there are also many applications that are more efficiently written in Go AND are more concise than C (again, there are exceptions, but for the most part this is true).
I think we can extend this argument to Rust and C++ as well. There are use cases when writing Rust code is probably better than writing C++ and vice versa. It just depends on what you’re writing. I doubt that C++ will go away soon, but i wouldn’t be surprised if it became confined to maybe a few use cases.

AngularNodeJS 🚀 • Dec 26 '19 • Edited

I was curious to see what the trend is for these programming languages in the last 5 year.

I'm actually surprised people are still more interested in C/C++ these days with Golang and Rust being on the hype train.

trends.google.com/trends/explore?d...

Lorenzo (Mec-iS) • Dec 22 '19

C++ templates were introduced in C++11 and I still don't know if are inspired or instead inspired generics in Rust. Reconstructing the historical process is also somehow important.

Ben Lovy • Dec 22 '19

C++11 introduced variadic templates, but non-variadic templates existed before then. Each successive release has extended the feature set significantly, though. Generics are seemingly universal, I think it would be tricky to pinpoint a "chicken-or-egg" moment between Rust and C++.

Jason C. McDonald • Dec 24 '19

It's worth noting that C++ didn't kill C, either. ;)

So I think you're right on that nothing is likely to "kill" anything else.