Yeah, we struggled with how to do errors right in Rust for a long time, and it's really interesting to see that we almost ended up in the same place as Midori. The main differences are:

- Midori (and Swift) uses effects instead of monadic types (probably good, since we dodge the interactions with generics described at the end, but the "throws" syntax is so sweet);

- Rust uses a return codes implementation instead of an unwinding implementation (for simplicity's sake; some Rust users really don't like unwinding, for legitimate reasons in many cases, but Midori's arguments in favor of unwinding are compelling);

- Rust lets you catch panics at thread boundaries (one of the most controversial decisions in Rust; I think it was the right one, but I definitely acknowledge that it's a big tradeoff).

> - Rust lets you catch panics at thread boundaries (one of the most controversial decisions in Rust; I think it was the right one, but I definitely acknowledge that it's a big tradeoff).

(Unstable) Rust lets you catch panics anywhere. You have to be able to do that for sane FFI - as you know (but perhaps other readers don't), a panic that unwinds across the Rust/C FFI boundary causes undefined behavior, so AIUI extern functions in Rust should all look like:

    pub extern "C" fn foo_the_quuxes(x: i32) -> i32 {
        std::catch_panic(|| do_stuff_in_rust_land_that_may_panic(x))
          .unwrap_or(-1)
    }

(Actually, checking several libraries off the top of my head that expose C APIs, most don't do this -- probably because std::catch_panic is relatively new.)

Let's hope developers don't abuse std::catch_panic for regular Rust code. Maybe a lint that warns about uses outside of an extern fn is worth having.

  > Let's hope developers don't abuse std::catch_panic for 
  > regular Rust code.

This has been taken into account on multiple occasions, and the developers have introduced mechanisms to prevent people from treating `recover` as a general error-handling mechanism: https://github.com/rust-lang/rfcs/pull/1323

> (Unstable) Rust lets you catch panics anywhere.

Note that you're replying to the original creator of Rust, he's most likely aware of that discussion.

Yes, I know pcwalton is and was heavily involved in Rust development. That's why I parenthetically stated that he probably already knew these things (catch_panic is actually newer than the bulk of pcwalton' work on Rust's language and standard library, so there is a small chance he doesn't know about it).

It's still worth noting this point though, for the benefit of other readers.

pcwalton has been heavily involved with Rust since long before anyone remembers, but you're confusing him with Graydon Hoare, Rust's true original author.

I am for some reason…

I guess it's a lot easier to have "unstoppable" panics if you have super isolated lightweight processes to begin with, instead of big, old, run-of-the-mill-operating-system processes filled with a whole lot of threads that don't all want to die. :V

With their Result type, Midori is really hammering home that Result/exception isomorphism. Is the interaction with generics really any worse than what we would have to write if we wanted a map function that optionally returns early if the closure returns Err?

fwiw, I always thought the biggest difference between Rust's scheme and regular exceptions were that in Rust you never unwind until a catch block since a `?` on its own at most returns from the current function, and now Midori goes and requires `try` on ever call of a possibly-throwing function and it ends up working out just the same...

The Rust community agrees that try! has worked out well. It's worked out so well, it's being promoted from a library-defined macro to a language-defined operator (not only to be more succinct, but also to integrate with other features that will extend its usefulness).

> I enjoy that Rust just decided to change their "try" syntax for calling a function that could possibly fail to a simpler "?" suffix, and now we get Duffy praising how well "try" worked out for them. :P

The Rust community did no such thing. The status of the RFC is currently that they will implement '?' as a gated feature (which is only available if you're on the nightly toolchain) and see if it is useful. If it's found to obfuscate the code like many people have suggested, then they will take it back out.