3 ms·

We've all been there – you know for sure something is 100% safe and then the fuzzer finds and UB that was outside of your mental model bounds... Thing is, if s

We've all been there – you know for sure something is 100% safe and then the fuzzer finds and UB that was outside of your mental model bounds... Thing is, if some system/concept/abstraction/model is memory-safe, more often than not it directly translates to Rust concepts via lifetimes and the such. If you've done it a number of times, you will find it very easy to map the former to the latter. In the rare cases when it doesn't fully translate, you can always dip into unsafe (usually at the lowest levels of your abstractions), same as the Rust's standard library does, and test/fuzz that part extensively.

mort96 4y ago
I am not against the concept of safety guarantees. We have all been there where we have written code based on a faulty mental model which resulted in bugs. Yes. And more often than not, Rust would have prevented those bugs or made them less severe. But we have also all been there where we have had a solid mental model of what a system is doing and written correct code. Rust helps in the former case, but it makes the latter case harder. And no, it's not the case that "more often than not", if you need one const reference and one non-const reference to some data, your code is wrong. In fact, almost all code in almost all mainstream languages end up with multiple references where at least some are non-const, and it's fine most of the time. In Rust, all of those situations require type system and borrow checker gymnastics. I'm not against Rust. I think it's a fine language. I also think it's significantly harder to write than most other languages if you don't want to just punt and use Rc<RefCell<T>> all over the place.