They're basically making an argument of "talking about the programming language involved is missing the forest for the trees." Bugs are inevitable, regardless of language, and so the real culprit here is a lack of QA/validation before deploy.

Which like, sure, it's a good point in general, but it's also worth discussing if certain technologies would make your QA team's lives easier. Both "would this tool catch this bug" and "are there structural problems that led to a bug slipping through into production" are valid questions.

In my mind, the author is making the same mistake he accuses others of making, just from the opposite direction.

QA aren't some magic wizards that can catch all bugs. They might never hit the memory corruption scenarios that Rust optimizes for. I think you need everything - a good high level language, experienced devs who know that domain, and good practises surrounding each release. There is no good reason for a billion dollar corp to skimp on these.

> Author says Rust wouldn't solve the crowd strike outage but then literally admits that it would have prevented it?

If a person who got claymored by a Takata airbag in a car crash had taken a different route the crash wouldn't have happened and the airbag explosion would have been prevented, but the actual problem still exists and is waiting for some other thing to trigger it.

That's the point the article is making, yes Rust would probably have prevented this specific exact incident but the actual problem that led to this is Crowdstrike's apparent lack of testing and staged release processes for these channel files which could just as easily have triggered some other bug that Rust would not necessarily have had any impact on.