3 ms·
Although this can be abused, the use case is not external dependencies IMO, but rather extending systems. Think of a web server etc. Each plugin is still a stat
by dvirsky 10y ago
Although this can be abused, the use case is not external dependencies IMO, but rather extending systems. Think of a web server etc. Each plugin is still a static binary that is self contained, but you can load capabilities into the server in runtime.
This is not like dynamic linking hell you can get yourself into when writing C.
- clappski 10y agoBut isn't that exactly how dynamic linking works? By loading a DLL at runtime? The only issues I've ever had with dynamic linking are at _runtime_, where XXX.dll can't be found.
- dvirsky 10y agoyes, my above comment wasn't phrased that well. but do distinguish between a plugin system where you load so's or DLLs to extend an app, and an application that has dynamic linking against them, where the linker handles this. So basically something like apache modules - either you can load the module or not - vs something like "cannot find symbol foo in foo.so.0.1."
- wtbob 10y ago> Each plugin is still a static binary that is self contained, but you can load capabilities into the server in runtime. In my Go code, I've just used subprocesses for that. Stdin & stdout, plus a simple serialisation format, and I'm done. Not suitable for high performance stuff, of course, but good enough for my needs.
- dvirsky 10y agoyeah, it could work for sure if latency is not an issue. It's also possible to do a go->C->go bridge to load Go plugins dynamically.
- pjmlp 10y ago> This is not like dynamic linking hell you can get yourself into when writing C. No, but they will eventually need to handle plugin versions.