Yet C++ is what Google, Facebook, Microsoft and others still use for their most mission critical software.
Microsoft had a project to move Windows mostly into .NET, sabotaged by their Windows team, which a decade later rebooted the ideas using COM instead, an idea that has been a commercial failure, while everyone just keeps migrating to .NET.
Microsoft Security team pushed a best practices paper that new projects should use:
1. .NET
2. Rust
3. C++ with Core Guidelines, with Visual C++ analysers turned on
4. They also have a security annotations for C and C++ code (SAF)
Google castrates the use of C++ to app developers in Android to writing native libraries to be consumed by Java and Kotlin, is behind the effort to adopt hardware memory tagging alongside ARM, the reason why Linux kernel no longer uses VLAs and the big pusher for Rust on the Linux kernel.
So it is not just simply "they use C++".
We choose C/C++ because it's what we know and what our colleagues know, but I think a lot of us wish there was a better alternative.
One less device running C, with firmware written in a type safe language that takes bounds checking seriously.
As for Python, I recommend you to have a look at IEEE magazine.
C++ is really only the answer if you need extreme performance and/or expressiveness out of a systems language. Some code, like database engines, really benefits from that.
https://www.f-secure.com/en/consulting/foundry/usb-armory
https://www.ptc.com/en/products/developer-tools/perc
No one has ever demonstrated a systems architecture that can outperform a state-of-the-art schedule-optimized design. This result is expected in theory. There are several optimality theorems, treated as a soft limit, that only hold true if you don’t control the schedule. The requirements of GCs guarantee you don’t control the schedule. State-of-the-art system designs, in non-GC environments, aren’t limited by those theorems and frankly run circles around GC-based systems. I work with a lot of companies that run nothing but managed languages and even they don’t believe that produces an optimal system, just an adequate one for non-intensive use cases. And that is a legitimate position.
You clearly are deeply invested in the superiority of GCs for all use cases. That’s fine. I make a lot of money replacing them with empirically much higher performance systems. There isn’t a lot of computer science to support the pro-GC position if performance is the objective. And to be clear, the loss of performance is integer factor, not something that can be trivially dismissed.
The last time I did full stack C++ development was in 2006, nowadays its use is constrained to a couple of unavoidable native libraries, or GPGPU shaders.
Not everything can be proved in practice when management prefers to give money to the ones that sabotage projects like Windows Dev team has done to Longhorn and Midori efforts.
Are you aware that for quite some time any of your Bing searches using Asian servers were powered by Midori?
Thankfully this is a problem that eventually will get fixed by generational evolution, pity I won't be around to fully witness it.
I’m not familiar with schedule-optimized design though, could you expand a bit on it?
But I assume it can’t easily be used with routinely changing design requirements, with non-obvious object life-times, like most business applications, CRUD apps —- which is the primary use-case of high-level languages.