@koteisaev @marcan My point is that memory safety does not help here. Because a panic at a out-of-bounds is memory safe and would still have the exact same effect. Hector's argument seems to be that other things you can optionally do in Rust would potentially allow to avoid this, but this is not the result of using a memory safe language per se. I agree about the sad state of software engineering and I also I agree about the advantages of memory safety in general.
@uecker @koteisaev My point is that you can do those things in Rust and you can't in C.
The actual crash here was a NULL deref. That is one of the most classic footguns of memory-unsafe languages (not just those, also others like Java for some reason). In Rust there are no
NULL
s, only explicitOption<T>
s, which force you consider the case of there being no value. Yes, you can still just turn it into "panic if no value" but making it an explicit decision that the programmer has to make means it's a lot less likely to happen by accident and a lot more likely to be correctly handled with error propagation, and it also means you can outright ban that choice by policy and technical means.@uecker @koteisaev My point is that you can do those things in Rust and you can't in C.
The actual crash here was a NULL deref. That is one of the most classic footguns of memory-unsafe languages (not just those, also others like Java for some reason). In Rust there are no
NULL
s, only explicitOption<T>
s, which force you consider the case of there being no value. Yes, you can still just turn it into "panic if no value" but making it an explicit decision that the programmer has to make means it's...