4 ms·

> ... the general Rust practice of panicking upon unexpected conditions What makes you say this? From the sample I've seen, Rust programs are far more diligent

> ... the general Rust practice of panicking upon unexpected conditions What makes you say this? From the sample I've seen, Rust programs are far more diligent about handling errors (not panicking: either returning error or handling it explicitly) than C or Go programs due to the nature of wrapped types like Option<T> and Result<T, E>. You can't escape handling the error, and panicking potential is very easy to see and lint against with clippy in the code.

layer8 4y ago
I’m referring to the fact that ubiquitous functions like unwrap() panic if the programmer has made an error. Guarding against such panics is outside of the scope of Rust-the-language, and has to be handled through external means. There are linters for C as well.
- Veliladon 4y ago
  I think I prefer Rust's way of doing things. Just last night I used the Vec! macro incorrectly putting in a comma instead of a semi-colon and despite the program compiling correctly, it immediately panicked with an OOB error. With C it would have been a lot harder to even notice a bug little alone track it down.
  - layer8 4y ago
    Right. My personal opinion is that exceptions provide a better trade-off between catching bugs and still allowing the chance of graceful shutdown or recovery.
    - Veliladon 4y ago
      In my case it wouldn't have raised an exception though, it would have just been UB. It's not like there's not exceptions in Rust though. The error handling is thorough to a fault when it's used. Unwrap is just a shortcut to say "I know there might be bad input, I don't want to handle it right now, just let me do it and I'll accept the panic."
      - layer8 4y ago
        By exceptions, I’m referring to languages with exceptions as a dedicated language construct with automatic stack unwinding, and preferably without UB (e.g. Java or C#). Rust doesn’t have exceptions in that sense.
        dureuill 4y ago
        But panics in rust are pretty much exceptions though? The differences are they are actually meant to be used for exceptional situations ("assert violated => there's a bug in this program" or "out of memory, catastrophic runtime situation") and they are not typed (rather, the panic holds a type erased payload). Other than that, it performs unwinding without UB, and is catchable[0]. I'm not seeing the technical difference? [0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
        layer8 4y ago
        You’re probably right now that I’ve read up on it, I wasn’t previously aware of catch_unwind.
        dureuill 4y ago
        Glad to be of service. Note that the idiomatic error handling in rust is still Result based rather than panic/catch_unwind based. Nevertheless a long living application like, e.g., a webserver will catch panics coming from its subtasks (e.g., its request handlers) via catch_unwind
    - stjohnswarts 4y ago
      exceptions would be awful in the kernel. I would be highly surprised if kernels like fuscia allow c++ exceptions.
- hegelstoleit 4y ago
  Linters can catch panics, linters for C won't catch memory issues which is what rust prevents.
  - layer8 4y ago
    Linters like Splint [0] (predating Rust) can do that for C. I’m not saying that Rust’s built-in approach isn’t better, but please be careful about what exactly you claim. [0] http://splint.org/ http://splint.org/
    - dcsommer 4y ago
      Interesting that despite tools like Splint, 70% of high severity security vulns, including in well staffed projects like Chrome and Windows, are due to memory unsafety. The false negatives of security analysis tools are significant and are the very reason Rust got developed.
      - layer8 4y ago
        No, the reason Rust was developed (with regard to that aspect) was that the necessary static analysis is enforced by the compiler if it is built into the language, whereas otherwise (if not built in) it empirically doesn’t get a lot of adoption. There’s nothing Rust’s static analysis is doing that couldn’t be done with the same semantics using an external static analyzer and linter annotations. The ideas of Rust weren’t new when Rust was developed. The actual integration into a new programming language beyond experimental status was, and the combination with ML-style functional programming.
    - hegelstoleit 4y ago
      Splint doesn't make C memory safe. What I meant is that it doesn't prevent the same problems that Rust does. Hence, you can add a linter to rust to prevent panics. You cannot add a linter to C to make it memory safe.
- stjohnswarts 4y ago
  That's where linters and code reviews come in, you will never 100% prevent stupid coding, that's where review either automated and/or other coders and coding standards come in.
- tomjakubowski 4y ago
  > that ubiquitous functions like unwrap() panic if the programmer has made an error. You're not wrong but you chose a hilarious example. Unwrap's entire purpose is to turn unhandled errors into panics! Array indexing, arithmetic (with overflow-checks enabled), and slicing are examples where it's not so obvious there be panic dragons. Library code does sometimes panic in cases of truly unrecoverable errors also.

layer8 4y ago

I’m referring to the fact that ubiquitous functions like unwrap() panic if the programmer has made an error. Guarding against such panics is outside of the scope of Rust-the-language, and has to be handled through external means. There are linters for C as well.

Veliladon 4y ago
I think I prefer Rust's way of doing things. Just last night I used the Vec! macro incorrectly putting in a comma instead of a semi-colon and despite the program compiling correctly, it immediately panicked with an OOB error. With C it would have been a lot harder to even notice a bug little alone track it down.
- layer8 4y ago
  Right. My personal opinion is that exceptions provide a better trade-off between catching bugs and still allowing the chance of graceful shutdown or recovery.
  - Veliladon 4y ago
    In my case it wouldn't have raised an exception though, it would have just been UB. It's not like there's not exceptions in Rust though. The error handling is thorough to a fault when it's used. Unwrap is just a shortcut to say "I know there might be bad input, I don't want to handle it right now, just let me do it and I'll accept the panic."
    - layer8 4y ago
      By exceptions, I’m referring to languages with exceptions as a dedicated language construct with automatic stack unwinding, and preferably without UB (e.g. Java or C#). Rust doesn’t have exceptions in that sense.
      - dureuill 4y ago
        But panics in rust are pretty much exceptions though? The differences are they are actually meant to be used for exceptional situations ("assert violated => there's a bug in this program" or "out of memory, catastrophic runtime situation") and they are not typed (rather, the panic holds a type erased payload). Other than that, it performs unwinding without UB, and is catchable[0]. I'm not seeing the technical difference? [0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
        layer8 4y ago
        You’re probably right now that I’ve read up on it, I wasn’t previously aware of catch_unwind.
        dureuill 4y ago
        Glad to be of service. Note that the idiomatic error handling in rust is still Result based rather than panic/catch_unwind based. Nevertheless a long living application like, e.g., a webserver will catch panics coming from its subtasks (e.g., its request handlers) via catch_unwind
  - stjohnswarts 4y ago
    exceptions would be awful in the kernel. I would be highly surprised if kernels like fuscia allow c++ exceptions.
hegelstoleit 4y ago
Linters can catch panics, linters for C won't catch memory issues which is what rust prevents.
- layer8 4y ago
  Linters like Splint [0] (predating Rust) can do that for C. I’m not saying that Rust’s built-in approach isn’t better, but please be careful about what exactly you claim. [0] http://splint.org/ http://splint.org/
  - dcsommer 4y ago
    Interesting that despite tools like Splint, 70% of high severity security vulns, including in well staffed projects like Chrome and Windows, are due to memory unsafety. The false negatives of security analysis tools are significant and are the very reason Rust got developed.
    - layer8 4y ago
      No, the reason Rust was developed (with regard to that aspect) was that the necessary static analysis is enforced by the compiler if it is built into the language, whereas otherwise (if not built in) it empirically doesn’t get a lot of adoption. There’s nothing Rust’s static analysis is doing that couldn’t be done with the same semantics using an external static analyzer and linter annotations. The ideas of Rust weren’t new when Rust was developed. The actual integration into a new programming language beyond experimental status was, and the combination with ML-style functional programming.
  - hegelstoleit 4y ago
    Splint doesn't make C memory safe. What I meant is that it doesn't prevent the same problems that Rust does. Hence, you can add a linter to rust to prevent panics. You cannot add a linter to C to make it memory safe.
stjohnswarts 4y ago
That's where linters and code reviews come in, you will never 100% prevent stupid coding, that's where review either automated and/or other coders and coding standards come in.
tomjakubowski 4y ago
> that ubiquitous functions like unwrap() panic if the programmer has made an error. You're not wrong but you chose a hilarious example. Unwrap's entire purpose is to turn unhandled errors into panics! Array indexing, arithmetic (with overflow-checks enabled), and slicing are examples where it's not so obvious there be panic dragons. Library code does sometimes panic in cases of truly unrecoverable errors also.