[taylodl]

I remember when Stroustrup's C++ came out in 1986. I used to be able to cite the Annotated Reference Manual (ARM) by chapter and verse. But if I were a young programmer in 2022 and looking at learning either C++ or Rust I'd choose Rust in a heartbeat.

Why?

Many reasons. For starters, C++ is 40 years old at this point and embodies software engineering practices from the late 70's to early 80's (for you young folks, structured programming was the new hotness in the 70's!) C++ was also designed to take advantage of C's tooling, or lack thereof. C had incredibly simplistic dependency management. It worked well for the time since there were very few external dependencies, almost the entirety of the codebase was hand-built by the entity creating the software. There were very few libraries outside of the standard libraries.

C++ has an object model making it difficult to use and extend objects from different code bases/libraries. Never mind the inheritance patterns leading to lots of confusion. Just remember, Java and later C# were created to address these issues with C++. They were both touted to be better versions of C++ (which was true in the application development space where a GC could be tolerated)

Finally, the C++ type system is barely a type system as we understand them today. That's just history - C++ reflects our best thinking from the 70's and the modern type systems started emerging in the 80's. The simplicity makes some things unduly burdensome to implement.

Don't get me wrong - I've programmed in C++ for decades and I like it, warts and all. But I'm also practical and I recognize its days are numbered. Will C++ be around in 20-30 years? Absolutely! But so is Cobol, and would you start a major project today using Cobol? No. You can see we're shifting from C++ to Rust. C++ is the past and the lion's share of the present but Rust is gaining on the present and is the future. If I did't know either Rust or C++ in 2022 then I would focus my efforts on learning Rust.

[synicalx]

> would you start a major project today using Cobol? No.

You might not start a project in it, but goddamn I bet you could make a boatload of cash doing consulting work to keep ancient COBOL systems running. Even today that's pretty lucrative business if you have the skills and connections.

[cogman10]

Honestly, I think the shift you are already seeing is from C++ -> a GCed language (python, javascript, java).

While C/C++ are everywhere, they are mostly in very low level places. You don't find a lot of new backend projects that go the C++ route.

Rust will likely eat up a significant chunk of C++'s current market share and SOME of the backend service market share (where CPU and Memory are REALLY important). However, I don't find it terribly likely that it will grow much beyond that.

As for the Cobol analogy, a good one, but you have to also realize there are about 1,000,000x more lines of C++ in the wild than Cobol. For cobol to die takes some institutional investment that most companies are not willing to burn. C++ will have a MUCH harder time being purged.

[klysm]

If I was in a situation where c++ made sense for a greenfield project, rust would almost certainly be a better choice.

[pjmlp]

Except not having the libraries, IDE tooling and graphical debuggers that make C++ still relevant.

[klysm]

I agree those are downsides. But I think memory safety matters more in the problem space where c++ is relevant. I understand that's debatable, but I think the historical evidence suggests that it is impossible to write memory-safe c++ code beyond a fairly low complexity threshold.

[pjmlp]

Indeed, however memory-safe c++ isn't on the top list of what makes GPGPU, HPC/HFT, LLVM/GCC relevant in the industry, as such, those ecosystems won't be jumping into Rust anytime soon.

Some recent examples, Apple recently added support for using Metal from C++ instead of Swift secure bindings, Android now supports Rust at the OEM layer, no roadmap for NDK/AGK support for anything beyond C and C++, Azure Sphere is "secure" yet SDK is all about C and C++ (no Rust plans), Khronos API ecosystem is all about C and C++, CUDA,....

[klysm]

Agreed the spaces you’ve enumerated make sense for c/c++ still because trading off memory safety is a sensible engineering decision given the current state of things. Unfortunately security vulns can still sneak in there though :/

[flohofwoe]

> You don't find a lot of new backend projects that go the C++ route.

TBF, C++ was never a great backend language. Rust "the language" isn't either, but "Rust the package ecosystem" might be one day (because unlike C++, Rust is coming out of the "web hemisphere").