Hacker News Reader

Comment by steveklabnik | Hacker News Reader

The Rust language knows nothing about the heap.

The standard library does assume this, but it's not an inherent language issue. Most people who are in resource constrained environments won't be using the standard library anyway.

View on HN

Rust also made the same mistake that Go did: it tried to appease the "exceptions are bad" crowd and ended up adding exceptions as an afterthought. I'm angry: Rust is merely good, but with a few early tweaks, it could have been great.

Rust does not have exceptions, not even in the limited capacity that Go sort-of has. It's legal for a Rust implementation to translate panics into aborts, which means that they cannot be relied upon as an error-handling mechanism. Furthermore, the means to halt unwinding in Rust exists only to prevent memory unsafety from occurring when Rust is embedded in another language via the C interface, because unwinding across an FFI boundary is undefined behavior. In fact the exact mechanism used in the aforementioned role has deliberately arbitrary restrictions placed upon it in order to prevent anyone from using it as a general-purpose error-handling mechanism. Finally, the prevailing Rust culture overwhelmingly discourages using anything other than Result for error handling, to such an extreme that I've never in all my days even seen anyone attempt to "catch" a panic as an error-recovery mechanism.

https://doc.rust-lang.org/beta/std/panic/fn.recover.html looks a lot like catch to me. That the documentation suggests not using it as "catch" is merely a political statement. While it may be legal to turn panics into abort, I doubt implementations will do that, because by doing so, you'll break programs that assume that panic recovery works.

The reason Rust's standard library isn't safe against malloc failure is that propagating Error everywhere would be cumbersome; I distinctly recall rust mailing list discussions on this point.

The only reason handling allocation failure has to be difficult is that the Rust people put themselves into giving into the anti-exception people. Once you allow exceptions, allocation failure becomes as easy to address as any other kind of resource exhaustion.

The Rust designers made a serious error eschewing the only fully general and fully ergonomic error handling strategy we've found.

Implementations will do that, e.g. https://github.com/rust-lang/rfcs/pull/1513 .

Encouraging this style of programming makes me sad.

This isn't a style of programming, it's a compiler flag for end-users. There's a reason that GCC and Clang have the -fno-exceptions flag.

The -fno-exceptions flag also makes me sad, because it encourages people to write libraries that are worse than they could be purely for the sake of interacting with code that chooses not to use an important feature of the language. Exception support should not be optional.

  > the Rust people put themselves into giving into the 
  > anti-exception people

It's a shame that you characterize design decisions as "giving into" the crowd instead of trying to understand why the decision might make sense in the context of Rust. Designing the error handling story was a discussion that spanned years, with dozens of discussions, many implementations, and likely hundreds of participants.

  > That the documentation suggests not using it as "catch" 
  > is merely a political statement

It's not just political, note the "RecoverSafe" bound on the type parameter. See https://doc.rust-lang.org/nightly/std/panic/trait.RecoverSaf...

What's wrong with Rust's error-handling mechanism (namely, the `Result` type)? Generally when writing Rust, panics only come up when you actively invite them with something like an `.unwrap()` call or the `try!` macro, which is Decidedly Bad Style for anything serious.

The `try!` macro never causes panics, it uses the `Result` type as is typical for error handling in Rust.

Reply on news.ycombinator.com