Why Rust Isn't Killing C++ (2024)

My thesis has long been that it's impossible to replace C++ with a single language. C++ got into the trouble it has because it permits any and all development to occur within its walls. The C++ committee cannot make any decision without alienating some niche C++ industry that nevertheless represents at least hundreds of millions of dollars per year. The result is a jumbled mess of mismatched and incompatible features that provide a combinatorial explosion of hiding places for surprising and dangerous interactions in otherwise innocent looking code.

Rust (and insert any other language here) can only kill C++ by being C++.

However, we're seeing quite a lot of systems language development over the last decade and a half. Which is surprising coming from any sort of money making venture. To create a serious language, you're signing up for a decade of hard work at a minimum just to get your foot in the door. Then an endless parade of technical and community building issues to wade through, forever.

C++ cannot be killed off by one language, but it can be killed by a dozen or two languages. So we're seeing Rust, Hylo, Vale, P, Odin, Zig, Jai (do we have a release date for that one yet?), Carbon, Swift, Go, and even the newer language releases of C++ is trying to kill off old C++.

A lot of entities are looking around the room and asking themselves "how do we deal of this C++ thing" and then deciding to commit to the seriously non-trivial endeavor of creating a new language from scratch.

Eventually, C++ will be relegated to a historical footnote and niche application. Although, I'm not going to be surprised if this takes another 50 years and half a dozen new languages on top of what we're already seeing.

As C++ fan, that used to teach it as TA, spent time at CERN doing HPC in C++, I would assert C++ has gone beyond PL/I complexity level.

And just like 50 years ago with PL/I dialects, a reboot will eventually happen.

I expect C++26 to be the last relevant ISO C++ revision, for the use cases where C++ would still be the main supported language, like existing infrastructure.

I don't forsee post C++26 revisions to ever gain major industry relevance.

One issue with all wannabe replacements, is that C++ will never go away as long those replacements aren't bootstrapped, relying on GCC or LLVM for their toolchains.

IMO, unless you have really serious reasons, it would be silly to turn "a decade of hard work" into two decades of hard work. With an even lower chance of your new language getting traction.

Nothing prevents you from launching a working language first and then replacing the backend later. That's what Zig folks are working on at the moment. And nightly Rust recently got experimental support for Cranelift backend.

Compiler frontends don't start out self-hosted either, anyway. Because it's literally impossible. The first implementation has to use something else that already exists

Fully agree, and is a complex matter, as apparently LLVM has Linux kernel level of contributions, not only due to companies, but also PhD/Masters being done on it.

And as such C++ will stay around for a long time, even if everything else on top would be another language.

> It forces an understanding of fundamentals.

I don't have a dog in this fight as I haven't learned Rust. This statement, though, came off as ridiculous.

I've worked as a C++ developer. Most of my peers didn't understand the "fundamentals". They didn't know a map was implemented as a binary tree, for example. They didn't understand struct packing. The list goes on an on.

C++ allows for quite a bit of abstraction letting people be quite productive without understanding much about the machine. People look up the API in the standard library and they just use it like they would any other language.

That was, after all, one of the selling points of C++ over C.

If that quote from the article was supposed to be comparing C++ positively to rust, honestly it comes off as pretty condescending to me, too.

Just because Rust has some safety rails built into it, that doesn't mean it hides the nature of what's going on underneath from you, any more than using a static analyzer on C++ would. Rust isn't any higher level than C++, and you still need to deal with all of the same requirements and underlying concepts and semantics in writing safe code in Rust as C++, it just forces them explicitly ahead of time and does so in an extremely clear manner, whereas C++ "enforces" them at runtime as they arise and in an extremely opaque manner. That's basically the only difference, and in fact, because Rust explicitly and clearly forces you to contend with the concepts of single ownership and proper RAII and when to use which pointer type and the basic practices of avoiding data races and memory safety violations from the get-go in a way that C++ does not, if anything Rust forces you to learn to do everything correctly and grok all the concepts behind it up front far more rigorously than C++ ever would, since in C++ you can kind of skirt by ignoring all of it.

And as a testament to this, I have found in casually branching out and reading up on C++ (despite how much of a fan of Rust I am, and the fact that I think Rust is genuinely the future and should probably eventually take over C++'s position for any new projects, I really think that C++ is a very cool language, with some absolutely killer features, and I can absolutely see why those who enjoy programming in it do so, and I actually think I would enjoy programming in it too) that my experience with Rust and Rust's concepts actually makes C++ infinitely easier to understand, because the underlying concepts and implementation of everything is pretty damn similar, which I think should indicate that Rust does in fact encourage you to learn the underlying concepts of things. I've also found that knowing Rust makes my C code infinitely better, because I've got a borrow checker in my head now.

> I've worked as a C++ developer. Most of my peers didn't understand the "fundamentals". They didn't know a map was implemented as a binary tree, for example. They didn't understand struct packing. The list goes on an on.

And even if you do know the fundamentals, for a vast majority of programming, you don't need to care.

How often does the average programmer need to care about the underlying mechanism a map? How often do they need to care about struct alignment? Etc.

> C++ allows for quite a bit of abstraction letting people be quite productive without understanding much about the machine. People look up the API in the standard library and they just use it like they would any other language.

Rust similarly does... it just yells about the specifics of the abstractions.

> How often does the average programmer need to care about the underlying mechanism a map? How often do they need to care about struct alignment? Etc.

It is important to know the big O performance of an underlying data structure if it is being used for a non-trivial number of elements.

And struct alignment I've had to worry about many times in my career, especially when passing structs between platforms or languages.

So for most of my career, these have been important issues.

(Though I'll admit between starting my career in compilers and then doing embedded, the first half of my career was fairly biased towards the low level details!)

> So for most of my career, these have been important issues.

I appreciate what you're saying, but your career is an outlier. The VAST majority of programmers/software engineers are gainfully employed without knowing any of these things.

> How often does the average programmer need to care about the underlying mechanism a map?

I think it's useful to know it's not an O(1) lookup as many programmers seem to assume. Definitely useful to know it is ordered.

Also, I once ran out of RAM (over 80GB), because of all the extra pointers needed in a tree. I switched to a sorted array and used a binary search instead - got the same performance, without running out of RAM.

Author mentioned about high-frequency trading tools and machine learning.

Don't know about machine learning, but a HF C++ developer usually has solid fundamentals. I tend to believe that naïve C++ programmers aren't in those areas.

I must have a different idea of what "fundamentals" are, because map being implemented as a binary tree isn't a fundamental, but simply an implementation detail.

When I think of the fundamentals, I think of the lower-level stuff like pointers, memory management (malloc/free/new/delete), and avoiding buffer overflows.

> Most of my peers didn't understand the "fundamentals". They didn't know a map was implemented as a binary tree, for example.

I mean, I don't use c++ much, but... the "fundamentals" are that an unordered map is probably implemented as a hash table, and an ordered map could be implemented on a trie, a vector, a linked list, some other thing I can't think of right now, or... some variety of a binary tree. Right? I don't think I would want to assume.

> and an ordered map could be implemented on a trie, a vector, a linked list, some other thing I can't think of right now, or... some variety of a binary tree. Right? I don't think I would want to assume.

You're correct in that one shouldn't assume a red-black tree. However, the standard does dictate O(...) performance for the map, which strongly suggests an underlying structure.

And as I point out in another comment: Knowing that it was indeed a tree helped me debug an issue where I ran out of RAM.

In any case, you're point strengthens mine: That you don't need to know "fundamentals" to program in C++.

The article puts several arguments forth, but it misses what Rust's tagline is: "Empowering everyone to build reliable and efficient software. ". Yes, the C++ talent pool is currently bigger than the Rust talent pool, but the latter is rapidly growing, because it is a friendlier language. Yes, a newcomer to programming won't know enough low level details to create the most efficient software, but that applies equally to C++ and Rust. But a Rust novice has a much better chance of writing a performant piece of software that doesn't blow up in production than a C++ novice.

> This causes them to write off C++ which I think is a huge mistake because it’s actually one of the best languages for new developers to learn.

I might be missing something, but I don't see any argument in the article that supports this claim. It only mentions that C++ is well-paid.

> Most applications that use C++ are latency and efficiency critical.

I'll take the under on this. There are plenty of C++ applications that are "latency and efficiency critical" but I'd guess it's well under 50% of all the C++ software out there.

Java, and even python are used in HFT, along with many other languages. Depending on the task they can work well or poorly.

C++ has a good position in this space though because often you come down to a if(something){doTrade();} and java's optimizer has figured out that this if is normally false and so you pay a CPU branch missprediction penalty, while C++ had optimized for the true case and so when it matters is faster.

No matter what the language used, HFT has some different programming styles vs normal.

> while C++ had optimized for the true case

Which is why we have Profile Guided Optimization.

When we started our current system 15 years ago (Rust wasn't an option) 5% of the code needed C++, so everything was written in C++ as there is too much friction trying to make with a different language.

I'm sure there was something other than C++ that would have worked just as well. I don't know what it would be, but there are many options. Even then the article makes a good point: we can hire C++ developers, could we hire someone who knows the other option?

> There are plenty of C++ applications that are "latency and efficiency critical" but I'd guess it's well under 50% of all the C++ software out there.

Easily well under 5%, and I'll assert it's under 1%.

1 - Because for most organization/project, there are constraints with higher priority than the intrinsic qualities of the programming languages.

The authors mentions specialized talent pool. I think that's a good point, but from my experience, someone capable of writing performance oriented code in C++ should be able to do the same in rust with minimal training time since the execution and memory models are close enough. In this case, i think the ecosystem of libraries and pre existing code would be the main reason to stick with C++.

2 - C++ is evolving pretty fast

Much as LLVM/Clang pushed GCC to be a better compiler. I think the pressure from newer languages like rust in having a positive effect on the C++ ecosystem. Especially in term of tooling, syntax and general dev productivity (c++ modules ). Still not at the level of cargo as such, but things are improving.

Good for C++, but it also means that as time passes, there are less and less reason to switch to a completely different language and ecosystem.

The jury is still out on the "safety" part of C++ and how much safer C++ can get and how would that compare to what rust is providing right now.

My bet is that rust will always be preferred for environment where safety the number one concern.

Well, and almost no company or open source project is going to spend years rewriting their giant C++ code-base in Rust. And many people leading such C++ projects won't bother gaining expertise in Rust or care about hiring people who know Rust. New code at these companies will continue to be C++. And not all developers consider Rust to be superior to C++.

Don't underestimate good old fashioned inertia, in other words.

Even if you want to, it is hard to see how to make one line of Rust fit into all those millions of lines of C++.

And of course since all I know is C++ on the rare times where I have code that doesn't need to fit into all the existing C++ - I still know C++ well while I'm sure any Rust I write will have a lot of beginners mistakes.

> it is hard to see how to make one line of Rust fit into all those millions of lines of C++

Good point. If Carbon/Cpp2front/etc ever get off the ground, they could supercede any C++-to-Rust transition if they can easily integrate with existing code.

The author's circular argument is correct. C++ had long noted this - which is why they are unwilling to break ABI despite many improvements that would be possible if they would. They know that a stable language is one of their largest selling points. (see phython 3, perl 6).

I agree this isn't much to add, but many people fail to realize this argument and so it is important.

I think this is a very important point. The most reliable indicator of how long a language will be around is not growth or buzz, but how long it has been around.

To put things into perspective, despite all its growth and popularity, Rust hasn't even overtaken PHP yet.

Also known as the Lindy Effect https://en.wikipedia.org/wiki/Lindy_effect

Something that will surely play a role in the continuation of C++ as a key mainstream language is the degree to which is can selectively adopt features that made newer languages more attractive. Its not so much about deep design features or any of the (ultimately subjective) preferences for programming paradigms, but more the usability and convenience of developing good stuff, both as individuals and in teams, small and large.

If you think about the diverse domains where C++ has deep roots, from games development (check out Godot) to live coding (check out Supercollider) to scientific computing (vast universe, check out CERN's ROOT) and everything in-between (including machine learning and finance mentioned in the post), this particular "game" is really for C++ to lose.

It may eventually fade (one of the factors is that C++ users and communities are extremely dispersed, there are few visible champions). But it won't be a quick thing.

Old building decay over time. A lot of COBOL still runs fine decades later.

Anyone involved in a major refactor knows it is a minefield. It should only be done as part of a strategic upgrade, not because Rust is "better" than C++.

“No return on investment” is not the same as “not worth it”. There is benefit in Rust over C/C++ in plenty of use cases. There is still a daily background noise of software security issues caused by poor memory safety practices. The solution to this is not to keep pretending that humans will somehow get better at writing C code. They won’t. It’d also be lovely to reduce the circ*mstances in which we all have to deal with the utterly arcane build tooling that comes along with a typical C/C++ codebase.

Reasonable people could disagree about whether or not a migration of a particular codebase is worth it. A general / absolute argument in either direction is not reasonable. And this whole thing is muddied by the fact that there’s CERTAINLY a material contingent of, frankly, incredibly delusional C/C++ developers that can’t stand the mere thought of change, nor the implication that these languages may not be perfect. Some even wearing the inscrutable nature of their tools of choice as a point of intellectual pride.

Just go tell your CEO you are going to rewrite all the C++ at your company into Rust, taking months of Engineering effort, and deliver the exact same functionality at the end of it.

A refactor needs to be part of a strategic initiative. If security is paramount to an organisation, a refactor to Rust can be worth it. Doing new projects in Rust can also be a valid decision.

> or Rust isn’t as capable as C++ (also untrue for the vast majority of applications)

I wonder what are the applications for which that statement is true. So far I've found nothing apart from obscure/proprietary architectures for which Rust doesn't have a compiler (and that's not a problem of the language itself)

I'm the author and I've been trying to respond to everyone but Hacker News won't let me comment fast enough. Thanks everyone for taking the time to read my article and respond!

Your criticisms are greatly appreciated. This article came from having read a lot of posts online saying developers shouldn't learn C++ because Rust is killing it anyway. A lot of developers (new developers, especially) seem to take that statement to heart which I think is a mistake. I'm definitely not trying to take away from Rust because it's a great language (maybe even better than C++), but there's more to choosing a language than just which is better (unfortunately) and that's the point I was trying to get across.

It may be true in the literal sense that "the developer talent pool for C++ is much larger than Rust" in that there are more C++ developers than Rust developers, but if I can plug my own research a bit: at least for open source projects, rewriting in Rust seems to increase the number of contributors, across all experience levels.

https://cypherpunks.ca/~iang/pubs/gradingcurve-secdev23.pdf

This isn’t the first time I read that C++ is great as a foundational language. I think there was a StackOverflow blog post about it just recently also.

Any self-taught C++ dev here that can talk about their journey? How did you learn (books or courses), and how much did it help you later on when learning new languages?

They taught us a couple weeks worth of C++ in college, but this was way back in the early 1990's. So I started my career as a C developer, gradually learning how/why to use C++ as better tools and libraries evolved.

Various DOS-era libraries for UI, database, and communication encouraged me to use C++ more. And then learning Windows programming (MFC) also very much got me into C++.

I eventually jumped to C#, which was probably made much easier by being comfy with C++ first.

I started about 10 years ago with modding games. C++ is what everyone used (and mostly still uses) to write mods/cheats, dll injections, and so on. There were some shared online that I used as reference to learn how it was done. Looking up everything I didn't understand, reading hundreds of forum posts, blogs and stackoverflow. Modifying it to do silly things.

It's a really steep difficulty curve to start like this, but it'll immediately force you to understand all the low level fundamentals if you want to accomplish anything. You can't make a functioning mod if you don't understand the memory model of the game and engine you're messing with, or what your code is actually doing. So you build a really strong foundation by force, and everything after comes naturally.

Now I work at a AAA game studio and it's really fun to be able to easily make large changes to the engine as needed. Sometimes you have to write complicated generic code, and sometimes you get to write really fast and simple code. You always understand what happens behind the scenes, how the computer will represent your data and how it processes it. How different threads interact when accessing shared data. There's not really anything that can't be figured out.

Somehow I never cared for any courses or books. They all want you to make boring things, and that's the best way to get disinterested and give up. Wanting to get a particular thing to work can be incredible motivation to keep digging at it for weeks and learn large amounts of trivia along the way.

I think my suggestion would be don't try to learn C++. Find something you actually want to do (maybe you want to make a game?) and use C++ to do that. At least that's what worked for me.

Also, this meme is very much true. Try to stay clear of "modern c++" template over engineering. There's a reason why no game studio uses the STL. https://twitter.com/nice_byte/status/1466940940229046273

The thing is: C++ ain't a language. It's two, if not three languages mashed together. You start with the C preprocessor, then you have the template language and only then you find classes, objects, pointers, etc.

That's like learning Rust but having to learn POSIX sh, and some badly documented Haskell dialect on top of it just to get going.

Seriously, take this picture[1] label the Dinoco car "C++", Rust-eze "Rust", and Hostile Takeover Bank "Go". Done!

[1] https://image.jimcdn.com/app/cms/image/transf/none/path/s90b...

Prediction: in five years or so, gcc shall have gained some extensions which, combined with some ludicrous boost.org template gymnastics, manage to duplicate Rust's borrow checker.

C++ will then kick back, light up a cigarette, take a long drag, exhale a cloud, and wonder aloud what the next "killer feature" will be.

Good luck making all your teammates use these boost templates and use them correctly. And debugging these layers of templates.

A classic from the old Rust FAQ:

>> I already write perfect C++. What does Rust give me?

> Modern C++ includes many features that make writing safe and correct code less error-prone, but it’s not perfect, and it’s still easy to introduce unsafety. This is something the C++ core developers are working to overcome, but C++ is limited by a long history that predates a lot of the ideas they are now trying to implement.

> Rust was designed from day one to be a safe systems programming language, which means it’s not limited by historic design decisions that make getting safety right in C++ so complicated. In C++, safety is achieved by careful personal discipline, and is very easy to get wrong. In Rust, safety is the default. It gives you the ability to work in a team that includes people less perfect than you are, without having to spend your time double-checking their code for safety bugs.