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.
Applying the ? operator to an Option<_> doesn't work inside a function returning io::Result<_>, for example, and turning the None from an out-of-bounds vector access into some io::Result::Err usually wouldn't make sense.
I would go so far as to say that an out-of-bounds index is always a logic error (to be handled by panicking), not an input error (to be handled with Result). And if the out-of-bounds access was caused by invalid input, then logic error consists of not checking the input before indexing.
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 think that the point of Rust as far as memory safety isn't perfection. The point is centralizing proper memory safety.
With C, every single programmer has to properly account for memory safety in just about every program they write. If you fix a memory safety bug in one program, that's not necessarily going to help any other program.
With safe Rust, that work has largely been done for you. If a memory safety bug is found and fixed in Rust's standard library, it's found and fixed for every program that uses safe Rust (with a recompile using the new standard library version).
The point is for some experts to work together to get things as memory safe as possible in one place instead of everyone having to get things as memory safe as possible in every place.
There were also memory safety bugs found in Rust code without frontier models before. Note that I do not deny that Rust has an advantage with regard to memory safety (at the cost of other things, including supply chain issues), but it is massively overhyped.
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.
I have my share of criticism of Rust. But even a safe language has to deal with unsafe memory etc. at some point in the stack. The goal is to minimize such uses of unsafe and for the cases of unsafe that exist to prove that they are safe.
These haha gotcha's are criticism leveled at language designers who never denied that there is unsafe code, that there can be bugs in unsafe code, and that such bugs can leak to safe code.
egg in the face
Is it an egg in the face when it requires LLM analysis to find these nowadays? It tells me that the Rust developers got really good at eliminating memory bugs that are lurking in unsafe code.
Also, this doesn't change anything to the benefits of Rust's ownership model, which removes classes of bugs that are very common in C/C++, so the Rust advocates were still right.
(I'll leave my rants about Rust in a thread where it's more appropriate, but they are not about memory safety.)
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 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 would go so far as to say that an out-of-bounds index is always a logic error (to be handled by panicking), not an input error (to be handled with Result). And if the out-of-bounds access was caused by invalid input, then logic error consists of not checking the input before indexing.
If you are doing this then you've made a mistake in your code. Rust is consistent in catching these early.
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.
With C, every single programmer has to properly account for memory safety in just about every program they write. If you fix a memory safety bug in one program, that's not necessarily going to help any other program.
With safe Rust, that work has largely been done for you. If a memory safety bug is found and fixed in Rust's standard library, it's found and fixed for every program that uses safe Rust (with a recompile using the new standard library version).
The point is for some experts to work together to get things as memory safe as possible in one place instead of everyone having to get things as memory safe as possible in every place.
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.
These haha gotcha's are criticism leveled at language designers who never denied that there is unsafe code, that there can be bugs in unsafe code, and that such bugs can leak to safe code.
egg in the face
Is it an egg in the face when it requires LLM analysis to find these nowadays? It tells me that the Rust developers got really good at eliminating memory bugs that are lurking in unsafe code.
Also, this doesn't change anything to the benefits of Rust's ownership model, which removes classes of bugs that are very common in C/C++, so the Rust advocates were still right.
(I'll leave my rants about Rust in a thread where it's more appropriate, but they are not about memory safety.)