[rambocoder]

Very cool.

I can see using this to construct an application made out of plugins, where their isolation provides fault tolerance, I can kill and restart a plugin as needed.

Now if it had heartbeat between the main process and plugins, so that unresponsive plugins would be killed and restarted automatically. Plus a restart strategy as a config parameter for the plugin so if the plugin dies, it can be restarted automatically. Basically a one_for_one restart strategy as in http://www.erlang.org/doc/design_principles/sup_princ.html

Does it make sense to panic in the constrctor https://github.com/dullgiulio/pingo/blob/master/plugin.go#L5... instead of returning nil, error

[vezzy-fnord]

Have you looked into Suture, which is just that - supervision trees for Go? (https://github.com/thejerf/suture)

[rambocoder]

I've looked at Suture before and now pairing it up with pingo might be a good idea because Suture can add supervision capability to this library.

As a standalone library, Suture gets close to what I want, except that the way Go's runtime works, if there is a panic in a goroutine, another goroutine cannot recover(), so if I create a service that suture supervises, and that service starts a goroutine that panics, suture will not handle it, the whole process will crash. Pingo get's rid of Go's shared heap memory, so if pingo's plugin panics, Suture could restart it, this maybe a good combination.