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 and doesn't panic.
I guess the concern with panics is you're not forced to think about how you want to handle them like you do when you get a `Result` or `Option` returned.
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.
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 and doesn't panic.
I guess the concern with panics is you're not forced to think about how you want to handle them like you do when you get a `Result` or `Option` returned.
As a result it could be used as a DDOS against your app if it's network accessible.
gotta remember tho that ? didn’t exist in 1.0, and now we can’t break existing code
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.
> Like indexing a vector panicking instead of returning a Some(T) in case the index is out of bounds.
If you are doing this then you've made a mistake in your code. Rust is consistent in catching these early.
> Pattern 2: Trusting user-provided implementations to be correct
reminds me of the tales from https://oxide.computer/blog/iddqd-unsafe
> Notes from Microsoft Security's Frontier Offensive Research & Generative Exploitation Lab.
A good use for AI
No, a good use to fix their specs.
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.