We have literal decades of experience showing that the problem isn't "get good"--no matter how many best practices are followed, it turns out that the next gene

We have literal decades of experience showing that the problem isn't "get good"--no matter how many best practices are followed, it turns out that the next generation of fuzzers or analyzers or whatnot is able to uncover yet more problems in the most perfect codebases we're aware of. In my experience--and most others' too--it is far better to design APIs so that they are impossible to misuse, rather than relying on developers to remember the rules to prevent misuse. This is where maxims like "parse, don't validate" come from. C's type system is simply too weak for API misuse to be made compile-time failures, which means you have to rely on convention, and anyone who thinks that convention can be made robust across a multimillion line codebase is delusional. One of the advantages of Rust is that you can create newtypes which rewrap the APIs to make misuse impossible. I've been working on some numerics code in Rust, and the first thing I did was to make different types for the different kinds of indices (rows, columns, permuted rows, etc.) so that it's simply impossible to use the wrong index for a given array. Also, one of those things I've noticed is that most of the people who are dismissive of Rust is that they point to its protection against 'missing "free()" here and there.' Which is strange, because it probably doesn't even make the top 10 list of problems in C that Rust protects against. The C issue that keeps me up at night when I write C code is pointer invalidation, which is what Rust's lifetimes + mutability xor aliasibility rules are meant to protect against. So why talk about free and not pointer invalidation?