You can statically link libc in Rust too; at least, if teh interwebz is correct (not a Rust expert); you just need some extra flags.
This is actually not that different from Go in practice; many Go binaries are linked to libc: it happens as soon as you or a dependency imports the very commonly used "net" package unless you specifically set CGO_ENABLED=0, -tags=netgo, or use -extldflags=-static.
Statically linking libC is problematic in various ways. I really appreciate that Zig has its own runtime that is designed specifically for this use case.
glibc, Linux's traditional libc, can dynamically load hostname resolution policies, but that only works if the executable has access to dynamic loading, i.e. if it's not a static executable.
Dynamically loading hostname resolution policies doesn't happen often, but when it does happen it's a right pain to diagnose why some tools see the right hostname and other tools don't.
You can, but usually, if you really want a binary with no runtime dependencies, most people will just compile their code against musl libc instead.
The only issue is that some lib sometime do not compile (or at least without some workaround) with musl. Although it often concern one specific platform (looking at you Mac OS).
This is obviously a trade off, it’s not a bug there’re certain things one must overcome “with time”, even if Go starts using libc am pretty sure the Go team will have their own libc which makes no difference unless it deals with the problem Cgo have
