
The Game of Distributed Systems Programming. Which Level Are You? - nicolast
http://blog.incubaid.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/
======
pvanroy
This is a very nice classification. It does ring true in my experience,
although I would put a few more levels between level 3 and level 4. Very few
people are anywhere near level 4.

Your level 3 makes a few "level 2 mistakes". For example, time outs are evil,
since they force a decision to be made at the wrong level of the system.
Protocol stacks shouldn't use time outs. Rather, they should pass the request
to stop or continue waiting to the right level of the system (which can go all
the way up to the application level and even to the user level!).
Unfortunately, the most-used protocol stacks either don't implement this or
it's not exposed to the application programmer. And so we still have a long
way to go.

~~~
nicolast
The 'timeout' as referred to in the list of possible actions ('schedule a
timeout') refers to the timeout mechanism used to implement master election in
Arakoon, our product on which some of the experience in the article is based,
where we attempt to be at level 3 in the rewrite we're currently working on.

When this action is evaluated (in the impure part of the system), an action
will be scheduled with the threading system for execution sometime later, at
which point some new message will be sent through the machinery, just like any
other message received from another node on the network.

It's not about timeouts on message transmission or anything alike.

------
setori88
Im pretty certain that the 'final' level that he talks about doesn't make use
of timeouts, but stream monitors that raise temp fault, perm failure and okay
flags.

he makes no mention of streams nor of the concept of a port which (in oz) is
used to corden of nondeterminism.

------
sausagefeet
Does this mean channels, like in CSP (what Go does), are unfit for distributed
envs because they are synchronous?

~~~
nicolast
Why would CSP be 'synchronous'? There's a difference between how things appear
(API) and how the implementation works: it's certainly possible to have an API
which looks synchronous, yet everything is async at runtime. Think about
Haskell's do-notation with GHC's IO manager, the Erlang approach, something
like Gevent/Greenlets in Python,...

~~~
sausagefeet
Because, AFAIK, CSP is defined by synchronous message passing:

\- CSP message-passing fundamentally involves a rendezvous between the
processes involved in sending and receiving the message, i.e. the sender
cannot transmit a message until the receiver is ready to accept it.

\- Programs in the original CSP were written as a parallel composition of a
fixed number of sequential processes communicating with each other strictly
through synchronous message-passing.

\- The PAT process language extends CSP with support for ..., asynchronous
message passing, ...

[http://en.wikipedia.org/wiki/Communicating_sequential_proces...](http://en.wikipedia.org/wiki/Communicating_sequential_processes)

GHC's IO, Erlang, and Gevent are not implementations of CSP. Go is, though,
which makes me wonder if Go is not a good tool to implement distribution in if
they added inter-vm channels.

