3 ms·

Hot Take: Rust Panic's are about as bad as Sig11s from the C world. I don't get good debug information in the typical case - and library authors get to decide w

• frfl 3y ago
  Definitely a "hot take".
• threatofrain 3y ago
  On a tangent — for a numeric library, would you rather NaN or throw? I find a fair amount of division over this question, but people lean towards throw over NaN.
  • truculent 3y ago
    If the operation can fail, that should really be represented in the type, right?
    • zokier 3y ago
      One of my random thoughts is that floats could be represented as enums in type system, e.g. in rust-like syntax: #[repr(f32)] enum Float32 { PositiveInfinity, NegativeInfinity, Nan(NanPayload32), Finite(FiniteFloat32), } You could also then define NonNanFloat32 etc which could be used for certain operations. Of course on machine level its all the same
      • truculent 3y ago
        Yeah, I think something like this would make sense. I get why people might not like it, but this is what we’re dealing with whether we like it or not.
    • brabel 3y ago
      No necessarily. Rust doesn't do that for array indexing (though bound checking is enabled at runtime and will panic if out of bounds), division by zero, numeric overflow and probably many cases where it was deemed to be just too cumbersome.
      • truculent 3y ago
        True, but iirc Rust also supplies a `get` method for when you want to get elements safely.
  • pocketarc 3y ago
    I'd definitely go with throw - it's indicative of a logic bug, and I'd rather notice it during dev (or if not, catch in prod, complete with stack trace and whatnot), than to have it silently corrupting anything that relies on that calculation happening correctly, without me even being aware of it. Like, if I'm doing x + y, and y just accidentally happens to contain the wrong data because of a mistake in the code, a NaN means the code will proceed as normal, and nobody will notice anything is wrong. If it's not a noticeable bug, it might be a long time until it's spotted by someone. And when they do, who knows how much damage it will have caused.
    • lumost 3y ago
      I'd always go with NaN. In dataprocessing, it's common to encounter NaNs due to bad data - these records can be filtered out to allow the process to continue. The records which resulted in NaN can be flagged for follow-up. As a program author, I'd expect that it's my choice how to handle this situation. I don't want libraries making arbitrary decisions about how my code should work.
• ben0x539 3y ago
  You're not supposed to be afraid of segfaults, you're supposed to be afraid of the incorrect memory accesses that don't get caught by segfaults.
  • corethree 3y ago
    Yeah, the problem is when one of these faults comes from a 3rd party library and doesn't include stack trace info.