6 ms·

IMHO, unwrap() , expect() and company, has infected the Rust language so deeply that one wonders when (and not "if") will a library send a panic and crash the w

by drtgh 2y ago

IMHO, unwrap() , expect() and company, has infected the Rust language so deeply that one wonders when (and not "if") will a library send a panic and crash the whole program. How could be erased those panic! methods that are used in most of Rust's libraries is something that may be is beyond the possible? beside is promoted from all the Rust's tutorials and reference code. So much correctness in the Rust language just for to promote to all the community to crash the program from libraries without handling the error is something I can not understand. I hope this philosophy do not reach the Linux kernel.

db48x 2y ago
What does this have to do with anything?
- diggan 2y ago
  Trying to figure this out as well... Tests have a bunch of .expect and .unwrap (which is to be expected), but core logic of the library doesn't seem to have any that seems they'll get in the way?
- hypeatei 2y ago
  It's done in bad faith. Some are vehemently against Rust because of the "culture" around criticizing other languages' memory safety models, namely C/C++.
  - db48x 2y ago
    You may be right.
    - drtgh 2y ago
      It is not the case, not bad faith intended. To think it is a protest may be nearer. Build in release a hello world, Build in release the example of this library (replacing the assert_eq by a println!("{}", zoned) or other ), or even a different library if it have a large dependence tree. Open on a text editor both files. The presence of the string messages for "unwrap" increased, right? One can observe the code in this library take care of making reach the user the errors in most the parts of the library, so: how was increased the string messages for "unwrap"? How can one know from were they came from? One ends up having to read all the dependencies^5, from were almost always a unwrap() reach the runtime of the release build.
aw1621107 2y ago
> How could be erased those panic! methods that are used in most of Rust's libraries is something that may be is beyond the possible? It's arguably quite possible, though not as straightforwards as one may hope. For example, there's no_panic, which results in a linker error if the compiler cannot prove a function cannot panic [0], albeit with some caveats. > So much correctness in the Rust language just for to promote to all the community to crash the program from libraries without handling the error is something I can not understand. Is there that much "promoting" of unchecked unwrap()/expect()/etc. going on? How do you distinguish that from "genuine" cases of violations of the programmer's assumptions? I ask because Result/? along with libraries like thiserror/anyhow/etc. are right there and arguably easier/more concise, so unwarranted unwrap()/etc. would seem "harder" to write/justify than the alternative. The main exception I can think of are more one-off cases where the author is intentionally sacrificing robust error handling for the sake of speed/convenience, but that's a more language-agnostic thing that pretty much "doesn't count" by definition. > I hope this philosophy do not reach the Linux kernel. IIRC this is being worked on, especially given Linus's position on panics in the kernel. [0]: https://github.com/dtolnay/no-panic https://github.com/dtolnay/no-panic
- drtgh 2y ago
  > Is there that much "promoting" of unchecked unwrap()/expect()/etc. going on? How do you distinguish that from "genuine" cases of violations of the programmer's assumptions? More like promoted indirectly, I think by being used widely on reference code and tutorials the programmers absorbs as a familiar and quick to write method without planning much. And at same time by not being actively promoted that such methods should not be used within a library runtime or similar at least, because many people do not see it as wrong, what convert it in philosophy I guess. When the dependency chain of library loading is fired, almost always I checked some unwrap ends within the program's runtime, so distinguishing whether those are genuine cases of violations (IMHO they can't be genuine if a lib can panic the program), or if it was just a unfinished prototyping part or etc, I think is not exactly important as individual until it reach terms of generalized behavior along the language libraries, and even seen in some programs of the community. > IIRC this is being worked on, especially given Linus's position on panics in the kernel. These are good news
burntsushi 2y ago
Eh? There isn't a single unwrap/expect in the examples at the top level crate documentation. There should be very few overall. But there are hundreds of executable doctests, so there are certainly some unwraps. But I've already opined on this topic: https://blog.burntsushi.net/unwrap/ https://blog.burntsushi.net/unwrap/
the_mitsuhiko 2y ago
That is not my experience at all. It’s very rare that libraries unwrap. Beyond example code and tests I rarely see unwrap.
bigstrat2003 2y ago
> I hope this philosophy do not reach the Linux kernel. Well, I hope it does. Albeit it almost certainly will not, because Linus is opposed to it. But ever since I read Joe Duffy's blog posts on the Midori research project at MS, I have been convinced that using panics leads to increased reliability, not decreased. From his blog[1]: "Given that bugs are inherently not recoverable, we made no attempt to try. All bugs detected at runtime caused something called abandonment, which was Midori’s term for something otherwise known as “fail-fast”." And: "Abandonment, and the degree to which we used it, was in my opinion our biggest and most successful bet with the Error Model. We found bugs early and often, where they are easiest to diagnose and fix." I think that the Midori team's work shows that a practice of "there's a bug, stop everything" leads to more reliable software. Sure, there's an initial period of pain where you're fixing a ton of bugs as they cause the software to panic. But you reap the rewards of that effort. I don't think Linux will ever move towards a model like this, but I think it would be beneficial in the end if they did. 1: https://joeduffyblog.com/2016/02/07/the-error-model/#bugs-arent-recoverable-errors https://joeduffyblog.com/2016/02/07/the-error-model/#bugs-ar...

by drtgh 2y ago

db48x 2y ago

What does this have to do with anything?

diggan 2y ago
Trying to figure this out as well... Tests have a bunch of .expect and .unwrap (which is to be expected), but core logic of the library doesn't seem to have any that seems they'll get in the way?
hypeatei 2y ago
It's done in bad faith. Some are vehemently against Rust because of the "culture" around criticizing other languages' memory safety models, namely C/C++.
- db48x 2y ago
  You may be right.
  - drtgh 2y ago
    It is not the case, not bad faith intended. To think it is a protest may be nearer. Build in release a hello world, Build in release the example of this library (replacing the assert_eq by a println!("{}", zoned) or other ), or even a different library if it have a large dependence tree. Open on a text editor both files. The presence of the string messages for "unwrap" increased, right? One can observe the code in this library take care of making reach the user the errors in most the parts of the library, so: how was increased the string messages for "unwrap"? How can one know from were they came from? One ends up having to read all the dependencies^5, from were almost always a unwrap() reach the runtime of the release build.

aw1621107 2y ago

> How could be erased those panic! methods that are used in most of Rust's libraries is something that may be is beyond the possible? It's arguably quite possible, though not as straightforwards as one may hope. For example, there's no_panic, which results in a linker error if the compiler cannot prove a function cannot panic [0], albeit with some caveats. > So much correctness in the Rust language just for to promote to all the community to crash the program from libraries without handling the error is something I can not understand. Is there that much "promoting" of unchecked unwrap()/expect()/etc. going on? How do you distinguish that from "genuine" cases of violations of the programmer's assumptions? I ask because Result/? along with libraries like thiserror/anyhow/etc. are right there and arguably easier/more concise, so unwarranted unwrap()/etc. would seem "harder" to write/justify than the alternative. The main exception I can think of are more one-off cases where the author is intentionally sacrificing robust error handling for the sake of speed/convenience, but that's a more language-agnostic thing that pretty much "doesn't count" by definition. > I hope this philosophy do not reach the Linux kernel. IIRC this is being worked on, especially given Linus's position on panics in the kernel. [0]: https://github.com/dtolnay/no-panic https://github.com/dtolnay/no-panic

drtgh 2y ago
> Is there that much "promoting" of unchecked unwrap()/expect()/etc. going on? How do you distinguish that from "genuine" cases of violations of the programmer's assumptions? More like promoted indirectly, I think by being used widely on reference code and tutorials the programmers absorbs as a familiar and quick to write method without planning much. And at same time by not being actively promoted that such methods should not be used within a library runtime or similar at least, because many people do not see it as wrong, what convert it in philosophy I guess. When the dependency chain of library loading is fired, almost always I checked some unwrap ends within the program's runtime, so distinguishing whether those are genuine cases of violations (IMHO they can't be genuine if a lib can panic the program), or if it was just a unfinished prototyping part or etc, I think is not exactly important as individual until it reach terms of generalized behavior along the language libraries, and even seen in some programs of the community. > IIRC this is being worked on, especially given Linus's position on panics in the kernel. These are good news

burntsushi 2y ago

Eh? There isn't a single unwrap/expect in the examples at the top level crate documentation. There should be very few overall. But there are hundreds of executable doctests, so there are certainly some unwraps. But I've already opined on this topic: https://blog.burntsushi.net/unwrap/ https://blog.burntsushi.net/unwrap/

the_mitsuhiko 2y ago

That is not my experience at all. It’s very rare that libraries unwrap. Beyond example code and tests I rarely see unwrap.

bigstrat2003 2y ago

> I hope this philosophy do not reach the Linux kernel. Well, I hope it does. Albeit it almost certainly will not, because Linus is opposed to it. But ever since I read Joe Duffy's blog posts on the Midori research project at MS, I have been convinced that using panics leads to increased reliability, not decreased. From his blog[1]: "Given that bugs are inherently not recoverable, we made no attempt to try. All bugs detected at runtime caused something called abandonment, which was Midori’s term for something otherwise known as “fail-fast”." And: "Abandonment, and the degree to which we used it, was in my opinion our biggest and most successful bet with the Error Model. We found bugs early and often, where they are easiest to diagnose and fix." I think that the Midori team's work shows that a practice of "there's a bug, stop everything" leads to more reliable software. Sure, there's an initial period of pain where you're fixing a ton of bugs as they cause the software to panic. But you reap the rewards of that effort. I don't think Linux will ever move towards a model like this, but I think it would be beneficial in the end if they did. 1: https://joeduffyblog.com/2016/02/07/the-error-model/#bugs-arent-recoverable-errors https://joeduffyblog.com/2016/02/07/the-error-model/#bugs-ar...