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.
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++.
Not touching a codebase only applies to legacy software which is feature complete. Any actively developed software will benefit from incremental improvements.
Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golang’s also providing solid opposition.
Bjarne still sees C++'s safety problem as lack of adoption of Modern C++. WG21 is catering to C++ users who will not make such changes.
WG21 has firmly rejected everything resembling Rust's borrow checking (a solution that now has a decade of proven track record, and has been demonstrated to be possible in C++ via Circle/Safe C++). Addition of "pervasive annotations" is so unacceptable to WG21's view of C++ that they're still insisting on Profiles.
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.
Since you don't mention that this migration is basically executed agenticly by Claude, it seems like you attribute this troubled migration to Rust not being that good of an improvement after all. For me it doesn't seem that surprising that Claude autonomously translating hacky Zig (according to Andrew Kelly #1) to unidiomatic (way more unsafe code that usual) Rust didn't solve the issues that the original code base already had.
#1 https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
That's immaterial to the discussion.
(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.
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.
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
The two factions of C++ - https://news.ycombinator.com/item?id=42231489 - Nov 2024 (653 comments)
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.
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.
Obviously we need ABI compatibility between the two standards for this to work.
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.
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.
Probably best to go to the index and look at part 1 of the saga.
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!
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.
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.
That's not the biggest upside of move semantics. You can't safely express smart pointers without move semantics. They tried with std::auto_ptr, and it didn't work.
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.
Out of curiosity, would you be able to elaborate on (or link to?) what makes reflection so problematic?
Not much has changed, though, it still is. Just with a lot more bells and whistles around it
More importantly, before C++11 every library I worked with had their own incompatible way of managing memory. None of them used smart pointers in the API, it was always raw pointers (or references where possible but often not possible) and their own documented ownership rules. Any single library was simple enough to follow the rules (hint we got it wrong often), but the combination was very complex and sometimes impossible to combine the two different rules.
C++11 changed how most people manage memory. You could get the same effect without, but it was both more complex, and nobody agreed on the same rules.
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
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.
Past discussion (653 comments): https://news.ycombinator.com/item?id=42231489
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.
I don't see why breaking changes is such a major concern.
Unless the aggrieved party is the compiler maintainers, I guess.
C++ is still king of the mountain and it will remain so for decades.
The billions of lines of existing C++ are not being re-written in rust (by humans or AI's). 100 thousands of lines are being re-written.
C++ is changing, but C++11 is moving across the land. It will be 20 years before the 'new' C++ stuff gets regularly used.
Just because it is old, doesn't mean it doesn't have value.
Just because it is done a certain way at google, doesn't mean you have to do it that way.
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.
> involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad
Well.. "C".. though I wouldn't go so far as to call that a good language, either.
Are templates really so much better than macros that the latter deserve to be called a "hack"? The following two examples are both type-safe and have roughly the same semantics and #LoC:
Macros:
// pair.h
struct id(pair) { T a, b; };
static inline struct id(pair) id(make_pair)(T a, T b){
return (struct id(pair)){ .a = a, .b = b };
}
#undef id
#undef T
// main.c
#include <stdio.h>
#define T int
#define id(n) n ## _int
#include "pair.h"
int main(void){
struct pair_int p = make_pair_int(12, 13);
printf("%d %d\n", p.a, p.b);
}
//pair.h
template<typename T>
struct pair { T a, b; };
template<typename T>
pair<T> make_pair(T a, T b){
return (pair<T>){ .a = a, .b = b };
}
//main.cpp
#include <stdio.h>
#include "pair.h"
int main(void){
pair<int> p = make_pair(12, 13);
printf("%d %d\n", p.a, p.b);
}Perhaps that might be a better language in a different context, but I don't think that language would have have been better for Google given their goals (e.g., bidirectional interop with C++, incremental automated migration, memory safety, etc.)
I don't think that professional developers go around mindlessly starting projects without evaluating their choices. The truth of the matter is that the whole industry has been picking C++ over alternatives for ages, to the point where C++ managed to get one of the most popular languages devised. Why do you think that happened?
> I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch (...)
That says more about your competence than anything. I mean, CMake works so well that companies such as Jetbrains developed their C++ IDEs around it. But somehow you seem to struggle where everyone just dash towards coding. Why is that?
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?
Apparently easier and faster parsing. Most modern language have arrived at the `fn bla(arg: ArgType): ResultType` form and I don't think they made that decision for purely aesthetical reasons.
Not just modern, it's older than you think. Pascal function definition is `function bla(arg: ArgType): ResultType;`
Strongly disagree. I too thought that it would be easy to implement a new language in 1-2 years. I started the current Quxlang codebase (under a different name) on Dec 27, 2022. In 2026, hundreds of commits and hundreds of thousands of lines of code later, I still don't have a feature complete language.
I also rewrote the syntax, mainly because C++ parsing is a nightmare... Although my choice was very different...
For me, I switched away from C++ in 2008 or thereabouts. For anything that needs a higher level of abstraction than C, I'll use Lisp, Python, Java, C#[1], etc.
You might enjoy (shameless plug to my own blog):
https://www.lelanthran.com/chap9/content.html
https://www.lelanthran.com/chap13/content.html
=============================
[1] Although, C# has lately gone the way of becoming incomprehensible syntax-wise. I've seen this happen with C++ in the past, so not so sure I'll even use C# again.