> Bounds checking and panicing are similar mitigation techniques and not an actual freedom from memory-born vulnerabilities Absolutely. Bounds checking is a mi

> Bounds checking and panicing are similar mitigation techniques and not an actual freedom from memory-born vulnerabilities Absolutely. Bounds checking is a mitigation technique to avoid potential footgun when you want/have to use manual array indexing. In most situations in Rust, you use iterators instead of array indexing. Those are the «actual freedom from memory-born vulnerabilities» and have no associated overhead. Since it is known at compile time that you are not going to access invalid memory, there is no need for bounds checking in this scenario. Most of rust safety comes from clever compile time checks with no additional cost at runtime. The two main counter-examples I can think of are : - bounds checking on manual array indexing - usage of a secure hash function by default in HashMaps The whole story about safe multi-threading and dangling pointers prevention is totally free performance-wise: everything is checked at compile time by the borrow checker. > memory safety is still not going to make it free from vulnerabilities to accidental DoS attacks (not even talking about malicious users here!) You're right, Rust doesn't solve all the problems at once. Is it a good reason to get rid of the benefits of solving the worst 50% of problems ?