[raggi]

This is definitely an area it would be great to see more work in. On Fuchsia we started linking the rust stdlib dynamically, but there are some significant ABI constraints to doing this in a traditional Unix shared library ecosystem that we're able to avoid due to the isolated and storage-deduplicated nature of the package system.

If you do link rusts stdlib dynamically, then you end up with binaries that are equivalent to C++ binary sizes with an external libc++, where rusts stdlib is approximately the same size as libc++, and the release mode stripped binaries are also comparable (within ~1kb of each other, and in the range of 10kb for a standard unix pipeline style application which does some basic stream processing of IO).

[brundolf]

Is dynamically linking Rust's standard library officially-supported or did you have to hack around that? I know static-linking is the default but I've never looked into doing otherwise

[steveklabnik]

The flag to dynamically link dependencies exists, and is part of the compiler's stable flags, but I'm not sure how much it's actually used, or how well it actually works.

[pabs3]

Hmm, an LWN comment posted on the Debian wiki claims there are ABI stability issues, but they are being worked on:

https://lwn.net/Articles/797616/ https://wiki.debian.org/StaticLinking#Rust

[steveklabnik]

Correct, the ABI is not stable. Given that they build a base system with a single rustc, that's not an immediate concern, though of course, a more stable ABI helps dynamic linking be more relevant.

[raggi]

The problem they'll have is that they don't update the whole system atomically, so the generations of different packages may be different.

A distribution like Clear or Nix could probably wrangle things appropriately.

[zozbot234]

Rust's stable ABI is the C ABI. I don't really see this changing in the foreseeable future.

[raggi]

It works well in terms of programs working. It has similar challenges to C++ that various commonly used abstractions end up producing a lot of code on the program side regardless. It's nonetheless worthwhile, if you have enough programs and resource constraints.

[pdimitar]

I am definitely not as well-versed as you -- but for now I'd stick with Rust's statically linking nature. What I am more looking for is to have some very aggressive tree-shaking at the final phases of Rust compilation/linking where the tooling can prove that in your program, say, 73% of the stdlib isn't used at all so it can just remove it from the final binary.

It's my view that as deployment moves more and more to containers and even to the "microkernel + your app only" model then being able to fit binaries in CPU caches will become crucial for the viability of such cloud hosting. (Although to be fair, when we're talking about Rust + the Linux kernel, running something in 25ms vs 5ms can't be a huge deal for 98% of all apps, right?)

[vvanders]

Pretty sure LTO already provides that functionality(I wish Rust had LTO on by default but it's fairly straightforward to flip on).

[pdimitar]

You can set LTO units to 1 which is what I do because it leads to some final binary size reduction -- but it isn't much. :(

I am aware that we have to start being more mindful of our dependencies but in commercial this is a luxury that you often don't have.