5 ms·

Didn't one of the main selling points of Go is one big static executable with no external dependencies? What's next? Generics?

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 ago
  But 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 ago
    yes, 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 ago
    yeah, 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.
StavrosK 10y ago
Are you saying that, in cases where that's not possible, you'd rather not have a program at all instead of a program with external dependencies? Because that doesn't sound very reasonable to me, even after ignoring that plugins aren't really dependencies anyway.
nine_k 10y ago
Generics would be great, but they are much trickier. It took Java many years to implement them, while having fewer runtime constraints.
stirner 10y ago
Standard library packages are not the same thing as the language and are not mentioned in the Go specification. The standard library is just a collection of packages that implement common functionalities that might otherwise lead to multiple competing implementations (like hyper, tiny_http, rotor-http, and solicit in Rust). Including a plugin mechanism is not an endorsement of that style of architecture, but simply an acknowledgement that there are programs that will need plugins.
stirner 10y ago
Standard library packages are not the same thing as the language and are not mentioned in the Go specification. The standard library is just a collection of packages that implement common functionalities that might otherwise lead to multiple competing implementations (like hyper, tiny_http, rotor-http, and solicit in Rust). Including a plugin mechanism is not an endorsement of that style of architecture, but simply an acknowledgement that there are programs that will need plugins.

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 ago
But 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 ago
  yes, 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 ago
  yeah, 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.

StavrosK 10y ago

Are you saying that, in cases where that's not possible, you'd rather not have a program at all instead of a program with external dependencies? Because that doesn't sound very reasonable to me, even after ignoring that plugins aren't really dependencies anyway.

nine_k 10y ago

Generics would be great, but they are much trickier. It took Java many years to implement them, while having fewer runtime constraints.

stirner 10y ago

Standard library packages are not the same thing as the language and are not mentioned in the Go specification. The standard library is just a collection of packages that implement common functionalities that might otherwise lead to multiple competing implementations (like hyper, tiny_http, rotor-http, and solicit in Rust). Including a plugin mechanism is not an endorsement of that style of architecture, but simply an acknowledgement that there are programs that will need plugins.

stirner 10y ago