> all these FUBAR C/C++ systems (...) work well enough to transfer that kind of garbage to me I don't think you read the article. The author specifically cites

> all these FUBAR C/C++ systems (...) work well enough to transfer that kind of garbage to me I don't think you read the article. The author specifically cites lots of different types of hyperbolic "rewrite everything in Rust!" arguments and explains how this article is not that and he doesn't advocate for that. The author of the article advocates "surgically replace weaker parts but keep most of the project intact." This is exactly how Mozilla is dogfooding Rust in Firefox. And no one is arguing that all of those C/C++ systems you mention are "FUBAR" -- that's a strawman. Rust advocates, as well as advocates of many of the newer-generation, lesser-used languages advocate for advancing programming beyond the languages designed in the 1970s. We've had an explosion in programming language diversity over the past 30 years and we've developed some great research on how to prevent certain classes of defects. The longer those C/C++-written systems exist without a rewrite in a safer language (or thorough audits including massive amounts of fuzzing), the larger the impact of inevitable non-zero-probability of those vulnerabilities which Rust prevents. The article's author completely admits that at their best, C/C++ developers can avoid all of the problems that Rust solves. But not everyone is a rockstar and not everyone performs at 100% all of the time. Rust is written for humans and the compiler is a strict nanny, preventing you from getting yourself into danger, the same ways you can with C/C++ memory issues. It also has tooling for unit tests, benchmarking, fuzzing, and standardizing code formatting conventions in the language. You can bolt these things onto C/C++, but that means that you have to go find them (which new developers won't do unless sufficiently motivated to).