Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- This is why I'm building Quxlang.
C++ cannot evolve easily without breaking backwards compatibility.
I started Quxlang because I saw the writing on the wall for C++. Doesn't mean C++ isn't good, but it has issues and needs improvement.
Somehow I managed to implement working modules, C++ doesn't seem to have that yet, although the C++ build system is horribly broken.
We'll have to see how it compares when it's more complete and ready to use. I don't have oop/inheritance yet which is also important for a C++ alternative.
by rpnx - Previous HN discussion here (https://news.ycombinator.com/item?id=42231489); 2024-11-24, 554 points, 653 commentsby aw1621107
- > it’s at least a bitter awareness of the fact that the industry doesn’t care to refactor existing code
Refactoring working, terrain-tested code?!?
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
by pif - wait. that's about the green field rewrite of Netscape. not about refactoring where needed.
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
by froh - You can incrementally refactor existing code to make it more maintainable and easier to implement the things you are working on.
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.
by rhdunn - There is a natural tendency for all programming languages to want to both retain backwards compatibility and also accumulate new features, eventually outgrowing the original design. C++ is obviously well past this point.
If this was a code base rather than a language specification, then this would be the time to refactor, but with a programming language you've got a world full of code, compilers and tools, and the resistance to change is massive.
One of the few success stories of a language refactoring and dropping backwards compatibility is Python 2 -> Python 3 (a 10+ year struggle). What might be considered as a failure case is Perl 5 -> Perl 6, where resistance to change caused the migration to Perl 6 to be so slow that effectively Perl 5 won, and the language itself became obsolete.
So, be careful for what you wish for - C++ certainly needs a refactoring, but whether it could survive it is another question, especially now since backwards compatibility is what is keeping it alive in the face of competition, and it's not at all clear going forwards what the impact of AI on programming languages is going to be.
- Very interesting summary of facts and quotations with conclusions. I would say there are even more camps than the two mentioned. Personally I think C++98 and Qt5 just worked and were good enough for all purposes, and C++ since has become an ever moving target with a lot of incompatibilities between compilers. Chasing for the ever latest version of the language and compilers is very expensive and enervating. I prefer how they solved this e.g. in the Ada community; they take their time for the release a new standard version, and until then, most compiler vendors have already updated their products and there was relevant experience with the new features long before the new standard was passed. In computer science, it seems to be a law of nature to keep "improving" good things until they become unusable and people walk away. In C++ I did so; I have a few C++11 code bases (some back ported from newer versions), but most are C++98/03; I even made a fork of Qt5 (LeanQt) with my own build system (BUSY) which is less work to maintain than continuously chasing new compiler/tool incompatibilities among platforms.by Rochus
- I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership.
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.
by gignico - Try building google opensource projects. They'll be mostly broken on your own toolchain.by feverzsj
- > Google supposedly significantly lowered its participation in the C++ development process, and instead started to work on their own C++ successor language.
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.
- Worth noting, Carbon is just an experimental language, I see no evidence it's being used widely or replacing C++.by rpnx
- Go is good enough for many tasks. Google wrote that as a replacement for C++ too. I guess Carbon is intended to be more for systems programming? Go had that intent initially, but soon realized that's not a good fit.by seethishat
- > Carbon seems to have gone nowhere.
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".
by aw1621107 - Successor languages usually take a long time. Some of them are made by people who are bad at estimates and will grandly tell you that next year they will have finished the language, but that's just because they actually have no idea. In reality it's typically ballpark ten years.
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.
by tialaramex - It's a committee, many people are involved, all with different opinions, but any decision requires consensus.
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.
by mgaunard - A big problem is that "consensus" for WG21 is actually just "Did the chair of your sub-sub-committee say there was consensus?" and is typically measured by voting. That's not a consensus, it's a majority.
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.
by tialaramex - I was deeply saddened by the vote the article refers to that effectively excluded Sean Baxter's Safe C++. It felt like a push that prevented tabling the solution at all. If Safe C++ had been debated on its merits, that would be one thing, but this seemed (to me) to prevent ever getting to that point. Who knows if that was the intent: the result is what disappointed me.
In my view, one of the major compiler vendors needs to take on Safe C++ and start supporting it... with refactoring tooling to get a codebase there. Because as this article says, tooling is key.
by vintagedave - To be fair to the committee, upgrading C++ compilers is already a chore, even with the changes as small as they are. Would you rather spend time updating your lambdas because they changed how capture works (a real breakage not long ago), or doing something of actual value? The only reason we finally updated from Python 2.7 to 3 was that the OS vendors dropped it, but it was effectively a waste of time.
That aside, I don’t understand why ABI breakage is a big deal. There’s probably a good reason, but ABIs are already so fragile, you can’t mix and match different compiler versions anyway, or even the same compiler with different flags. Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same?
The C++ committee should really stop adding esoteric features for library writers and focus on stuff for normies. Tooling is one as the article says, or how about finally getting Networking TS? This is probably the only mainstream language left that doesn’t have even basic networking support.
by abbefaria27 - The application I work on has an extension API that only requires C++11, but we compile against all the same headers in C++20.
Obviously we need ABI compatibility between the two standards for this to work.
by neutronicus - > Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same?
I think it's the distinction between can and must. Right now you can preserve ABI across compiler versions if you want to (and that is indeed a desirable quality for some users). The pushback is against changes to the standard that would require an ABI break.
by aw1621107 - Should have a (2024) annotation so far as I can see (haven't finished reading the article but it seems to be about events which have "just happened" back then)
also at the time this is what HN wrote about it: https://news.ycombinator.com/item?id=42231489
by tialaramex - Thanks! Macroexpanded:
The two factions of C++ - https://news.ycombinator.com/item?id=42231489 - Nov 2024 (653 comments)
by dang - >“We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.”
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.
- They seem willing to gradually replace C++ with Rust, but that actually does require C++ to not change in backward incompatible ways. They're depending on a stable ABI when calling into Rust.by nitwit005
- Haskell has a pretty good story about how to use different dialects in the front end of the language, as long as the backend is still the same. Well, when I say Haskell, I mean ghc.
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.
by eru - Don’t believe everything you read. Any communication from them is a PR exercise.
On the other hand, I read an interesting substack blog from an ex-Azure employee the other day: the Russinovich-dictated Rust rewrite was allegedly vaporware for a long time and caused lots of headaches that were not widely known. A highlight for me was the use of over 1000 third party crates in their products.
Would be interesting to know how it’s going nowadays.
As any company, the one I work for also has its decent share of rustafarians. The Rust penetration is modest and slow, but the PR is remarkable.
by blub - Replace C++ code with Rust is happening at a glacial pace, basically involving full rewrites of the module replaced and significant work to refactor the surrounding code to support it.
(This is why Rust is focusing heavily on interop right now, if it is easier to integrate more projects can use it)
The problem is updating a decently sized program from one version of a compiler to another can take man months to do and that doesn't typically include intentional breaking changes.
A C++ change that requires updating 1% can be several hundreds of thousands of updates which is on the scale of beyond a man year depending on if you can regex cheat.
The fear the author is glossing over (I wouldn't say ignore they acknowledge there are reasons) is when faced with a man year to update people just don't.
Especially when the most interesting breaking changes don't tend to be synthetic (you can just make modules look like code you couldn't write before after all) but instead be subtle changes in behavior.
That means that you won't necessarily even know all the breakages which is a horrifying concept.
by Guvante - > But the major players do seem to be happy to replace their C++ code with Rust.
I would be wary of mindlessly referring to appeals to authority like this. Sometimes their rationale is very context sensitive. For example, Microsoft has been behind quite a heavy push for C#, and it wouldn't be wise to use that as an example of C# being preferable to C++. See for example Bun's recent migration to Rust which could be misinterpreted as an example supporting migrating to rust, but under the hood it's far from a success story.
- > But the major players do seem to be happy to replace their C++ code with Rust.
Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched. It's not worth to rewrite C++ into C++++ to get a couple of features that are flawed retrofits backported from modern languages. In the end you still have C++.
by pornel