Actually, the libc is dynamically linked here, as shown in the /proc/maps section of the article.

So, to answer the GP: yes, resident memory from the libc ends up being amortized between all the processes that use it. But it doesn't even matter much as there's a mere 5 MiB of resident memory involved here. The “hundreds of MiB” are only of virtual memory, and that shouldn't be of any concern (see my other comment in this thread).

> Go programs are statically linked

Not necessarily true, unless you use strategies like the one suggested in the top level post above this. https://www.osso.nl/blog/golang-statically-linked/

In practice, those dependencies are ubiquitous enough that the "DLL hell" half of the dynamic-linking problem is avoided. The other issues (system-dependent behavior quirks, estimation from static libraries, linker caching, etc. etc.) remain in many cases.

Go doesn’t statically link against libc; maybe it’s possible with the likes of musl, but in general, libc is dynamically linked.