
The Error Model in Midori - jsnell
http://joeduffyblog.com/2016/02/07/the-error-model/
======
ben0x539
As is usual the Rust crowd is excited about the shoutouts and the
applicability of the consideration to Rust's analogue.

In particular, 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

~~~
pcwalton
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).

~~~
tomjakubowski
> \- 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.

~~~
masklinn
> (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.

~~~
kibwen
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.

~~~
masklinn
I am for some reason…

------
mwcampbell
They got as far as porting the Microsoft Speech Server, for multiple
languages, yet the project was canceled. That's really sad.

~~~
sciurus
They accomplished a lot!

[http://joeduffyblog.com/2015/11/03/blogging-about-
midori/](http://joeduffyblog.com/2015/11/03/blogging-about-midori/)

------
vvanders
Kind if surprised with all mentions if reliability and lightweight processes
that there was no mention of Erlang.

~~~
glibgil
Did you read the following paragraph and the section on Abandonment? Erlang
isn't mentioned by named, but the problem domain is.

"I expect more of the world to adopt this philosophy as the shift to more
distributed computing happens. In a cluster of microservices, for example, the
failure of a single container is often handled seamlessly by the enclosing
cluster management software (Kubernetes, Amazon EC2 Container Service, Docker
Swarm, etc). As a result, what I describe in this post is possibly helpful for
writing more reliable Java, Node.js/JavaScript, Python, and even Ruby
services. The unfortunate news is you’re likely going to be fighting your
languages to get there. A lot of code in your process is going to work real
damn hard to keep limping along when something goes awry."

~~~
vvanders
Yup read that part and that's exactly my point.

The author hammers home how important abandonment is in a light threaded
system without any mention of all the work that Erlang has been doing for
years in that space. Given how much reference there is to Rust, Go and a host
of other languages I would at least expect Erlang to be mentioned.

~~~
igravious
The frequency of the mentions of Go made me prick up my ears so I've done a
frequency analysis of language mentions:

    
    
       Midori: 31
       Go:     27
       C++:    27
       C:      18
       Rust:   10
       Swift:  03
       D:      02
       Scala:  02
    

None for Erlang! Could it be said that Joe Duffy is focussing on statically
typed languages or systems programming languages? Interesting that Go is most
referenced, not C++ :)

------
junke
> Bugs Aren’t Recoverable Errors!

This is true in the context of Midori but not in general. In a dynamic
environment, you recompile your buggy function and continue working.

------
dllthomas
> Maybe statistical correctness is okay for scripting languages, but for the
> lowest levels of an operating system, or any mission critical application or
> service, this isn’t an appropriate solution. I hope this isn’t
> controversial.

I would say that in any case, statistical correctness is all you can have.
It's a bit of a nitpick, though, as it certainly doesn't mean that it can't be
some orders of magnitude more likely.

(Which point the author seems to make, himself, later in the essay.)

------
ikurei
> "This distinction [between bugs and recoverable errors] is paramount.
> Surprisingly, most systems don’t make one, at least not in a principled way!
> As we saw above, Java, C#, and dynamic languages just use exceptions for
> everything; and C and Go use return codes."

Not a Java programmer, but isn't that what RuntimeException is for? Yeah, Java
uses exceptions for both errors and recoverable errors, but it can use
_different_ exceptions.

~~~
swsieber
You'd like to think that, but they can be caught and used just like other
exceptions. The one caveat is that you can't force code to account for
potential RuntimeException's. With things like an IOException, the code has to
account for the possibility that the exception will be thrown.

So, they are a little different, but the tooling for them is pretty much the
same, greatly diminishing the effect.

------
alexeiz
A huge post. He just keeps piling on one thing on top of another and another
and another. Many topics should be discussed separately. There is a lot of
information. And yet, I feel that critical topics are misunderstood.

------
norswap
Does anyone know if they plan to release any of this stuff as open source?

------
teekert
This is kind of confusing when you start reading the article thinking it is
about the Midori browser [0] while it is actually: "Midori was a
research/incubation project to explore ways of innovating throughout
Microsoft’s software stack." [1]

[0][http://midori-browser.org/](http://midori-browser.org/)

[1] [http://joeduffyblog.com/2015/11/03/blogging-about-
midori/](http://joeduffyblog.com/2015/11/03/blogging-about-midori/)

~~~
Razengan
Why do the Midori Browser screenshots look like they're a Mac app and yet the
download page says it's not available for OS X?

~~~
teekert
Yeah, a bit stupid, they even showcase the browser on macs only (guess they
like the clean look). It's a GTK app, Gnome3 apps do look similar to osX apps.
The full screen button though, it is very out of place. It is problably the
result of using it on Elementary OS (where it is de default browser), a Linux
distro that aims to emulate osX. [0]

[0] [https://elementary.io/](https://elementary.io/)

------
nickysielicki
His earliest blog post on this is from November. Midori the web browser, which
I figured this would be about, was first released in 2007.

I don't understand how this type of name overlap happens. It's got to be of
the, "Yeah, I know this obscure name is already used for an open source
project and I just don't care" variety.

~~~
throwaway_xgqtr
> "Yeah, I know this obscure name is already used for an open source project
> and I just don't care"

Curious how you jump to this conclusion. Not to burst your bubble, but the
overwhelming majority of programmers even have likely never heard of the
Midori browser. Additionally, the Midori browser did not invent this word, it
is a Japanese word...and also the name of a band, the name of an olympic
figure skater, the name of a liquor, all predating the browser.

Why on earth would people working on an internal Microsoft project go
searching for obscure open source projects that might be using the same name
before agreeing to move forward with the name?

~~~
nickysielicki
I have nothing to say to that. You're 100% right.

~~~
13of40
FWIW, I recall there was a terminal emulator called Power Shell back in the
day. I don't know if we bought the name or...500 lb. Gorilla...

