Hot takes on the state of Rust v C/C++ for safety (mastodon cross post)

A lot of people think I'm being sarcastic here, which is fair because I only went toe-to-toe against people on Twitter and didn't do much here, so I'll state my full opinion below anyhow: I would agree with anyone about not wanting to replace C (or C++). But, C has been alive for 50 years (or just 35 from C89) and Rust has been alive for just barely under 10 (since Rust 1.0). Even if you measure the last 10 years of Rust versus the last 10 years of C or C++, one of these languages is making leaps and bounds ahead in providing people better primitives to do good work. SafeInt secured pretty much all of Microsoft Office from some of the hardest bugs back in, around, 2005. C++ still lacks safe integer primitives; C only just got 3 functions to do overflow-checked math in C23, after David Svoboda campaigned for years. Rust just... has them baked into the standard library, for all the types you care about, too. Similarly, people have been having memory issues in C and C++ for a while too. Most of the way to get better has been clamping down on static analysis and doing more testing, but we're still getting these errors. Meanwhile, teams writing Rust have been making way less errors on this in all the openly-published data from corporations like Google, and privately we are hearing a lot more about people taking complex financial and parsing code and turning it into Rust and having a fraction of the issues. Even if I want to see C doing better, I have to acknowledge we were (a) too slow and not brave enough to do the things that could fix these portions of the language; (b) have fundamental design issues in the language itself that make ownership impossible to integrate as part of the language without breaking a ton of code; (c) do not provide good in-language tools and keep depending on vendors to "do the right thing" (i.e. adding or expanding U.B. and then just saying "vendors will check it" rather than taking responsibility with our language design); (d) are moving monumentally too slow to address the needs of the industry that many people -- especially security people -- have been yelling about since the mid 90s. As much as I just want to pretend that I can write off every developer with "haha lole skill issue test better sanitize better IDIOT", if the root cause on this bug is "there was some C and/or C++ code that looked nominally correct but did batshit insanity in production", we absolutely will have problems to answer for. This doesn't absolve CrowdStrike for cutting 100s of workers and playing fast and loose, this doesn't excuse the fact that hospitals went down and people likely dead from lack of access to care, this doesn't change that it's abhorrent to have unmitigated hardware access in Ring0 just for a "security product", which has been the trend of every app wanting to plug in its own RootKit-like tool just for the sake of "app security" lately (League, NProtect, School Exam Spyware, etc.). There's a LOT of levels of "what the fuck have we let happen?" in play here, but I don't control those other levels. I'm responsible for C, so I'm gonna look at the C bit. Other people responsible for the other parts of this stack should, hopefully, take sincere responsibility for those parts. (I doubt it, though, lmao.)