> All this while Rust, go, and all the new kids on the block use only static linking.

This is trivially disproven:

  $ ldd /usr/bin/rustc
   linux-vdso.so.1 (0x00007ffd3de9b000)
   librustc_driver-e4385bf403336f76.so => /lib64/librustc_driver-e4385bf403336f76.so (0x00007ff832a00000)
   libstd-d371b708c754b3bb.so => /lib64/libstd-d371b708c754b3bb.so (0x00007ff832886000)
   libc.so.6 => /lib64/libc.so.6 (0x00007ff832600000)
   libLLVM-14.so => /lib64/libLLVM-14.so (0x00007ff82be00000)
  [...]

Not only does rustc dynamically link against rust's "std" library, but also parts of rustc are implemented in a dynamic library ("librustc_driver").

The only reason projects written in Rust (other than rustc itself) don't use dynamic linking to other Rust code yet, is that there still isn't a stable ABI for Rust code (for good reason: that allowed them to introduce not only reordering of struct fields and niche optimizations, but also passing and returning slices as a pair of registers instead of a pointer to a two-word structure in the stack). I fully expect that, as the language matures, a stable (possibly opt-in) ABI will be introduced, together with freezing some of its standard library (for instance, the contents of the Vec structure, and how its inline functions work), allowing for dynamic linking against Rust's "std" (and as a consequence, passing Rust types between separate dynamically linked modules compiled with different releases of Rust).

(As an aside: back when C was the "new kid on the block", it also used only static linking, dynamic linking of C code came later.)