4 ms·

One of the biggest issue with Rust’s panics is there’s many times when you must never panic. For example in an OS, when trying to save your crucial data to disk

One of the biggest issue with Rust’s panics is there’s many times when you must never panic. For example in an OS, when trying to save your crucial data to disk, in real-time code where panicking would maybe kill someone in the real world, etc

kibwen 6y ago
I don't really understand this criticism, because there's no good alternative. Every language is capable of producing invalid states that the programmer did not intend; consider `x / user_input()`. (Unless literally every possible invariant of the program is expressed in the type system, which is not something that we have figured out how to do at scale and not something that even the most type-heavy of the popular languages come anywhere close to.) And once you're in an invalid/unanticipated state, you either crash or you don't. Of the two options, the latter is far worse (On Error Resume Next, anyone?), and is just as likely to lose data/get someone killed.
- masklinn 6y ago
  > I don't really understand this criticism, because there's no good alternative. There's the option of surfacing the panic-ability of a function in the same way the constness is surfaced, which would allow some subsets of the code to ensure they won't call a possibly-panicing thing, even at the cost of convenience.
  - a1369209993 6y ago
    In the cases where the problem is actually panicing (ie, a non-total function) rather than your choice of core-dumping code, lack of panic-ability is strictly insufficient - `while(1){/*busy-loop*/}` is exactly as bad as `panic();`, and what you actually need is not "must never panic", it's "must make forward progress within some (not necessarily rigorously defined but) small amount of time". That doesn't have anything to do with panic besides that `panic` would be declared as `fn(string)->noreturn[takes_upto: (infinity * seconds)];`, rather than just `fn(string)->noreturn`. (And really, noreturn ought to be enough to infer that on its own.)
    - masklinn 6y ago
      > lack of panic-ability is strictly insufficient Sure. It is also by far the largest risk you face, so would solve a good 4 or 5 nines if the issue. > And really, noreturn ought to be enough to infer that on its own. noreturn only works for functions which never return. Most panicking functions do return, just not all the time.
      - a1369209993 6y ago
        > noreturn only works for functions which never return. Most panicking functions do return, just not all the time. Sorry, I meant that any function that was noreturn could be inferred to take up to forever to return (since it always takes forever to return, since it never returns). Then, any function that calls such a function (in a non-DCEed position) can be inferred to also take up to forever to return (even though it might take less than that), because some possible code path through it (it's up to X amount of time to return) takes forever due calling a function that takes forever.
        masklinn 6y ago
        That is true, although I don't know how helpful that is aside from checking that the annotation is not broken? Much like `const`, the annotation would have to be opt-in either way: * Rust doesn't infer function types (on purpose) * like const (or Copy), the removal of the flag is a breaking change, so it should not happen implicitly So functions would necessarily have to be explicitly marked as e.g. `convergent` or whatever. And while callers of `!`-functions would be easy to check for, I don't think rustc is currently smart enough to infer the totality loops in general.
        a1369209993 6y ago
        > Rust doesn't infer function types (on purpose) > I don't think rustc is currently smart enough to infer the totality loops in general. Well, yes; we're necessarily talking about changes to the language (or, equivalently, possible different languages). > while callers of `!`-functions would be easy to check for, [other problems wouldn't] That was my point, thanks: "when trying to save your crucial data to disk, in real-time code where panicking would maybe kill someone in the real world, etc", checking for the easy-to-check-for problems doesn't actually suffice to prevent disasters.
- mlindner 6y ago
  So you want your kernel to panic whenever it runs out of memory?
  - xxpor 6y ago
    Yes, for servers! Hard failures are much easier to deal with than soft-not-dead-but-still-useless states. echo 1 > proc/sys/vm/panic_on_oom
    - mlindner 6y ago
      Interesting. The company I just left sells a load balancer/application server/do-everything-box and one of the rules of the coding is that it must never crash. Even out of memory errors need to be recovered from and we shut off the kernel feature that makes malloc not actually malloc memory.

kibwen 6y ago

I don't really understand this criticism, because there's no good alternative. Every language is capable of producing invalid states that the programmer did not intend; consider `x / user_input()`. (Unless literally every possible invariant of the program is expressed in the type system, which is not something that we have figured out how to do at scale and not something that even the most type-heavy of the popular languages come anywhere close to.) And once you're in an invalid/unanticipated state, you either crash or you don't. Of the two options, the latter is far worse (On Error Resume Next, anyone?), and is just as likely to lose data/get someone killed.

masklinn 6y ago
> I don't really understand this criticism, because there's no good alternative. There's the option of surfacing the panic-ability of a function in the same way the constness is surfaced, which would allow some subsets of the code to ensure they won't call a possibly-panicing thing, even at the cost of convenience.
- a1369209993 6y ago
  In the cases where the problem is actually panicing (ie, a non-total function) rather than your choice of core-dumping code, lack of panic-ability is strictly insufficient - `while(1){/*busy-loop*/}` is exactly as bad as `panic();`, and what you actually need is not "must never panic", it's "must make forward progress within some (not necessarily rigorously defined but) small amount of time". That doesn't have anything to do with panic besides that `panic` would be declared as `fn(string)->noreturn[takes_upto: (infinity * seconds)];`, rather than just `fn(string)->noreturn`. (And really, noreturn ought to be enough to infer that on its own.)
  - masklinn 6y ago
    > lack of panic-ability is strictly insufficient Sure. It is also by far the largest risk you face, so would solve a good 4 or 5 nines if the issue. > And really, noreturn ought to be enough to infer that on its own. noreturn only works for functions which never return. Most panicking functions do return, just not all the time.
    - a1369209993 6y ago
      > noreturn only works for functions which never return. Most panicking functions do return, just not all the time. Sorry, I meant that any function that was noreturn could be inferred to take up to forever to return (since it always takes forever to return, since it never returns). Then, any function that calls such a function (in a non-DCEed position) can be inferred to also take up to forever to return (even though it might take less than that), because some possible code path through it (it's up to X amount of time to return) takes forever due calling a function that takes forever.
      - masklinn 6y ago
        That is true, although I don't know how helpful that is aside from checking that the annotation is not broken? Much like `const`, the annotation would have to be opt-in either way: * Rust doesn't infer function types (on purpose) * like const (or Copy), the removal of the flag is a breaking change, so it should not happen implicitly So functions would necessarily have to be explicitly marked as e.g. `convergent` or whatever. And while callers of `!`-functions would be easy to check for, I don't think rustc is currently smart enough to infer the totality loops in general.
        a1369209993 6y ago
        > Rust doesn't infer function types (on purpose) > I don't think rustc is currently smart enough to infer the totality loops in general. Well, yes; we're necessarily talking about changes to the language (or, equivalently, possible different languages). > while callers of `!`-functions would be easy to check for, [other problems wouldn't] That was my point, thanks: "when trying to save your crucial data to disk, in real-time code where panicking would maybe kill someone in the real world, etc", checking for the easy-to-check-for problems doesn't actually suffice to prevent disasters.
mlindner 6y ago
So you want your kernel to panic whenever it runs out of memory?
- xxpor 6y ago
  Yes, for servers! Hard failures are much easier to deal with than soft-not-dead-but-still-useless states. echo 1 > proc/sys/vm/panic_on_oom
  - mlindner 6y ago
    Interesting. The company I just left sells a load balancer/application server/do-everything-box and one of the rules of the coding is that it must never crash. Even out of memory errors need to be recovered from and we shut off the kernel feature that makes malloc not actually malloc memory.