
Suture – Supervisor Trees for Go - leef
http://www.jerf.org/iri/post/2930
======
tel
It would be interesting to see what it takes to get this functionality (at
least locally) into Haskell given that there _are_ asynchronous exceptions...
even ones with arguably greater safety than their Erlang compatriots.

A similar effort is happening with the Cloud Haskell program, but my
understanding is that they're pouring a lot of effort into transmitting
arbitrary Haskell functions over the wire between computers. This is pretty
unnecessary for supervision and "Let it Crash"-style error handling alone.

~~~
jeremyjh
That is a core primitive in Cloud Haskell but not the only one - you also send
and receive data as in Erlang. distributed-process-platform provides Erlang
style supervisors, gen_server, etc. It's all there and very much captures the
features and spirit of OTP in a powerful static type system.

~~~
tel
I'll definitely give it another look. I may have just misunderstood where the
effort was being spent.

~~~
coolsunglasses
You may be thinking of the statics stuff being done with GHC 7.10.

~~~
tel
I think I just missoveremphasized the importance of a particular paper on it
that I read.

------
wyc
Great article. I especially enjoyed the clear descriptive problem framing and
discussion about Erlang processes versus goroutines.

~~~
ckluis
Agreed - I think this was one of the best written descriptions of a problem
and then a solution set. Enough so that even someone only quasi-technical
could make sense of a good portion of it.

------
mratzloff
This was interesting simply for the explanation of Erlang systems, but as for
the project itself I currently use Supervisor
([http://supervisord.org](http://supervisord.org)) for this purpose, and I've
been pretty happy with it.

Any reasons to make the switch?

~~~
leef
For when you want to supervise goroutines instead of processes (Presumably
because processes are consuming too many resources).

~~~
lucaspiller
Exactly. One of the big ideas of Erlang is to have many lightweight processes
(processes in the VM, not OS).

As an example say you have a chat system, you will have a process for each
user [0]. If you have a million users, you will end up with a million
processes. The supervisor tree watches these processes, so if one crashes a
single user may get logged out but everybody else will be unaffected.

[0] In reality you'll probably have it even more fine grained than that, so
users will end up with multiple processes.

------
wcummings
Why not just use Erlang?

~~~
jerf
I'm comfortable with it, but none of my team wants to use it.

Even after 7 years of experience, it is very klunky to program in, and in
reimplementing the Erlang program I had in hand, I immediately added some
features that were very hard to implement in Erlang. And note the
_architecture_ of the code didn't actually change, this isn't one of those
cases where the second version was also radically different than the first so
no comparison is possible, it was actually hard to implement in Erlang. Erlang
is a very klunky language to work in. Raw Java might be klunkier, but it's
easily the klunkiest of the languages I use.

Erlang's clustering, which my code heavily depends on, just sort of breaks
sometimes, on machines that are on the same switch, with every bit of hardware
switched out over time. It is very opaque to figure out why it isn't working,
or how to make it work again. Mnesia breaks even more often on loads that
shouldn't be a problem. After 7 years of working with it, at this point _even
if_ the solution was just to turn on this one flag somewhere and all my
problems would go away, I still would not consider that a positive.

I don't "hate" it, but I've been waiting for years for a more conventional
language that had pervasive microthreading in it that I could use for work. Go
is not _quite_ it... I'd still like the goroutines to be completely isolated,
and I've got a handful of other quibbles... but it's close enough that I might
be able to get out of the hell of trying to multiprocess in most other
languages, while being something I might actually be able to get adopted. In
general, the company I work for has not been overwhelmed by the effectiveness
of Erlang.

In practice, the biggest loss of fundamental capability is loss of true
asynchronous exceptions, and, well... in practice that's only an annoyance,
not an OH MY GOSH I WILL NEVER USE A LANGUAGE WITHOUT ASYNCHRONOUS EXCEPTIONS
sort of thing. In most cases if you're throwing an async exception you've
really already lost and now we're just discussing exactly how you're losing.

Every language student should study Erlang, and learn from it, and possibly
use it. It's a solid language. And there's nothing wrong with trying to port
some of that solidity elsewhere. (I'd pick a real DB over Mnesia, though.)

~~~
tormeh
Have you taken a look at Akka (with Scala)? You sacrifice code hot-swapping
and I think little else, but you get JVM performance and one of the most
extensible non-Lisp and safe non-Haskell languages in existence.

~~~
wcummings
Or Akka with Java

~~~
tormeh
Yeah, but the reasons for choosing Java over Scala are mostly organizational.
If your organization can tolerate Erlang it can tolerate Scala.

~~~
wcummings
But his can't tolerate Erlang, that's why he used Go.

~~~
tormeh
Sorry, kinda missed that.

------
spenrose
I did something similar in Python, using Redis for the "operating system" and
Linux processes. The system managed wide sets of parallel I/O operations with
second-level latency. Worked great, albeit orders of magnitude slower than
something like this. If you keep the supervisor on the same machine, you can
do async exceptions via kill.

------
dman
Any pointers on what blogging setup is being used at jerf.org for writing this
post? I found the page pretty tasteful.

~~~
buro9
It has all the signatures of a static site generator.

