9 ms·

Rust's error handling looks like the Maybe monad. That seems pretty reasonable in Haskell. I'm a little surprised by the criticism in the article — is the autho

• steveklabnik 12y ago
  It's similar. We don't have HKT, so we can't get fully generic monads, but you can implement specific instances, like we have with Option/Result.
  • mafribe 12y ago
    Steve, what's the reason that Rust doesn't have HKTs (higher-kinded types). Is there a technical barrier, e.g. to do with life-time inference, or is it a philosophical choice not to have them?
    • steveklabnik 12y ago
      It's one of our most requested features (and would be really good for collections) but it should be backwards compatible and therefore was postponed until after 1.0. Nobody has put in the work to actually make a formal RFC yet either, which is required.
      • NotableAlamode 12y ago
        Is anybody actively working on this? I suspect that doing this well is non-trivial. Neither Tofte/Talpin nor Cyclone, both of which heavily inspired Rust's lifetimes, have HKTs as far as I'm aware.
        • steveklabnik 12y ago
          Everything is focused on shipping a good 1.0, so no.
          • NotableAlamode 12y ago
            I understand that 1.0 was / is a priority. But I wonder what the state of discussions about HKTs in Rust is: is this addition believed to be an easy problem in the sense that it may be a lot of work, but no major roadblocks are expected? Or are there open questions that require substantial research?
            • steveklabnik 12y ago
              The state is, "this should be backwards compatible, therefore, we don't need to think about it more until after 1.0." That's pretty much it. There isn't an active discussion, because we're actively discussing the things needed to ship 1.0.
• falcolas 12y ago
  My experience mirrors the author's: it results in a lot of use of macros and case statements. These create a fair bit of cognitive overhead to discern what the program flow will end up being, and special syntax for unpacking values. The broad use of case statements leads to one more odd problem - knowing when, and when not, to use a `;`. Explicit returns are frowned upon, they prefer the "results from the last expression" form of returns. The `;` results in an expression returning a different value and a different type. The type system will usually catch these errors and print a helpful "perhaps you should remove the ';' from this line" message, but it's an extra bit of cognitive overhead induced by case statements. Ultimately, I think it's less about missing syntactic sugar, and more about the type system acting like an electric fence instead of a hedge in its efforts to guide the user to their destination.
  • pcwalton 12y ago
    > Explicit returns are frowned upon That's not true in any of the code I write. I prefer explicit returns in all of my Rust code. The only time I use the "result from last expression" return is when it's the last statement in the function. The recommended way to deal with errors in Rust is "try!". Using "try!" essentially gives you the ergonomics of exceptions. You should prefer that to match or .and_then(), which are verbose.
  • burntsushi 12y ago
    Explicit returns are not frowned upon. I don't know where you got that idea. The only thing I can think is that this: fn foo() -> bool { true } is preferred over fn foo() -> bool { return true } But that's more of a style issue. As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I love it.
    • falcolas 12y ago
      > Explicit returns are not frowned upon. I don't know where you got that idea From the docs: http://doc.rust-lang.org/book/functions.html http://doc.rust-lang.org/book/functions.html > Using a `return` as the last line of a function works, but is considered poor style