5 ms·

The author says "Rust crashes all of the time" and then goes on to invoke the Cloudflare unwrap() as an example of that. Uhhhh... but that was clearly a program

by fn-mote 11mo ago

The author says "Rust crashes all of the time" and then goes on to invoke the Cloudflare unwrap() as an example of that. Uhhhh... but that was clearly a programmer error, right? Ignoring the possibility of a Result being Err instead of Ok is not something the language is supposed to protect you against.

loeg 11mo ago
Yes, but in C++ we would simply not have asserted the result has_value instead of has_error and instead returned some implicit memory corruption. Or, I think that is the author's argument. (I don't subscribe to that point of view.)
- saghm 11mo ago
  Yeah, I don't really get that argument if that's what the author is trying to claim. If there's a language where a programmer mistake can't have bad consequences, C++ isn't it, so either it would need to be combined with an argument that C++ programmers are just better (which seems like a bold claim that would require evidence, on top of not really being about the language anymore), or it isn't really a point against Rust.
byko3y 11mo ago
There are programming languages/models/runtimes that crash and recover, there are models that gracefully degrade. Rust cannot recover. Neither can C++ in many cases e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`. Do note that C did not have such a flaw built into language — C++ authors invented it and Rust inherited this flaw (the authors simply did not feel like it's a flaw). I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact). Or compare it to BEAM that can have processes crash all day long and still continue to work. "Memory safety at all cost" is not a practical requirement — it's theological.
- EnPissant 11mo ago
  Nothing forces you to panic in Rust any more than anything forces you to call abort() in C. let a = b.unwrap(); is conceptually no different to: if (b == NULL) { abort(); } a = *b; don't write either if you don't want to halt.
- aw1621107 11mo ago
  > Rust cannot recover. catch_unwind exists for a reason. > e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`. You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though. > Do note that C did not have such a flaw built into language assert() says hi? > I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact). Why doesn't a similar argument apply to "specially designed" Rust? > Or compare it to BEAM that can have processes crash all day long and still continue to work. Again, nothing stops you from writing Rust that does the same. [0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [1]: https://cpp.godbolt.org/z/ao4cf3zrr https://cpp.godbolt.org/z/ao4cf3zrr
  - byko3y 11mo ago
    >You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though. Come on, please tell me you don't do this in your code. Formally you are correct, but there are many things in C++ that should have better not existed. >Why doesn't a similar argument apply to "specially designed" Rust? Because it would lose most of the Rust properties by that time. C code with fixed memory layout, on the other hand, is ideomatic and was widely employed in the past. It's still being employed in embedded. I'm not saying that you are wrong though, there might be people optimizing Rust for this very purpose, but I'm not aware of such an effort. >catch_unwind exists for a reason. >>Or compare it to BEAM that can have processes crash all day long and still continue to work. >Again, nothing stops you from writing Rust that does the same. Who's gonna GC the poisoned garbage left in undefined state after the crash? I'm not saying it's impossible — I honestly have no idea whether safe recover is possible in Rust, but from what I know it's rather in middle of "not possible" and "not viable".
tialaramex 11mo ago
By coincidence I was talking to one of Cloudflare's engineers this weekend† and they actually argued that the unwrap() isn't the problem per se, that instead it's just wrong to go from "We don't know if this data works" to "Everything is broken" without the step where you check that data works - and that's still true if we're doing this once per minute not once per month. I argued that requiring expect("expectation") calls rather than unwrap() instils the discipline to consider what you're expecting and thus why you think we won't panic - to write the text in the expect call, but I did not convince them and they remained sure that what Cloudflare needs is better deployment discipline not improved engineering practices. † It is a coincidence that they work for Cloudflare, it was quite intentional that I spent much of my weekend with them, we were playing video games.
- riwsky 11mo ago
  Screw discipline, it’s a tooling problem. Making canary rollouts with automatic rollback the default would take a lot of investment up front, but then would make discipline at release time a non-factor.

by fn-mote 11mo ago

loeg 11mo ago

Yes, but in C++ we would simply not have asserted the result has_value instead of has_error and instead returned some implicit memory corruption. Or, I think that is the author's argument. (I don't subscribe to that point of view.)

saghm 11mo ago
Yeah, I don't really get that argument if that's what the author is trying to claim. If there's a language where a programmer mistake can't have bad consequences, C++ isn't it, so either it would need to be combined with an argument that C++ programmers are just better (which seems like a bold claim that would require evidence, on top of not really being about the language anymore), or it isn't really a point against Rust.

byko3y 11mo ago

There are programming languages/models/runtimes that crash and recover, there are models that gracefully degrade. Rust cannot recover. Neither can C++ in many cases e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`. Do note that C did not have such a flaw built into language — C++ authors invented it and Rust inherited this flaw (the authors simply did not feel like it's a flaw). I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact). Or compare it to BEAM that can have processes crash all day long and still continue to work. "Memory safety at all cost" is not a practical requirement — it's theological.

EnPissant 11mo ago
Nothing forces you to panic in Rust any more than anything forces you to call abort() in C. let a = b.unwrap(); is conceptually no different to: if (b == NULL) { abort(); } a = *b; don't write either if you don't want to halt.
aw1621107 11mo ago
> Rust cannot recover. catch_unwind exists for a reason. > e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`. You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though. > Do note that C did not have such a flaw built into language assert() says hi? > I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact). Why doesn't a similar argument apply to "specially designed" Rust? > Or compare it to BEAM that can have processes crash all day long and still continue to work. Again, nothing stops you from writing Rust that does the same. [0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [1]: https://cpp.godbolt.org/z/ao4cf3zrr https://cpp.godbolt.org/z/ao4cf3zrr
- byko3y 11mo ago
  >You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though. Come on, please tell me you don't do this in your code. Formally you are correct, but there are many things in C++ that should have better not existed. >Why doesn't a similar argument apply to "specially designed" Rust? Because it would lose most of the Rust properties by that time. C code with fixed memory layout, on the other hand, is ideomatic and was widely employed in the past. It's still being employed in embedded. I'm not saying that you are wrong though, there might be people optimizing Rust for this very purpose, but I'm not aware of such an effort. >catch_unwind exists for a reason. >>Or compare it to BEAM that can have processes crash all day long and still continue to work. >Again, nothing stops you from writing Rust that does the same. Who's gonna GC the poisoned garbage left in undefined state after the crash? I'm not saying it's impossible — I honestly have no idea whether safe recover is possible in Rust, but from what I know it's rather in middle of "not possible" and "not viable".

tialaramex 11mo ago

By coincidence I was talking to one of Cloudflare's engineers this weekend† and they actually argued that the unwrap() isn't the problem per se, that instead it's just wrong to go from "We don't know if this data works" to "Everything is broken" without the step where you check that data works - and that's still true if we're doing this once per minute not once per month. I argued that requiring expect("expectation") calls rather than unwrap() instils the discipline to consider what you're expecting and thus why you think we won't panic - to write the text in the expect call, but I did not convince them and they remained sure that what Cloudflare needs is better deployment discipline not improved engineering practices. † It is a coincidence that they work for Cloudflare, it was quite intentional that I spent much of my weekend with them, we were playing video games.

riwsky 11mo ago
Screw discipline, it’s a tooling problem. Making canary rollouts with automatic rollback the default would take a lot of investment up front, but then would make discipline at release time a non-factor.