But the major players do seem to be happy to replace their C++ code with Rust.
Perhaps it's time to ease up on the backwards compatibility. Especially in the era of AI.
Alas, C++ still mostly does its libraries via conceptual copy-and-paste (#include). So that would need to be fixed, if you wanted to mix-and-match dialects. You could probably keep '#include' syntax, but subtly change its meaning.
also at the time this is what HN wrote about it: https://news.ycombinator.com/item?id=42231489
I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-too-late ranges library. C++26 is also a joke imho. But on the other hand, working with std::optional and (in C++23) std::expected is so much better than without. The thing is nobody forces you to use every single feature of a new standard, but I would not recommend ignoring very good tools just for the sake of it.
PS: it's funny I wrote my comment three days (and not an hour) ago.
Not much has changed, though, it still is. Just with a lot more bells and whistles around it
C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.
Why would anyone expect big broad changes? And historically, whenever they did happen anyway through forced compromise, they resulted in failure because they were not consistently implemented.
The only way that works is small compatible and iterative changes.
If you've worked on technical problems with an IETF Working Group you'll know what actual consensus looks like. If you've been around a while you might even have seen abuse of process used to dodge rules and seen demonstrated before you why we need consensus anyway. ISO's procedures are probably adequate for its original goals but they're completely inappropriate for designing a programming language. SC22 should never have existed and is entirely the wrong place to do this work.
Refactoring working, terrain-tested code?!?
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
The issue with Netscape (per that article) was that it was a rewrite, not a refactor. I.e. replacing all the existing code with new code. That's why it took a long time to release a new version: the previous code hadn't changed and the new code wasn't functionally equivalent to the existing code, let alone have any new features.
actually it is very explicitly pushing to refactor and rejuvenate the working field tested code, instead of green field rewriting it.
elsewhere he goes on to what's needed for that, also see the great both entertaining and informative fosdem talks about rejuvenating LibreOffice
Even in those domains there are efforts to do things in Rust, although it's unclear when Rust is going to be an actually serious/viable option.
I suspect C++ will become less of a "mainstream" language but only relevant in those specific domains. OS / Services will consider alternatives first.
Past discussion (653 comments): https://news.ycombinator.com/item?id=42231489
Did they decide to keep things as is or rewrite in Rust with LLM assistance in the couple years since this article? Carbon seems to have gone nowhere.
Most programming languages "go nowhere" in the sense that they never end up used for lots of real world projects - but they can have interesting and useful ideas which inspire future languages.
Google writes a tremendous amount of new code. You can reap a large portion of the benefits by using Rust for new code.
At least as far as public info goes it's still being worked on. The GitHub repo [0] has pretty consistent activity and some recent-ish talks [1], one of which says that they are considering a 0.1 release "early next year".
an active project indeed!
The other major problem for C++ is that correct C++ basically looks like nonsense, because the committee insists on pushing dangerous footguns that nobody sane would ever use in normal codebases through yet takes their sweet time with adding basic functionalities like pattern matching or even "print", which is somehow finally added in C++23. Worse still, nothing is ever really allowed to be removed/deprecated from C++, so you have decades of accumulated syntax debt that nobody is allowed to actually fix.
I think the biggest issue with C++ is that despite the fact that 90% of the language just should not be used in any normal code, period, there really is nothing that can replace C++ in its niche of high performance, low-level systems level programming. There is a good language buried underneath C++ somewhere, it's just that nobody has taken the time to extract it.
Well.. "C".. though I wouldn't go so far as to call that a good language, either.
Carbon?
Just to give you a small example? why would a C++ successor language use `fn main()` instead of using C/C++ style `int main()`? And their generics system is even more confusing, are they going to support a new form of generics or are they sticking with templates? And if they are going to add templates, why would they not add pretty much one of the best additions to modern C++ to Carbon, concepts?