undefined | Better HN

0 pointsburntsushi3y ago0 comments

That all sounds fine and good. Of course assurance that there are no panics has practical benefits. Sign me up.

I'm still not sure what that has to do with complaining that Rust makes it too easy to panic. What's the alternative? If you're suggesting "garbage-in-garbage-out" everywhere, then I don't think that's a plausible answer for things like 'slice[i]' or 'RefCell::borrow()'. Whether garbage-in-garbage-out makes sense as a strategy depends a lot of the specifics of the situation. (And your polygon example sounds like one of those.) But that to me doesn't suggest something systemically wrong with the frequency of panicking branches in Rust code.

0 comments

2 comments · 1 top-level

pornel3y ago· 1 in thread

The alternative is to have control, so you can choose (and enforce) the right strategy for your context: unwinding, or aborting, or only infallible/Result/GIGO (with turning `slice[i]` and `RefCell::borrow()` into compile-time errors where necessary). Rust's default of "anything can unwind anywhere at any time time" is just one of these strategies, and it's not always the right one. And when it's not the right one, it does create a "mine field" as the OP says.

burntsushiOP3y ago

I think I see what you're saying now. I guess time will tell, but I don't think the alternative you pose will get rid of the so-called "mine field." So I still stand by what I said: complaining about too many panics is like complaining about too many bugs. I think a different complaint, i.e., "Rust doesn't give enough visibility and control with respect to panics," is a different story entirely and is valid. (Although I don't particularly suffer from its absence.) With that said, it would be cool to have the level of control you're talking about, but it's not clear to me the extra language complexity required for it is worth it. But hard to say at just a conceptual level.

j / k navigate · click thread line to collapse