The central argument is that C/C++ is not worth the trouble for new code and that using it "correctly" is a theoretical thing that even experts struggle with. C

The central argument is that C/C++ is not worth the trouble for new code and that using it "correctly" is a theoretical thing that even experts struggle with. C/C++ programmers keep on insisting that they've found ways to do it right, finally. Some C/C++ programmers seem to believe that, unlike everybody else, they actually have the combination of wisdom, skills, and discipline to not fall into this trap. At this point that seems rather foolish. The author's main argument is that other languages that exclude categories of bugs that keep on popping up in the C/C++ world are good enough at this point to be used for essentially all system programming stuff. Apple, Google, Microsoft, etc. employ the best people that money can buy them. And they've each started actively discouraging the use of C/C++ for new stuff. Google actually created Go for this reason and they are now also using a lot of Rust lately. Apple created Swift to get rid of object C. And MS has been trying to move to C# (which they created) for the last two decades to put a stop to all the embarrassing issues they had with their native stuff. They too seem to like Rust lately. And obviously they each have to own up in public regularly about cases where, "oops, we did it again" despite having spent the last few decades to avoid having to do that so regularly. The usual suspects are bits of C/C++ doing things wrong with memory and bounds checking because their programmers made a mistake. It seems leaving this to humans to do "right" just is not good enough at this point. The article gets a bit messy with a rant on stateful vs. stateless and a few other things. But the main argument with that seems to boil down to the notion that depending on a lot of stuff like databases, memory caches, etc. that are often implemented using C/C++ is neither fast (because of network latency) nor safe (because of the above mentioned bugs and security issues). It's true and it's why alternatives to these infrastructure components written in other languages are a thing. They are plenty fast and in so far they are not, the network latency hides most of the issues to the point where you'd not notice much difference in terms of e.g. throughput or latency at the price of maybe slightly more CPU usage on servers that are mostly running nowhere even close to 100% CPU usage. Besides, adding more CPUs is cheap. Dealing with security problems is not. And of course using Rust for things that really need to be fast is a thing. There's growing amount of projects that are about creating drop in replacements for C/C++ things that have existed for a very long time where the goal is to actually improve their performance and safety by re-implementing them in Rust. It's the argument the article does not make. But it seems that with Rust, you can have your cake and eat it in terms of performance. So, why bother with C/C++ for new stuff? Why risk security bugs when the main argument of better performance simply does not hold true anymore? It's a solid argument. But I agree the article does a weak job of making it.