[feelin_googley]

"... trivial deployment, etc.)..."

Does this refer to static binaries?

What amazes me most about Go is that they managed to successfully pitch a C-like systems language that does not promote use of shared libraries. About six years passed before they added an option to create them.

Were there many complaints about the absence of shared libraries originally?

Whenever I have mentioned the benefits of compiling C programs as static binaries and that in some cases with todays hardware one can have enough memory that shared libraries may not be necessary in order to conserve memory (one of the original goals of shared libraries), I have encountered substantial resistance to the idea. Perhaps some folks are interested in shared libraries for reasons other than memory conservation.

[hliyan]

The deployment time benefits of static binaries far outweigh the resource saving benefits of dynamic linking. I'm speaking from experience with C++. There is also a latency boost for high CPU intensive processes.

[closeparen]

The Go community mostly deploys network server daemons to its own datacenter infrastructure. C and systems programming in general also target end-user devices, where it isn't the programmer's memory to spend.

The open-source community already has a mature ecosystem for dealing with shared libraries via package managers and distro maintainers. In a company's proprietary backend it's almost certainly cheaper to throw memory at the problem than to spend engineer time crafting and maintaining a coherent/compatible set of packages for its various backend services.

[ptr]

In my experience, shared libraries can simplify deployment as well; say you’ve got a 100 programs using the same library, and you need to change the implementation. With a shared library you only need to build and deploy one artifact, you don’t need to relink and redeploy 100 programs.

[Santosh83]

Security: they need to be updated in one place instead a hundred different places.