[pizlonator]

This might end up being the forcing function (quoting myself from another reply in this discussion):

> It can't be that replacing 20 C/C++ shared objects with 20 Rust shared objects results in 20 copies of the Rust standard library and other dependencies that those Rust libraries pull in. But, today, that is what happens. For some situations, this is too much of a memory usage regression to be tolerable.

If memory was cheap, then maybe you could say, "who cares".

Unfortunately memory isn't cheap these days

[miki123211]

Can you even make the standard library dynamically linked in the C way??

In C, a function definition usually corresponds 1-to-1 to a function in object code. In Rust, plenty of things in the stdlib are generic functions that effectively get a separate implementation for each type you use them with.

If there's a library that defines Foo but doesn't use VecFoo>, and there are 3 other libraries in your program that do use that type, where should the Vec functions specialized for Foo reside? How do languages like Swift (which is notoriously dynamically-linked) solve this?

[zozbot234]

You can have an intermediate dynamic object that just exports Vec<Foo> specialized functions, and the three consumers that need it just link to that object. If the common need for Vec<Foo> is foreseeable by the dynamic object that provides Foo, it can export the Vec<Foo> functions itself.

[staticassertion]

How much overhead is that? Also, why would that have much overhead? Things deduplicate in memory.

[pizlonator]

They dedup at the page level.

This isn’t that kind of duplication.

[rlpb]

Your apt update would still be huge though. When the dependency changes (eg. a security update) you’d be downloading rebuilds of 20 apps. For the update of a key library, you’d be downloading your entire distribution again. Every time.