Using the sum of C and C++ is a bit misleading. If you use C++20 or later with containers, smart pointers, ... the number of memory safety problems goes down a lot. But if you include all the problems from C and older C++...
Rust
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
Ah but then you would actually have to use C++ /jk
On the phoronix forums there are people seething about Rust nonstop. Rust in the linux kernel is their favorite enemy and they will have very strong opinions about it without ever having written rust nor a line of code in the kernel.
Rust won't 100% replace C++ code in old code bases but I'm convinced that in 5-10 years the amount of new C++ code will fall behind Rust code.
5 years is optimistic. More likely 10-20 years at least. Established languages have a lot of inertia and it takes a very long time for that to change.
language popularity can change pretty quickly
according to the tiobe index, in 1985, lisp was the 2nd most popular programming language and c++ was the 10th. fast-forward 5 years and c++ took the 2nd place, while lisp fell down to 7th place. i wouldn't be surprised if something similar happened between c++ and rust
Inertia also accounts for time and popularity. The longer something has been around and popular the more inertia it has and the harder it is for something to change it. Back in 1985 things had a lot less inertia then they do today - C and C++ have been gaining it constantly for 30 years since then.
To me the inertia could be measured in time to refactor projects.
How much time would it take to refactor or create a net new replacement of all of the lisp code of 1985 in active production vs all of the c++ in active production today.
I do not know the numbers but I would hypothesis a staggering delta in hours needed from the then to now. Even with advancements in code change velocity of today
Considering the fact that there are crucial programs all across platforms that are written in Assembly and are still very relevant. This couldn't be more true.
@shape_warrior_t I think faster delivery is also a consequence of a good DX,
managing dependencies and building with cargo is probably less cumbersome than installing specific toolchain and fighting makefiles and CMake.
I'm not sure that's a factor here because Google doesn't use CMake or Cargo (at least not the way we all use it).