Earlier quoted context omitted.
> The cloudflare bug was not caused by rust Yeah. Rust’s Option::None as like null in C++. Unwrapping an option is like checking if something is null and crashing. This "crash from an unwrap" is just a null pointer exception / segfault in any other language. The same bug would be trivial to write in any other language, and with more or less the exact same result. Its just - weirdly news because it was rust code. What…
The Cloudflare bug was unwrapping a Result::Err not an Option::None. Both Option and Result can be unwrapped and - to some extent not coincidentally - both can also be subject to the Try operator (?) which is arguably more correct here than unwrap because this can fail and perhaps the caller will have some plan to recover. My list of peeves would be very different from yours. I would like to prohibit move of the dodg…
I guess its equivalent to Go code like this:
value, err := stuff()
if err != nil {
panic(err)
}
int result = stuff();
assert(result >= 0);
> What sort of "interacting with raw pointers" are you thinking of that's too inconvenient and ugly for your liking?
I have 2 complaints. First, I wish Rust had a -> operator or something like it. This sort of thing is horrible:
(*(*(*ptr).foo).bar)
Here's an unsafe function which manages the internal state of a skip list:
https://github.com/josephg/jumprope-rs/blob/3981256e4e741d8b...
This code is insanely fragile. There are multiple pointers to different elements floating around. The only way I got miri to calm down was to dereference the node pointer constantly. Eg:
*cursor.num_bytes -= (*node).str.len_bytes();
let next = (*node).first_next().node;
As a general principle, unsafe rust should be as simple and easy to reason about as possible so we can spot security problems. But rust's syntax makes unsafe code very complex. I don't think this complexity is in any way necessary.