Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


This is an excellent take.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: