Rewriting the GNU Coreutils in Rust

There's some talk, but no efforts that I know of - see this blog entry on how Swift achieves dynamic linking when Rust doesn't that explains one route that could be taken to dynamic linking in Rust without losing too much of the Rust benefits.

Ultimately, though, we're at the "needs an innovation" stage - dynamic linking is built around the idea that compilation takes a single independent unit of source and turns it into complete object code with unresolved symbols. Linking then resolves all the symbols to get an executable binary. In that model, dynamic linking is a big win; there's a clear divide between the single units of source and the symbol resolution.

Modern languages (C++, Rust, Swift, Go and others) are not as amenable to this model; units of source code are not independent any more, because the use of generics and vtables both mean that inlining and specialisation of the inlined code is a huge win and thus we want to either have huge units of source (entire programs, say), or we want the link phase to do significant compilation effort, possibly changing the units that it has on disk.

Note that Rust is, in a very technical and useless sense, dynamically linked on Linux; while all the Rust code forms a single object, that object is dynamically linked with the C code it depends on at runtime, including the VDSO and libc. It's just that what we want is to somehow get the shared code between two Rust objects into a Rust shared object that's reused at runtime, and this is a deeply challenging problem to get right, especially in a language that aims to have cheap abstractions like Vec<_> working well.