6 ms·

Why Rust Isn't Killing C++

28 points by klelatti 2y ago

tga_d 2y ago
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 https://cypherpunks.ca/~iang/pubs/gradingcurve-secdev23.pdf
smitty1e 2y ago
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.
- Expurple 2y ago
  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.
  - smitty1e 2y ago
    There is no luck; there is only Freewill interacting with the Borrow Checker of Destiny.
loganthorneloe 2y ago
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.
- ladyanita22 2y ago
  For which applications would you say Rust isn't as capable as C++?
ladyanita22 2y ago
> 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)
deleted 2y ago
[deleted]
BeetleB 2y ago
> 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.
- Sohcahtoa82 2y ago
  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.
  - loganthorneloe 2y ago
    This is what I was getting at.
- andersa 2y ago
  It doesn't force it, but it is much more fun to use once you understand the fundamentals, since you can still write code where it makes a difference.
  - BeetleB 2y ago
    So ... the same as Rust, then?
- John23832 2y ago
  > 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.
earthboundkid 2y ago
Why would you label the Rust-eze car "C++"?
- loganthorneloe 2y ago
  I really missed an opportunity here
- earthboundkid 2y ago
  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/s90bacc9cde9c3af4/image/i76fe644c9b6b0e36/version/1484775672/image.jpg https://image.jimcdn.com/app/cms/image/transf/none/path/s90b...
khuey 2y ago
> 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.
- BeetleB 2y ago
  > 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%.
  - khuey 2y ago
    Yeah I'd agree.
- ghshephard 2y ago
  Not to mention that the demonstration I've seen of a sub microsecond trading platform was written in Java. and talking to my manager who used to be a developer in high-frequency trading - he tells me that's a pretty common language in that space. Which, I'll be honest, kind of blew my mind.
  - thefaux 2y ago
    Yes, it is surprising initially but I can imagine that hft java coding conventions are very different from enterprise java.
  - bluGill 2y ago
    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.
arpyzo 2y ago
The gist of this blog post seems to simply be that C++ has a lot of momentum.
- marginalia_nu 2y ago
  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.
  - vaylian 2y ago
    Also known as the Lindy Effect https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
choeger 2y ago
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.
skilled 2y ago
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?
- cqqxo4zV46cp 2y ago
  Make take this as an indication that it’s not a great fundemental language.
- glonq 2y ago
  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.
- andersa 2y ago
  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 https://twitter.com/nice_byte/status/1466940940229046273
oxfordmale 2y ago
There is simply no good economical reasons to rewrite the worlds C++ codebase in Rust. It might be more elegant, but there is no return on investment.
- threatofrain 2y ago
  In the same sense that developing slightly better buildings shouldn't mean tearing down old ones.
  - oxfordmale 2y ago
    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++.
    - threatofrain 2y ago
      Old doesn't mean unmaintained, old buildings have run longer than COBOL has existed. Tearing down an old building just because a new building is objectively better can still be seen as a shameful waste, and although I don't know much about construction, I'm sure tearing down and rebuilding is also a minefield.
- cqqxo4zV46cp 2y ago
  “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 circumstances 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.
rootedbox 2y ago
Most of the safety nets in rust were in pascal(some may say done better in pascal). The fastest most efficient compilers in the early 2000s were pascal compilers (RIP Borland). but here we are.. no pascal and c++ everywhere.
- pjmlp 2y ago
  And just to confirm C++ isn't going away in our lifetimes, C++ Builder and Delphi had new releases last month.
serjester 2y ago
This seems like a circular argument? Why is rust not killing C++? Because it's not as prevalent. I'm not sure the author added anything insightful to the conversation.
- bluGill 2y ago
  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.
natsucks 2y ago
this is like saying "C++ won't die soon for legacy reasons"
Verdex 2y ago
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.
- loganthorneloe 2y ago
  This is an excellent take.
- JohnFen 2y ago
  I agree with this. C++ has become an unwieldy monster of a language by trying to be all things to all people. I've been programming in C++ from before C++ compilers even existed, and it has been my favorite language since then. Up until a number of years ago, anyway, when its bloat and layers of hackiness started becoming a legitimate problem.
- pjmlp 2y ago
  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.
gary_0 2y ago
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.
- bluGill 2y ago
  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.
  - gary_0 2y ago
    > 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.
soulbadguy 2y ago
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.
openrisk 2y ago
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.
vaylian 2y ago
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.
- loganthorneloe 2y ago
  Author here. These are great points and I agree with them all. Money is one of the reasons but I've found C++ to be great at forcing proper coding practices and understanding of concepts. That's not to say other languages don't, though.

28 points by klelatti 2y ago

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 https://cypherpunks.ca/~iang/pubs/gradingcurve-secdev23.pdf

smitty1e 2y ago

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.

Expurple 2y ago
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.
- smitty1e 2y ago
  There is no luck; there is only Freewill interacting with the Borrow Checker of Destiny.

loganthorneloe 2y ago

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.

ladyanita22 2y ago
For which applications would you say Rust isn't as capable as C++?

ladyanita22 2y ago

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

deleted 2y ago

[deleted]

BeetleB 2y ago

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

Sohcahtoa82 2y ago
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.
- loganthorneloe 2y ago
  This is what I was getting at.
andersa 2y ago
It doesn't force it, but it is much more fun to use once you understand the fundamentals, since you can still write code where it makes a difference.
- BeetleB 2y ago
  So ... the same as Rust, then?
John23832 2y ago
> 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.

earthboundkid 2y ago

Why would you label the Rust-eze car "C++"?

loganthorneloe 2y ago
I really missed an opportunity here
earthboundkid 2y ago
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/s90bacc9cde9c3af4/image/i76fe644c9b6b0e36/version/1484775672/image.jpg https://image.jimcdn.com/app/cms/image/transf/none/path/s90b...

khuey 2y ago

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

BeetleB 2y ago
> 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%.
- khuey 2y ago
  Yeah I'd agree.
ghshephard 2y ago
Not to mention that the demonstration I've seen of a sub microsecond trading platform was written in Java. and talking to my manager who used to be a developer in high-frequency trading - he tells me that's a pretty common language in that space. Which, I'll be honest, kind of blew my mind.
- thefaux 2y ago
  Yes, it is surprising initially but I can imagine that hft java coding conventions are very different from enterprise java.
- bluGill 2y ago
  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.

arpyzo 2y ago

The gist of this blog post seems to simply be that C++ has a lot of momentum.

marginalia_nu 2y ago
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.
- vaylian 2y ago
  Also known as the Lindy Effect https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect

choeger 2y ago

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.

skilled 2y ago

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?

cqqxo4zV46cp 2y ago
Make take this as an indication that it’s not a great fundemental language.
glonq 2y ago
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.
andersa 2y ago
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 https://twitter.com/nice_byte/status/1466940940229046273

oxfordmale 2y ago

There is simply no good economical reasons to rewrite the worlds C++ codebase in Rust. It might be more elegant, but there is no return on investment.

threatofrain 2y ago
In the same sense that developing slightly better buildings shouldn't mean tearing down old ones.
- oxfordmale 2y ago
  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++.
  - threatofrain 2y ago
    Old doesn't mean unmaintained, old buildings have run longer than COBOL has existed. Tearing down an old building just because a new building is objectively better can still be seen as a shameful waste, and although I don't know much about construction, I'm sure tearing down and rebuilding is also a minefield.
cqqxo4zV46cp 2y ago
“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 circumstances 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.

rootedbox 2y ago

Most of the safety nets in rust were in pascal(some may say done better in pascal). The fastest most efficient compilers in the early 2000s were pascal compilers (RIP Borland). but here we are.. no pascal and c++ everywhere.

pjmlp 2y ago
And just to confirm C++ isn't going away in our lifetimes, C++ Builder and Delphi had new releases last month.

serjester 2y ago

This seems like a circular argument? Why is rust not killing C++? Because it's not as prevalent. I'm not sure the author added anything insightful to the conversation.

bluGill 2y ago
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.

natsucks 2y ago

this is like saying "C++ won't die soon for legacy reasons"

Verdex 2y ago

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.

loganthorneloe 2y ago
This is an excellent take.
JohnFen 2y ago
I agree with this. C++ has become an unwieldy monster of a language by trying to be all things to all people. I've been programming in C++ from before C++ compilers even existed, and it has been my favorite language since then. Up until a number of years ago, anyway, when its bloat and layers of hackiness started becoming a legitimate problem.
pjmlp 2y ago
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.

gary_0 2y ago

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.

bluGill 2y ago
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.
- gary_0 2y ago
  > 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.

soulbadguy 2y ago

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.

openrisk 2y ago

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.

vaylian 2y ago

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.

loganthorneloe 2y ago
Author here. These are great points and I agree with them all. Money is one of the reasons but I've found C++ to be great at forcing proper coding practices and understanding of concepts. That's not to say other languages don't, though.