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'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.
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.
The Ericsson team does plan to open up things like that.
But pmods shouldn't be used like an example of them going against the community in driving the language forward. Very very few people in the community objected to their removal. Many of us were happy and thought it should have happened much earlier.
> 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.
It caused a bit of hassle, but not much, really. It was a feature that many Erlang people did not like much in the first place, so heavy use of it put them off to begin with.
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.
