I've always felt that parts of the Rust standard library to be weirdly un-rusty. Like indexing a vector panicking instead of returning a Some(T) in case the index is out of bounds. It's easy to avoid if you put the effort in of course, but it did always feel weird that one of the first data structures you learn has this behavior right out of the gate.
That's not really a memory safety bug, due to the fact that it panics rather than doing something unsafe.
The `variable[i]` notation is intended to function like in other languages, where it returns an unwrapped value. It would be ugly, noisy, unergonomic, and annoying to have to properly handle `Some` (like in `variable[i].unwrap()`) every single time you ever used it. Imagine doing `c[i].unwrap()[j].unwrap() += a[i].unwrap()[k].unwrap() * b[k].unwrap()[j].unwrap();`.
If you really want the result to be wrapped in `Some`, you can use `variable.get(i)`.
> That's not really a memory safety bug, due to the fact that it panics rather than doing something unsafe.
The ? operator can be nicer to read then all those .unwraps() as an alternative.
I guess the cover with panics is you're not forced to think about them like returning `Err`. As a result it could be used as a DDOS against your app if it's network accessible.
I think it is a reasonable tradeoff, especially since `get(i)` is available to do what you want. An array index oob error is usually a logic issue, not some recoverable error, and in a lot of cases you're doing it where it is impossible to be wrong, so it is a lot of error-checking (and giving up things like x[0] += 1) to have the Index trait return an Option instead of a direct reference.
Rust is unsafe by spec, not just by implementation. For memory and type safety. concurrency safety is impossible to get with their blocking IO approach.
I sure wish they'd rewrite the Azure Linux VM Agent in Rust. That thing normally burns 10-15% of a core, and also blocks VM restart for tens of minutes, god knows why.
I've seen certain MSFT engineers get a lock ordering warning from taking mutexes in a wrong order and "fix" it by using a spin loop + try lock instead.
True but C never went out of its way to highlight memory safety features and shut down (with a rather aggressive posture to boot) any criticism of the language with arguments revolving around this feature as if it was the Christ's second coming.
In lieu of finding out that there are in fact multiple memory issues in std is at least amusing and some might say well deserved egg in the face of the more, shall we say, enthusiastic defenders of the language.
The `variable[i]` notation is intended to function like in other languages, where it returns an unwrapped value. It would be ugly, noisy, unergonomic, and annoying to have to properly handle `Some` (like in `variable[i].unwrap()`) every single time you ever used it. Imagine doing `c[i].unwrap()[j].unwrap() += a[i].unwrap()[k].unwrap() * b[k].unwrap()[j].unwrap();`.
If you really want the result to be wrapped in `Some`, you can use `variable.get(i)`.
The ? operator can be nicer to read then all those .unwraps() as an alternative.
I guess the cover with panics is you're not forced to think about them like returning `Err`. As a result it could be used as a DDOS against your app if it's network accessible.
reminds me of the tales from https://oxide.computer/blog/iddqd-unsafe
Rust is unsafe by spec, not just by implementation. For memory and type safety. concurrency safety is impossible to get with their blocking IO approach.
In lieu of finding out that there are in fact multiple memory issues in std is at least amusing and some might say well deserved egg in the face of the more, shall we say, enthusiastic defenders of the language.