What Does C++ Do That Rust Doesn&#39;t?

Sure, OpenSSL for example has idiots writing code for them without review or any kind of controls in place. There's no issue with the fact that the code is obscure, the behavior unexpected, and that the language provides no easy tooling to ensure correctness, etc.

Nothing wrong with C/C++ 😄

Even if the language was easy to understand, without any gotchas anywhere, without any obscure syntax, undefined behavior, and so on, relying on code reviews is a bad idea.

Code review is performed by .. people. People are flawed. People wrote the original broken code, and people will review it and nod thinking it looks good.

When a language is well designed it can help people notice things that they should pay more careful attention to, or specifically signal "this bit is going to break the safety rules a bit" so you can focus triple effort on reviewing those 2 lines or something.

With C/C++ you're always guessing where the next gotcha comes from.

Jason C. McDonald • Dec 23 '19 • Edited

A lot of people complain about C and C++ being inherently "unsafe", but they forget all too often that their own favorite languages have gotchas too...they're just harder to spot, and far more unexpected to encounter. C and C++ don't pretend to be error-free. Given a proper understanding of the language, one can write production-quality code that has the stability of those "safer" languages, especially if one uses the newer memory safety features of C++14, C++17, and C++20.

...relying on code reviews is a bad idea.

Remember Linus's Law: "Given enough eyeballs, all bugs are shallow."

Writing code is an inherently human process. If you're looking for something fool-proof, it doesn't exist, since every language, tool, and algorithm was created by a human.

There are bad ways to do code reviews, but it's a poor workman who blames his tools. The greater danger is in not having code reviews at all.

When a language is well designed it can help people notice things that they should pay more careful attention to, or specifically signal "this bit is going to break the safety rules a bit" so you can focus triple effort on reviewing those 2 lines or something.

To some degree, you are right. There are "sharp edges" in C and C++ that are mitigated in some languages.

Of course, any serious C or C++ development team is going to have a slew of static and dynamic analyzers at their disposal that do exactly that.

With C/C++ you're always guessing where the next gotcha comes from.

Again, that "safety" that other languages promise is an illusion. C++ doesn't pretend not to have gotchas. In contrast, Python and Java developers (for example) love to proclaim that their language doesn't have any "undefined behavior", yet that is altogether untrue. UB may show up less often in those languages, and is usually billed under another name, but it is there.

Every language has undefined and unexpected behavior because machine code has undefined and unexpected behavior. And the less "UB" a language has, the nastier the remaining instances tend to be.

So if you like Rust, or whatever "safe" language you prefer, by all means, use it. But don't buy into the fallacy that it's somehow impossible to write deeply flaws code in $LANGUAGE.

Ben Lovy • Dec 23 '19

But don't buy into the fallacy that it's somehow impossible to write deeply flaws code in $LANGUAGE

I'm not sure that was the assertion - heck I'm writing Rust, you'd better believe there will be some deeply flawed code out there. The benefit of Rust specifically here is that it tags code sections known to be problematic, so you can punt some of that static analysis work currently necessary in a C++ codebase to the basic compiler, and then know where to focus your human-review efforts. To me this allows you to re-focus people time on jobs for people, and better leverage computer time for jobs computers couldn't previously do. While this won't prevent bad code, to me it does seem like it would isolate it somewhat. Wouldn't this property lead to a generally more focused development workflow over time?

Sounds like you have a fundamental misunderstanding of the argument and a knee-jerk reaction to someone not liking the languages you like.

It's possible to write bad code and bugs in every language
Not RELYING on code reviews to spot all your bugs is not the same as not having code review - there's a certain class of problems for which code reviews are the best tool available, spotting obscure bugs in your code is not really one of those
The issue here is that while you might find other additional tools that do some additional static checks, and there's warnings you can enable - since they are obviously possible they should be a part of the language, enabled by default, and not easy to bypass to create obviously broken code .. they shouldn't be optional warnings, they should be compiler errors that may occasionally be explicitly and individually suppressed.

Other languages have their own issues, but quite a few have evolved to say "hey, maybe we should try to stop the programmer from doing anything stupid at least without clearly acknowledging that they know it's probably stupid".

There is no such thing as a perfect language out there, I like writing Go a fair bit, but I still need external tools to check that I'm not ignoring errors and other things regularly. I think most of them should just be a part of the compiler. But hey, at least there's no #include and other such massively outdated bad concepts from C/C++ to worry about.

Elm's Maybe and case are amazingly helpful tools to avoid bugs where you, a human being, just forgot something, and a typical static analyzer sees nothing obviously wrong with the code. Elm forces you to at least clearly acknowledge that in this bit, you're ignoring some potential states. Zig has a similar concept to Maybe with their optional types.

Overall we should be using languages that are better designed, that come with "batteries included" in terms of the tools that try to ensure that you're writing good quality code, that try to help you avoid significant mistakes, that help your code review to focus on those bits where it's likely that you'll have critical errors in, and so on.

Another small point on this:

Of course, any serious C or C++ development team ...

Maybe that team just got started and they don't know of these tools, and maybe their project gets published and included in another project that just sees lots of GitHub stars and doesn't have the time to verify every line of code themselves. Maybe they just have one new team member, and their CI system had a bad day and just let all the bad code pass without any complaint.

Yes, it's possible to write good code in C/C++, it's possible to write decent (I wouldn't go as far as saying good) software in PHP. Just because it's possible with enough effort or luck, doesn't make the languages any good, or in any way invalidate the complaints about the languages.

On a small tangent - Python is one of my most favorite things to write in nowadays. It's the best performance enhancing drug a programmer can have in my view, as most things you need to accomplish are significantly easier to accomplish in it.

Unfortunately while Python has a lot of great things going for it, there's still a lot where it's failing. One such things is that I need to depend on a large number of external tools to make it possible for me to write good code.

I need poetry or pipenv to manage my dependencies, I need black to format my code properly, I need bandit to tell me about common security issues, I need pytest to help me write decent unit tests, and so on.

It'd be nice to see these also become a part of the official Python, but in case of Python, I'm quite hopeful vs. C/C++, as there's a long and clear history of pretty significant improvements having been made in the language without excessive fear about breaking things: python.org/dev/peps/

Jason C. McDonald • Dec 23 '19 • Edited

Just because it's possible with enough effort or luck, doesn't make the languages any good, or in any way invalidate the complaints about the languages.

And see, that shows the attitude I have a concern with. Just because you dislike C and C++ doesn't mean it "isn't any good." It just means, at best, that it isn't right for your projects. Every language is right for some type of use case. As someone who does a significant amount of work in C and C++, specializing in memory management and debugging undefined behavior, I probably know more about the inherent flaws and drawbacks of the languages than three quarters of the people on DEV.

But, truth is, only one of us is throwing about arguments devaluing the inherent usefulness of major programming languages, and as you'll note, that person is not me. Hand-waving dismissal of the validity or merit of tools that hundreds or thousands of other developers successfully use shows an overvaluing of one's own biases and opinions. It's often a sign of immaturity.

Case-in-point, just because I personally detest Javascript does not mean that Javascript has no value. I'm not going to write a long rant on why someone shouldn't use it, just because I personally dislike it! In fact, if someone were to launch a railing attack on the viability of Javascript, I'll be one of the first in line to remind everyone: every language has its use case, and none are without significant flaws.

So really, the one with the knee-jerk reaction here is you.

JavaScript is a terrible language and it should be replaced. So is PHP, so is C, and so is C++. They only have a "use" because decisions have been made that force those languages on us: JavaScript because it's the only one supported by browsers (this is changing with WASM at least and some languages compiling into JavaScript give some hope), PHP because people who started programming with it started some projects with it and executives keep hearing PHP programmers are cheap to hire, C/C++ because of history and lack of competition in the relevant area - this has also changed now and they will hopefully start fading away.

Yes, C/C++ has a use TODAY, because they're the only languages it's possible to do certain things in yet, for example Zig and Rust don't have a mature toolchain to build code for Arduinos. I'm just going to be glad when the day comes and there is no longer a single case where you need C/C++ other than the maintenance of old software, like COBOL today. I also know JavaScript pretty well because I need it, that doesn't mean I need to like it.

You're the one turning an argument about languages to a personal attack, and thus you lose. 😄

This really isn't moving anywhere, goodbye, merry christmas, and all that.

Ben Lovy • Dec 24 '19

I think you've both made good points, and both made personal attacks and talked passed each other somewhat. I agree, this thread is pretty thoroughly explored, thanks for the discussion!

Jason C. McDonald • Dec 24 '19

I'll just leave this here.

yourlogicalfallacyis.com/ad-hominem

Jason C. McDonald • Dec 24 '19 • Edited

Do you mean like this?

Sounds like you have a fundamental misunderstanding of the argument and a knee-jerk reaction to someone not liking the languages you like.

I apologize that I don't share your viewpoint, but this really needs to stop here. This could have stayed as a constructive discussion, and I tried to keep it that way. I expressed concern over your shift in tone, wherein you stepped over the line of the Code of Conduct (see above quote):

Being respectful of differing viewpoints and experiences

Trolling, insulting/derogatory comments, and personal or political attacks

Other conduct which could reasonably be considered inappropriate in a professional setting

As I said repeatedly, there is a tremendous difference between disliking a language and devaluing it altogether: declaring a language as being absolutely 'no good' (which you did multiple times) is a slap in the face of everyone who uses it. You know first hand what this is like, when you became angry at someone a few months back because they said Python was "poorly designed". It's not a "knee-jerk reaction," as you accused me of — rather, it is offense at having your professional knowledge and skill denigrated to irrelevance. Such denigration is rude, inappropriate, and below the bar of conduct for DEV.

In case you're concerned about my own statement earlier:

Hand-waving dismissal of the validity or merit of tools that hundreds or thousands of other developers successfully use shows an overvaluing of one's own biases and opinions. It's often a sign of immaturity.

Whether it's a sign of your immaturity is something you will have to decide for yourself; that's why I stated it as a correlation, but not a declaration about you. I want you to be aware of how you come across to others when you post railing declarations such as you did. Your knowledge, like mine, is a mere drop in the ocean, far too insufficient to declare something like C or Rust or Python or PHP as "no good". For one to believe they can, therefore, does require one to overvalue their own bias. Take it as a constructive criticism and move on.

We don't have to agree on whether C or C++ are great languages. You don't have to like them. You can even describe what you dislike about them, and where you believe other languages shine. But you do need to have enough respect for others not to denigrate the tools they successfully use as absolutely "no good" because of your own bias. Your words do matter.

Please let this be the last post in this thread, learn from it, and let's move on.

You really have a funny way of thinking. I say that you seem to have misunderstood my argument, you take it as a personal attack and call me immature. You assert your superior knowledge, and declare your opinion thus supreme and everyone else's point of view invalid, post memes to make fun of me, and then continue to complain about how I'm not respectful of your viewpoints 😄

It's a pretty poor attempt to compare my comments here to someone saying Python’s actual coding structure relies on white spaces in itself is "poor design". Also not really sure how any other discussion anywhere else proves your point regarding this one.

There's a difference between actively offending people, and saying things people find offensive. You might not like that I don't like C/C++, and I really don't care if you do or not, I also don't really care about "how I come off to others". That doesn't mean I'm "slapping" anyone, I'm just explaining my point of view.

If you don't like me calling something "no good", well that's a you -problem. Deal with it how you wish. I will continue to call things I dislike "no good" when I feel it's appropriate.

Ben Lovy • Dec 24 '19 • Edited

No minds are being changed, nobody will get a satisfying "last word", this is not productive and has little to do with the original post.

You are very right.

Jason C. McDonald • Dec 23 '19 • Edited

Yeah, probably. That said, LLVM Clang has many of that same sort of static analysis baked into the compiler, if you just turn the flags on for it. (-Wall -Wextra -Werror).

It's also pretty trivial to hook cppcheck into your automatic workflow and/or IDE to handle all the stuff the compiler doesn't complain about.

Ben Lovy • Dec 23 '19

cppcheck

TIL, thanks! I don't know that I've ever compiled C++ without that set of flags, I'm a little scared to.

Jason C. McDonald • Dec 23 '19

Just in case I wasn't clear, cppcheck is an external static analyser, but it's quite a good one!

Yeah, I never work without -Wall -Wextra -Werror. I ususally throw -Wpedantic in there too, for good measure.

Jussi Lind • Feb 25 '20

Also, Qt Creator IDE has an amazing static analyzer working out-of-the box.

Ghost • Dec 21 '19

"utterly irreplaceable" in some cases; in mine, I'm not interested in spend 10+ years to start confidently program concurrency and deal with memory drama. In many cases is irreplaceable but I'm not buying that those are all cases, ever, always, for any reason. The Mozilla team are not newbies nor Microsoft devs, and they are activelly working on Rust, I guess for them C++ is not utterly irreplaceable. That every line of C/C++ will be Rust or that C/C++ are soon to be dead is nonsense, not even COBOL is dead yet. But Python and even Ruby are alive in web dev when PHP exists. And many languages slowly started replacing Perl when everything was Perl; even Bash have lost some ground with Python. And we even have NO-SQL nowdays, who knew...

Jason C. McDonald • Dec 21 '19 • Edited

You misunderstand me. By "utterly irreplaceable", I'm referring to the entire programming landscape, not specifically to each conceivable case. C and C++ cannot be completely replaced across the entire industry.

Ghost • Dec 21 '19

My bad, I totally agree with that, as a side note: someone asked Linus Torvalds (the Linux kernel god) if he had plans to migrate the kernel to Rust, he answered something in the lines of "Rust seems interesting but nope, I like C", so there it is, not even C is soon to be dead.

Andrew Andersen • Dec 21 '19

The Prophet says: thee Old Gods to fall, New Ones will rise
      >Ok        >Mmmmmm

_sin.ns • Aug 11 '20

In Rust, bindings for existing C and C++ libraries can be leveraged for that use case. People are doing such things in production.

Jason C. McDonald • Aug 11 '20

Yes, but bindings are not the same as precedence. Your techniques may need to change with the language. It's like trying to use a StackOverflow question about the Qt5 library for C++ to answer a question about PySide2 for Python; same framework, different (official) bindings, differing techniques.

_sin.ns • Aug 12 '20 • Edited

You are correct in observation. But does the change in technique make a language inferior than other? Rust comes with some totally new paradigms which may seem uncoventional but that's the same experience developers in 1980s and 90s must have gone through when they had first taste of C++, Java or Python. Over time these dialects established themselves as solid and reliable tools.

Rust has got same mettle, it just needs consolidated organisational backing and continued professional interest which has already begun. Microsoft, Facebook and others are already founding their research efforts on Rust or have production systems running on Rust's shoulders.

Ben Lovy • Dec 21 '19

Sure, maybe

I suppose that's really my question.

Jason C. McDonald • Dec 21 '19

It just depends on whether there are enough experienced people more interested in The Future™ instead of writing stable production code right now, and only time will tell us that.

Ghost • Dec 21 '19

And those absolute decaration absolutely never are wrong, also those who calim that Rust is a C/C++ killer are the same that claim C/C++ are obsolete and dead languages i.e. frontend devs, webdevs, etc. I've never heard those claims from Rust dev teams or someone seriously working in Rust; in fact I've heard more about how to integrate C/C++ existing code, which by the way was the main goal from the start with Firefox, project that is now adding Rust to their existing codebase. I don't think anyone serious thinks that Rust is gonna replace them, who thinks the entire Linux kernel will be rewritten anytime soon is crazy, maybe never will, but new modules may be written in Rust in the future. Ruby and Python didn't born dead even when PHP and Perl had almost 100% of the web market; the fact that all the C/C++ codebase won't be replaced by Rust means nothing, is like saying that laptops born dead because we already had desktops or smartphones borne dead because of laptops, or electric cars are dead because of gas. To me the quora answers comes from a frustrated C/C++ programmer somehow envious of the Rust popularity and takes too serious and personal unfounded claims of the "dead of C"

Nested Software • Dec 21 '19

I would say the question isn't really whether something will "kill" c++ in the near term. The question is whether there are alternatives that can become viable ways to do certain kinds of programming. If so, then some of these alternatives may at some point replace c++. In the meantime, it's sufficient if a community can grow around something like rust that keeps it going and evolving into the future.

Dian Fay • Dec 21 '19 • Edited

An interesting footnote to his mention of how C/C++ "killed" Fortran: the startup I work for still depends on software written in it (wgrib2, for the curious). We're hoping to replace that dependency in the new year, but "dead" is very much a relative term for programming languages.

_sin.ns • Aug 11 '20

That is an opinion not a fact. You may like to consider this unbiased view from the architect of D programming language. qr.ae/pN212s

This was expressed in 2015, things have changed since then and Rust is much more powerful and capable now.

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.

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

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.