> I think Go tried to go fully static but ran into problems [...] So you can probably go fully static if you are only targeting Linux. There's yet another pro

> I think Go tried to go fully static but ran into problems [...] So you can probably go fully static if you are only targeting Linux. There's yet another problem Go ran into on Linux: resolving hostnames. The official way to resolve hostnames in a glibc-based system is to read /etc/nsswitch.conf, dynamically load the libraries referenced there, and call each of them in the correct order. Go tried to emulate that mechanism, going through glibc only when it saw a NSS module it didn't know, but that caused issues on musl-based systems which used a different mechanism (https://github.com/golang/go/issues/35305 https://github.com/golang/go/issues/35305). And it cannot ever be fully static on glibc-based systems, since there's always the chance of someone adding a new module to /etc/nsswitch.conf (for instance, some Linux distributions have now added the newer "resolve" module to that line, so Go would have to implement yet another one to keep being fully static). The Rust approach of dynamically linking to the shared C libraries (statically linking only the Rust libraries) avoided all these issues.