[sagichmal]

> Rather than being pre-compiled and linked, however, plugins are executed on the fly by Yaegi, an embedded Go interpreter.

Woof, no thank you.

Go is basically incompatible with any kind of plugin-like dynamic linking. There are basically two reasonable models for doing something like plugins: the HashiCorp model, where plugins are actually separate processes that do some kind of intra-process communication with the host; or the Caddy model, where you select which plugins you want when downloading the binary, and they're built-in at compile time.

[hinkley]

Correct me if I'm wrong, but the Caddy model requires curation, doesn't it?

Plugins and scripting languages flourish when they democratize the process of adding features to a piece of code. To have prebuilt binaries you need a build matrix, and the complexity of the build matrix is somewhere between exponential and factorial.

This is a perverse incentive for the curators. The cost has to be justified, and as the friction grows you can only justify the things that you have a strong affinity for. Anything you don't understand or don't like gets voted off the island.

In the best addon ecosystems, the core maintainers put some safety rails on the system so the addons can't do anything too crazy. Then they watch the cream of the crop and start trying to include them in the base functionality (limiting the number of optional features the majority of their users have to manually pick). The hard part here is how to reward the people whose ideas you just co-opted, and I don't have a great answer for that (although money and/or a free license for life is a good start)

[sagichmal]

> Plugins and scripting languages flourish when they democratize the process of adding features to a piece of code . . . In the best addon ecosystems, the core maintainers put some safety rails on the system so the addons can't do anything too crazy. Then they watch the cream of the crop and start trying to include them in the base functionality (limiting the number of optional features the majority of their users have to manually pick).

Well, it's a cost/benefit judgment call, not a single valuation. And I think for situations like this, if you have to pick a side, it's generally better to pick the exclusionary walled garden over the bazaar -- I think the value of democratization is usually overstated, and the drawbacks underemphasized.

[alufers]

There is the "plugin" package which seems really cool and fits the simplistic style of Go (tbh I haven't tried this module myself, only glanced at the documentation), but it does not work on Windows, which I think is the reason it is not used. The ticket about adding Windows support to the plugin package is one of the highest rated ones on Go's GitHub, yet it is still open.

[slx26]

See jdoliner's comment and replies on this thread for more context and information.

[sagichmal]

The plugin package was an experiment and is basically now abandoned, it's not meant for real use.

[saurik]

How can they possibly be calling this "native"? :/

[imtringued]

Any significant downside to the process based model? I haven't benchmarked the memory consumption of minimal a Go process but it should be well below what e.g. a minimal JVM application uses. With the right serialization format IPC can be reasonably efficient.

[unixhero]

I'm sure you're onto something. But I can't really decipher whats bad here and which of the two scenarios you mention apply to go interpreted plugins.