What exactly have I backpedaled on in any of my replies?

Rust.

Rust eliminates entire categories of bugs at compile time with performance that is on par with C++ and often better.

I do get bugs in my Rust code, but do you want to know what they are? Once in a while I forget to type a ! in an if-statement. Or I accidentally type && when I meant to type ||. These mistakes are trivially caught in unit tests or with a single run of the application and easily fixed. It's also very rare for me to actually make these mistakes. Almost every single time I compile my Rust code, everything works on the first try. But I confess, once in a while one of these minor bugs slips in there.

So yes bugs are possible in every language. But there's a lot to be said about what kinds of bugs are possible, what the risks of those bugs are, and what the process of mitigating them is like. A memory corruption bug is an entirely different beast from a simple Boolean logic bug.

Linters are good and should absolutely be used in any serious C++ project, but they can only catch the most basic sources of UB. I almost never make a mistake that a static analyzer can catch. It's the multithreaded lifetime issues and data races that ambush you the hardest, and I don't see any way a C++ static analyzer could hope to catch those.

But yes, most of the original post is bonkers and has the totally wrong conclusion.

That's awfully reductive.

Tools can absolutely vary in their qualities and in their risks / benefits. I don't know what kind of engineer wouldn't evaluate their choice of tools before using them. If you have a tool that explodes in your face when it gets jostled, that's a badly designed tool.

If you have no other choice for the work you need to do, then okay.. get very good at using the dangerous tool. But if an alternative tool exists that is not only safer but also more efficient, easier to use, and more productive in every use case then the biggest problem really is the choice of tool.

You can call it writing buggy code based on misconceptions, but the fact that it's possible (and not even especially difficult) to misuse smart pointers badly enough to produce program crashes and undefined behavior is still a fundamental weakness of C++ as a language.

As a counterexample, this type of bug is impossible to produce in Rust without explicitly using the unsafe keyword, and that keyword is something that is almost never used by regular developers and is an easy thing to audit for.

Edit: That being said, if you're stuck using C++ then obviously using smart pointers is the right thing to do whereas using raw pointers and managing the memory yourself is completely asinine, so if the author's point is to not use smart pointers in C++ then I suppose they want you to just... Leak memory? Because if you're able to figure out where it's safe to free a raw pointer, then you're able to figure out how to correctly use a smart pointer in that situation.

When it comes to certifying your own software, the evidence is the key thing needed by the certifying bodies.

If I'm someone who wants to get my Rust software safety certified, it's not enough for me to tell the certifier "I compiled my software with this compiler from a project called Ferocene and they have a blog post saying that they're safety certified. Give me a certification please."

Instead you need to show the certifier all the evidence that went into the safety case that achieved certification for Ferocene and then make a case that the evidence is relevant to your own safety case. This evidence from Ferocene is what you pay them for.

And you've pretty much made it over the tipping point into being a Rustacean when you embrace the fact that it is a good thing that Rust doesn't let you do things the way you're familiar with from other languages because those familiar ways were always the source of immense suffering without you even realizing it.