I wouldn't call it "huge". Using net/rpc to emulate shared library plugins has been the primary recommended technique to anyone raising the question for a while now. This simply makes it into a library.
Code gen is probably the most sensible way to approach the static nature of Go (and also generics, when all is said and done ;). While it is true that the pluggable platform x on Go should allow for any compliant plugin, at deployment time, the plugin set is known and effectively static.
Irony here is that given that the chaining of tools is emerging as the most natural way to build up the feature sets, the fast compile time may not be so fast anymore.
If you use go generate [1], you check in the generated code, and only the author of a library pays the cost of code generation, not all the downstream dependencies.
You pay a price for not recompiling from the real source; in particular, after a security bug is fixed in a code generator, the downstream libraries won't automatically regenerate their code.
On the other hand, it's no worse than ecosystems such as Maven or Linux distros where people commonly download binary libraries rather than compiling from source.
There are other options. This thread interested me enough to start sketching out a different approach. I don't see the point of the maintainers of the exoskeleton generating an unbounded set of permutations.
Hmm. So not to be critical but isn't this just rpc? It feels very much just like rpc development. If you look at the net/rpc package you basically do the identical thing.
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.
Might I suggest a third communication method: stdin/stdout? It should be very easy to implement, would work better with really small process and would be much more cross-platform compatible without having to invoke the TCP stack.
21 comments
[ 3.7 ms ] story [ 54.1 ms ] threadhttp://en.wikipedia.org/wiki/Pingu
Another method is using code generation: https://github.com/progrium/go-extpoints
Code gen is probably the most sensible way to approach the static nature of Go (and also generics, when all is said and done ;). While it is true that the pluggable platform x on Go should allow for any compliant plugin, at deployment time, the plugin set is known and effectively static.
Irony here is that given that the chaining of tools is emerging as the most natural way to build up the feature sets, the fast compile time may not be so fast anymore.
You pay a price for not recompiling from the real source; in particular, after a security bug is fixed in a code generator, the downstream libraries won't automatically regenerate their code.
On the other hand, it's no worse than ecosystems such as Maven or Linux distros where people commonly download binary libraries rather than compiling from source.
[1] https://blog.golang.org/generate
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
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.
What does it use for marshalling? JSON?
[1] https://golang.org/pkg/net/rpc/
[2] https://golang.org/pkg/encoding/gob/