Re: [go-nuts] Re: Any option to substitute plug-in package ?

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

Re: [go-nuts] Re: Any option to substitute plug-in package ?

For highly-specific filtering, you might also find https://github.com/google/cel-go interesting. CEL is statically typed and declarative. On Sat, Oct 28, 2023 at 11:48 PM Mike Schinkel wrote: > > I recently started using github.com/yuin/gopher-lua for a project to allow > users to add filtering

[go-nuts] Re: Any option to substitute plug-in package ?

Oops! Meant to say *“Using Lua to develop plugins in Go would NOT be ideal IMO.”* On Saturday, October 28, 2023 at 10:47:56 PM UTC-4 Mike Schinkel wrote: > I recently started using github.com/yuin/gopher-lua for a project to > allow users to add filtering criteria that would be

[go-nuts] Re: Any option to substitute plug-in package ?

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

[go-nuts] Re: Any option to substitute plug-in package ?

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,

[go-nuts] Re: Any option to substitute plug-in package ?

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: > WebAssembly

[go-nuts] Re: Any option to substitute plug-in package ?

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:

[go-nuts] Re: Any option to substitute plug-in package ?

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

[go-nuts] Re: Any option to substitute plug-in package ?

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: > It really depends

[go-nuts] Re: Any option to substitute plug-in package ?

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.

[go-nuts] Re: Any option to substitute plug-in package ?

The plugin package is very limiting even under Linux: see this reddit post . I suggest you look at hashicorp's go-plugin .