Newer stuff yes and it is great. However from basic rendering to browsers and the most complex applications (CAD, office software, finance, complex solvers like airline planning) are still in C++. Nobody will accept rewriting 35+ years of history.
C++ code bases are really a lot longer-lived than any other software builds upon them. Hence we cannot drop it.
Starting with C++17, I think committee has been doing the language a disservice and piled even more and more unintended complexity by rushing "improvements" like modules.
I don't write C++ anymore due to my team switching to Rust and C only (for really old stuff and ABI). I am really scared of having to return though. Not because I am spoiled by Rust (I am though), but because catching up with all the silly things they added on top and how they interact with earlier stuff like iterators. C++ is a perfect language for unnecessary pitfalls. Newer standards just exploded this complexity.
Have there been any successful attempts yet of translating 'idiomatic' C++ to 'idiomatic' Rust for a large codebase that has been developed over 30 years? What does the output look like? Does the code look maintainable (because mechanical solutions to translate from other languages into Rust exist, the result is just not what a human would write or ever want to work on). Are the prompts to guide the LLM shorter than the actual code base to be translated? Etc etc... eg the idea to use LLMs for migration is quite 'obvious', but the devil must be in the details, otherwise everybody would be doing it by now.
Models and agents have progressed significantly in the last few months. Migrating projects to rust can definitely be a thing in the coming years if there is sufficient motivation. But oftentimes c/c++ devs have aversions to the rust language itself, so the biggest challenge can be an issue of motivation in general.
Idiomatic C++ allows too much "freestyle" and duck-typed code. Rust language basically doesn't support half of the things that C++ allows because there is no type or memory safe ways to achieve them. When translating things into Rust, borrow checker forces you to invert the logic or completely redo the architecture. Oftentimes it requires trying multiple things and evaluating the performance cost, generated machine code quality and interface flexibility. It is quite difficult without an actual person to translate things.
Yeah that's why I'm very sceptical about any 'LLM will magically fix all the things' claims. The mechanical translations basically work by compiling the source language down to LLVM bitcode and then translating that back to another language, it works but is basically assembly code written in a highlevel language, it loses all 'semantics' and is entirely unmaintainable.
C++ code bases are really a lot longer-lived than any other software builds upon them. Hence we cannot drop it.
Starting with C++17, I think committee has been doing the language a disservice and piled even more and more unintended complexity by rushing "improvements" like modules.
I don't write C++ anymore due to my team switching to Rust and C only (for really old stuff and ABI). I am really scared of having to return though. Not because I am spoiled by Rust (I am though), but because catching up with all the silly things they added on top and how they interact with earlier stuff like iterators. C++ is a perfect language for unnecessary pitfalls. Newer standards just exploded this complexity.