rustup in official apt repositories: starting from Debian 13 and Ubuntu 24.04

> Python did so

Nah, python is one of the few languages with an ecosystem that can still be properly packaged, even after pep517. All libraries are scripts that are installed (and bytecode-compiled) globally.

Node is a pain in the ass due to the granularity of libraries, how frequently they update and how developers expect a specific pinned version (and vendors are flaky about backwards-compat), but nothing stopping it from having the same treatment as python.

Dynamic linking isn't really an end-user feature, but rather a system integrator's. It makes it easier to make sure everything behaves the same, and can share the same resources, which is why Apple particularly wanted an ABI for Swift[1]

[1]: https://faultlore.com/blah/swift-abi/ - How Swift Achieved Dynamic Linking Where Rust Couldn't

A couple of weeks ago I was curious how many binaries on my system did not link glibc. On my pretty standard Unbuntu it were exactly ten and they were 100% Go binaries.

This, pretty much. You can code a shared object/dynamically linked library in Rust, and it will work as a drop-in replacement for one that's coded in C. Rust also has extensive support for interfacing with C shared objects.

> I don't think rust is 'fanatic' about it, there's no cultural or organisational push of 'thou shalt static link'.

Rust users have a "fanatic" ideology about static linking is a stretch. But rust is indeed now firmly wedded to recompiling everything. This is true despite the fact that ever growing compile times are a major complaint about the language.

What Rust users are fanatic about is monomorphisation. That boils down to the compiler implementing generic types using C++ style templates instead of C++ style vtables. Monomorphisation means the compiler produces a custom version of most libraries for your application or more precisely, the types your application uses. It probably contributes it's speed. But since they are customised to your application there is no point sharing them, so shared libraries are kinda pointless.

Like C++ Rust supports both the vtable a template style, but assumption the compiler knows the Size of every object is baked in pretty deep. Parameters have the Sized constraint by default for example, and a standard trick to get around the borrow checker is to copy everything, which you can only do if you know its size. I don't see it changing now - the language will life or die by the choice.

You are making an assumption that shared libraries have to somehow be compatible with the C ones and use the C dynamic linker: you can 100% have your own dynamic linker and have your little ecosystem work the way you want it to work for your language, and you also (to be clear) absolutely can do this without having to be Apple and controlling the "system" dynamic linker (which again is itself just a convention really) to add features as they do with Swift/Objective-C. (Hell: even just having an alternative C standard library on your system demonstrates a separate linker ecosystem as the C dynamic linker is effectively shipped as part of the C standard library.) The only thing that matters here is not the disk format or the mechanism but how it would be packaged and the tradeoffs on when time has to be put into baking them.