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.
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.
That was most of your original comment and it remains wrong.
Now you’re talking about specific memory-safety-related features, but you’re making a big assumption. Not everything has to look like Rust. Goodness no! And C++ is still improving in that area too.
“An incremental language change would be to adopt a Rust-like iterator.” One of many possibilities.
“That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.” Obviously not. Nowadays maybe it could be easily done with AI, even if a Rust-like iterator is not necessarily something that C++ programmers would want.
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.