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.
If you really want the result to be wrapped in `Some`, you can use `variable.get(i)`.
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.
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.
If you really want the result to be wrapped in `Some`, you can use `variable.get(i)`.
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.