

Pingo: Plugins for Go - paskaahuomenta
https://github.com/dullgiulio/pingo

======
falcolas
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.

------
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](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...](https://github.com/dullgiulio/pingo/blob/master/plugin.go#L59)
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](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.

------
chuhnk
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.

------
frik
Great idea, as Go 1.4 currently only supports static linking this is _huge_ \-
emulates dynamic linking a bit like Chrome/Firefox addons "sandbox" style.

~~~
vezzy-fnord
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.

Another method is using code generation: [https://github.com/progrium/go-
extpoints](https://github.com/progrium/go-extpoints)

~~~
eternalban
Agreed, not huge, and well known.

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.

~~~
skybrian
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.

[1] [https://blog.golang.org/generate](https://blog.golang.org/generate)

~~~
eternalban
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.

------
aylons
The same name as a Python Library for single-board computers (though in
Python, not Go):
[https://github.com/garoa/pingo](https://github.com/garoa/pingo)

------
divan
I see this project as a helper for transition from "dynamic loading plugins"
to "microservices" mindset :)

~~~
chuhnk
You'll see the extreme similarities to writing a microservice here
[https://github.com/asim/go-micro](https://github.com/asim/go-micro)

------
Animats
This is very similar to Python's "multiprocessing" module.

What does it use for marshalling? JSON?

~~~
wtf_is_up
It's using Go's net/rpc package [1] from stdlib, so it would have to be
encoding/gob [2], also from stdlib.

[1] [https://golang.org/pkg/net/rpc/](https://golang.org/pkg/net/rpc/)

[2]
[https://golang.org/pkg/encoding/gob/](https://golang.org/pkg/encoding/gob/)

------
jzelinskie
How is this different from the pattern established in database/sql?

------
fideloper
I'm curious about how this concept is accomplished with other compiled
applications such as Apache and it's modules?

------
aninteger
The name choice is so close to a children's television show:

[http://en.wikipedia.org/wiki/Pingu](http://en.wikipedia.org/wiki/Pingu)

~~~
Daishiman
And a slang for penis in many dialects of Spanish

