Don't Rust and Go build to mostly-statically-compiled binaries? (With the exception of a link to libc.) (This isn't a rhetorical question, this is something I don't know a lot about
I'd imagine the biggest cultural reason is that many Rust developers were C developers who had a reason to find something better, but still scoff at garbage collection, large runtimes, etc. They probably have a lot more Rust expertise in their circle.
Another technical reason is that they were trying to replace their C code with Rust in bits and pieces before they went with a full rewrite. I don't know about Go, but this is something ergonomically doable in Rust.
I like loose type systems for some quick scripting, but I started to adopt Rust for many of my personal projects because I find it's so much easier to get back into a project after a year when there are good type system guard rails.
Rust can create statically-compiled binaries on Linux by using musl instead of glibc, but it’s not the default like it is in Go and is as a result not quite as effortless. There are a lot of crates with native dependencies that require slight environment tweaks to work on a musl build. Go on the other hand goes to great lengths to not need to link to any C code at all, to the point of shipping its own default TLS library and cryptographic primitives.
I thought the default for both Rust and Go were to statically compile everything except the dynamic link to libc? And that you could optionally statically include musl with a bit of extra work.
I've never had to do anything unusual with building, but I thought the "almost-ststically-compiled" thing was somewhere Go and Rust were almost identical.
Golang doesn't dynamically link to libc by default on Linux either - it calls the Linux kernel ABI directly (since that ABI is stable). The main upshot of this is that you don't have to worry about the classic glibc version bingo by default, while with Rust you have to go through some extra steps to avoid that.
You and your parent are talking about slightly different things. You are both correct in different ways.
Your parent is saying that, while what you say is true for Rust and Go code themselves, in practice, it is less true for Rust, because Rust code tends to call into C code more than Go code does, and Rust doesn't always statically link to that C code by default.
I'd imagine the biggest cultural reason is that many Rust developers were C developers who had a reason to find something better, but still scoff at garbage collection, large runtimes, etc. They probably have a lot more Rust expertise in their circle.
Another technical reason is that they were trying to replace their C code with Rust in bits and pieces before they went with a full rewrite. I don't know about Go, but this is something ergonomically doable in Rust.