Any option to substitute plug-in package ?

[alex-coder]

Hi All !

Plug-in package is very interesting, but in case the development under windows it does not work,
So, any hint to use some option instead will be highly appreciated.

Thank you.

[Brian Candler]

The plugin package is very limiting even under Linux: see this reddit post.

I suggest you look at hashicorp's go-plugin.  This takes a different approach: it spawns a separate process for each plugin, and talks to it over RPC.  It's very robust: it's the plugin library used by their other products such as Vault.

[TheDiveO]

It really depends on what you want to achieve...

1. dynamically discovering out-of-process RPC plugins ... Hashicorp's might be the most famous one.
2. dynamically discovering and loading shared lib plugins ... this needs some plumbing above the pure stdlib plugin functionality. Personally, I find the shared libs to be finicky and haven't yet done a real project that needed this variant (but I wrote a go-plugger module as an example).
3. statically binary-builtin plugins: this actually is what I tend to use in several of my own projects, where there is no need for dynamically extending but instead to easily maintain and use a fixed set of "plugins" and that set of plugins tends to slowly grow. The plugin mechanism might help organizing, such as my own go-plugger supporting type-safe plugin APIs and ordering and iterating plugins at runtime. For instance, I use this mechanism to simplify adding new types to factories, or to "decorate" containers with additional labels, such as in Docker compose contexts, or k8s contexts, or ...
   

[alex-coder]

Hi All,

so, binary code plugin as a RPC - frankly, never thought about :-)

What is written in go spec is a 

>> dynamically discovering and loading shared lib

as I see it but community developed much further

Thank you.

среда, 2 августа 2023 г. в 15:03:38 UTC+3, TheDiveO:

[Brian Candler]

I believe Hashicorp's go-plugin was developed long before Go's stdlib plugin functionality was made available.

But they still use it. It's well established and tested, the architecture has security benefits, and it works cross-platform. It also makes it easier for plugins to be distributed by third parties: they don't have to be compiled with the exact same toolchain. In fact, they don't even have to be written in Go.

Of course, shared libraries will be much faster - so it depends on your use case, whether you need large volumes of low-latency calls.

If your production environment is Linux, and the only issue is around *development* under Windows, then you can look into WSL or virtual machines.

[Christoph Berger]

WebAssembly comes to mind - see, for example, https://wazero.io/

A plugin would then be a .wasm binary that can be compiled in any language that supports WebAssembly as target.

Disclaimer: I have not yet tried this approach.

On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:

[alex-coder]

Hi All,

Currently I walk through the next book about native go development and find out that it is possible to use the plugin, 

but with limitations, so it became interesting what alternatives there are.

Thank you.

четверг, 3 августа 2023 г. в 12:09:21 UTC+3, Christoph Berger:

[alex-coder]

Hi all.

Of course, in case if anyone is in interest to write  plugins for Go.
I found another option for writing plugins by use Lua.
I haven't touched the example yet, but I'm giving out the link.
https://github.com/yuin/gopher-lua/

Thank you.

четверг, 3 августа 2023 г. в 15:47:26 UTC+3, alex-coder:

[Mike Schinkel]

I recently started using github.com/yuin/gopher-lua for a project to allow users to add filtering criteria that would be highly-specific to a user, but I would never consider using it for implementing a general-purpose plugin. 

Using Lua to develop plugins in Go would be ideal IMO. It is not performant like Go, not type-safe like Go, debugging embedded Lua code is difficult compared to working with Delve and Go, and you will have to ship plugin source code, or embed and write to a possibly hidden directory.

For real-world plugins I'd say stick with Hashicorp's go-plugin or similar as others have recommended, and then only fall back to Lua when you want to allow end-users who are not Go developers to extend your app in small ways.  #jmtcw #fwiw

-Mike
P.S. You could also use JavaScript instead of Lua, and most people are likely more familiar with that. I chose not to use a JavaScript package as I wanted something significantly lighter weight than JS.  OTOH, I am seriously considering switching out Lua and moving to github.com/antonmedv/expr for my use-case as it is even lighter weight still.

[Mike Schinkel]

Oops! 

Meant to say “Using Lua to develop plugins in Go would NOT be ideal IMO.”

[Nagaev Boris]

For highly-specific filtering, you might also find
https://github.com/google/cel-go interesting. CEL is statically typed
and declarative.

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/71ab878f-2ce6-4c73-9e85-e9d29e61d718n%40googlegroups.com.



--
Best regards,
Boris Nagaev

[Jason E. Aten]

The RPC and webserver/webclient approaches are well and good. Very standard, if high latency.

Other approaches I have used to extend Go dynamically:

a) embed a scripting language:

https://github.com/glycerine/zygomys (my lisp)

https://github.com/google/starlark-go (a python with assign once semantics)

https://awesome-go.com/embeddable-scripting-languages/ # a big long list of them

https://github.com/glycerine/rmq # call from/embed R/talk to it over http

b) embed a JIT/dynamic compiler

https://github.com/gijit/gi  # my partial implementation of Go on top of LuaJIT to get a REPL. Unfinished/has not been updated in many years.

https://github.com/go-interpreter/chezgo