Don't get me wrong, it sounds positive. A direct attack on Fil-C would have seemed mean-spirited so there is a lot of misdirection. Maybe the author doesn't even see what he's doing because he's so deep in it. But to me the message is clear. No matter what tools are developed for C and C++ to mitigate memory issues, Rust people will never concede that enough of these issues have been solved. They demand a complete rewrite of everything, or at least gradual replacement of all C and C++ code with Rust. Even if Rust is worse in other ways, does not deliver true safety, has technical shortcomings and worse licensing, etc.

This post is very polite compared to what I've seen from some Rust fanatics. But it still strikes me as talking down to the C and C++ community, as if these languages are beyond redemption because they don't work the same as Rust.

I'm not familiar with the guy and I can't say that this post is obviously mean. You certainly seem to think very well of him, which might cloud your judgement about what is actually in the post. It just comes off as soapboxing for Rust under the pretense of saying Fil-C is great. It's like reading a review for a movie that says "This movie was good for X, Y, Z reasons but this OTHER movie is at least as good, if not better." The man is certainly entitled to an opinion but I didn't get anything from it besides "I like Fil-C but Rust is still solving this problem a way I like better."

I wasn't suggesting that you should run everything with Fil-C all the time. If you run it sometimes, you're likely to catch most problems. The ideal tool would be CHERI or something. I think Rust makes a big mistake with its maximal error checking every time you compile, among its other flaws. Rust compile times are high compared to similar C++ code. The compiler has a high amount of necessary complexity that comes into play every time you run the code with a few lines of changes. Of course, C++ has higher compile times than Go and C, and probably some other languages, but they are fairly different languages with different error modes.

Let me put it another way. We could say that documentation, code formatting, and even profiling, all have a place in development. So would running a model checker or something. But we don't generally make compilers implement these features and make that a mandatory part of the build. I think the complex memory borrowing scheme of Rust unnecessarily forces the compiler to check a lot of extra stuff specific to a certain class of problem. You don't get a choice about how paranoid you need to be about errors. You just have to eat that long compile time, every time.

Maybe always faster, but perhaps not always much faster.

You can use classic OOP in Rust (even implementation inheritance, via the generic typestate pattern!) It's just not a good idea.

There are many languages in this space to choose from.