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.
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
I agree with you that it wasn't that much of a hassle technically, just wish that the announcement was done with more transparency instead of "OTP Technical Board" met somewhere and this is what was decided http://erlang.org/pipermail/erlang-questions/2012-October/06...
Reminds me of Microsoft's .NET development process from 10 years ago, huge corporation drives development of a platform behind closed doors with very few people from the outside having any idea what is coming in the future.
Elixir needs a good IDE with code completion and jump to definition. There are awesome Erlang plugins for Eclipse and IntelliJ IDEA, but for Elixir I am still hacking in SublimeText and the lack of those two functionalities slows down the process considerably, from what it could be.
IMHO when Ericsson decided to remove "experimental pmods" support from Erlang in version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a liability. Ericsson's development team did release a workaround example, but the whole process how this went down left a sour taste in my mouth.
My wish is that Ericsson's Erlang development team became more transparent to the outside world, shared their bug tracker, code reviews (Go team does this wonderfully) and did all development in the open. Then we would not have these situations https://github.com/erlang/otp/pull/687 and it would save me ton of time couple years ago chasing after ssl bugs.