Pingo: Plugins for Go | Hacker News Reader

Pingo: Plugins for Go

github.com

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.

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

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

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.

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.

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.

It's implemented as RPC over localhost. Doesn't replace dynamic linking, but can be very handy nonetheless ;)

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

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.

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

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.

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

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

You'll see the extreme similarities to writing a microservice here https://github.com/asim/go-micro

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

What does it use for marshalling? JSON?

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/

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

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

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

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

http://en.wikipedia.org/wiki/Pingu

Also the name of an actual company that provides phone cards/numbers for international calling: http://www.pingo.com/

And a slang for penis in many dialects of Spanish

Reply on news.ycombinator.com