* Vincent Bernat: > ❦ 24 mars 2020 16:30 -07, Russ Allbery: > >> On the other hand (and I don't follow this community closely, so apologies >> if I have the details wrong here), my impression is that the Go community >> is not planning to support shared libraries, loves its staticly-linked >> binaries, and makes extensive use of the fact that different packages can >> pin to different versions and this doesn't matter for their intended >> output format (a static binary). > > Go supports shared libraries since quite some time but I don't think > it's widely used. Notably, the tooling around it is quite primitive. > Even the plugin system (which is mostly like dlopen() and could be > useful in many cases) is seldomly used.
That's true, but also somewhat besides the point because in order to use dynamic shared objects to avoid recompilation of applications, you also need practical ABI stability, both between compiler versions and versions of the library. Go does not have a low-level ABI that remains unchanged across compiler versions, and (like C and C++) it encodes struct offsets and sizes directly in the machine code, sometimes in unexpected places due to inlining. So even if the Go standard library was linked as a shared object, you would still have to rebuild all applications using it. I believe GHC is similar in this regard. Using shared objects under such circumstances only makes updates harder for end users because live systems end up in inconsistent states (ideally only for a brief time). De-vendoring sources might still be an advantage because applications can be fixed with a bin-NMU, but it's a lot of work. The resulting divergence from upstream can result in additional bugs. On the other hand, there are projects which bundle sources only for developer convenience, but expect production binaries to use different library sources for the dependencies. I don't know if Kubernetes is one of those projects.
