3 ms·
Yeah, should have been more precise. Code that can be loaded at runtime, does not need to be compiled together with the host application, can be loaded by just
by Fire-Dragon-DoL 3y ago
Yeah, should have been more precise.
Code that can be loaded at runtime, does not need to be compiled together with the host application, can be loaded by just providing a path to a file/directory and can be executed in the host, ideally securely (not a strict requirement for my usage).
The plugin ideally runs with performance very close to host performance
go plugin package gets close, but the compile part is completely broken, where in reality the plugin has dependencies that can collide with the host. It would be fine if it was just the go runtime requirement that must match, but in reality it forces usage of cgo and a set of problems that make it really hard to use.
- candiddevmike 3y agoHave you looked at https://github.com/hashicorp/go-plugin https://github.com/hashicorp/go-plugin?
- Fire-Dragon-DoL 3y agoI looked at every option out there and none of them satisfy all the requirements at the same time, sadly
- nighmi 3y agoWhat use cases do you actually have for plugins? I mean, why do you need that hotloading factor?
- Fire-Dragon-DoL 3y agoA simple example: wordpress-like system. Plugins in wordpress are installed from the web UI and that's all, these just work with the same performance as the whole application (terrible native performance, but that's a PHP problem). In go to achieve that I would need to compile the plugins on the fly, as well as recompile the whole application, instead of delivering an executable file and a bunch of dynamic libraries. In .NET this was further used in large applications to reduce boot time, by loading code when it was first needed (DLLs)