> And if I write a "Rust: The Bad Parts", believe me, I'll be mentioning panicking.<p>This is why `panic=abort` should be the default, and the whole unwind-and-try-to-keep-the-world-sound path should be opt-in. Then panic is truly like `assert` and I'm guessing most of his objections would be gone.<p>My guess about default-panic behavior being unwind is rust's origins in the servo project. When you're part of a very large monolith that should try very hard not to crash (a browser), you will put some work in to try to make this unwinding okay. Yes, tests still want panic to unwind, but you could opt in to this to, or change the default in a `[test]` context, or a bunch of other things I'm sure smarter folks could argue in an RFC. But getting correctness right in prod should be goal #1 IMO, so it should bias toward abort.<p>For most places rust is probably actually used today (server-side), crashing is the safer and simpler behavior, and things like lock poisioning are not things you need to reason though.<p>I know the article is about Haskell, so not trying to derail it, but I have a really similar Haskell -> Rust path in my background, so a lot of the rest of Michael's reactions here are just +1 for me. For example, yes, exactly this about partial functions.<p>And, IMO, laziness, which he hints at in this section. The default should be the other way. Nothing worse than an `error` that's fired in some unexpected place/time due to lazy evaluation, and some thunk landed somewhere technically correct, but infuriating. Trying to figure out what the heck is going on can be really challenging/frustrating (as of my prod experience in Haskell 8-11 years ago, not sure what's gotten better/worse since then in ghc-land.)<p>I learned a <i>ton</i> from Haskell, and am so glad I used it in depth for awhile (ditto ML). But these days, to actually build something I want to build with long-term value in mind, either individually or as part of a team, I just use Rust. I get most of what I loved about Haskell without the annoyances.