Rewriting the GNU Coreutils in Rust

Rewriting the GNU Coreutils in Rust

If you don't have stable ABIs then savings from COW rarely materialize. Simply because different programs end up with different DSOs anyway.

Sure, if may still get that benefit for OS-supplied programs, but in todays' world where even low-end system gave gigabytes of RAM it's not very important.

And where it is important (embedded, e.g.) you would get bigger savings if you would just combine multiple binaries into one. Bosubox was written in C yet it's usually compiled as one binary anyway.

Thus solving dynamic linking problem without solving ABI stability problem incurs high costs yet doesn't buy you much.

And the fact that you can't solve stability ABI without developer's buy-in makes the issues easier to handle different issues, too.

Think Windows, platform with most third-party plugins implemented as dynamic libraries (Android and iOS have more apps today, but very-very few of them use or support third-party plugins): global variables can not be shared, there are no common libc (thus you need to keep track of different versions of malloc/free) and so on.

Similarly in Rust: if we don't plan to make the ability to build any module as share library the goal then we can significantly simplify that task and from practical POV there would be little difference.