> "I've just seen too many memory exploits in C/C++ to consider statements like "you can achieve memory safety in C/C++ if you're a True Scotsman" as anything o

> "I've just seen too many memory exploits in C/C++ to consider statements like "you can achieve memory safety in C/C++ if you're a True Scotsman" as anything other as logical fallacies." The problem is that for each person who offers your anecdata, there's another person who offers the antithetical anecdata. For example, in my experience with two very large defense lab projects written in C and C++ spanning the 80s to the early 00s, both projects had exceptionally nice tooling to prevent memory issues, and it was pleasant to work with the code. Debugging time was usually spent on application logic bugs and very rarely, if ever, spent on memory leaks, segfaults, corrupt data, alignment issues, etc. While I know this isn't directly applicable to Rust, I have also worked in a separate codebase that was a huge Haskell project and it was a nightmare of spaghetti code, performance bugs that were impossible to reason about, some segfaults, and it was extremely painful to descend into unsafe code for the occasional situations when it was required. Having the compiler to help us and leveraging the type system as part of the application design didn't really offer any significant benefits. This doesn't prove anything except that, like usual, it's situation-specific and depends on relevant trade-offs at hand. It almost never has anything to do with the generic types of safety guarantees that a framework or language allows you to formally verify.