A feature not wanted by Software developers, developing for multiple platforms. For systems packagers, this is a required feature. Shared libraries delimit the boundary between two responsibilities. And if those people coordinate then that works well. It becomes a system. There are limits to where this can happen. So I don’t know what the perfect solution is. If shared libraries are needed at all or if that feature can fade out. But it is worth a try to build systems and to give people the possibility to do so. So I would wish Rust and Cargo gained shared library support so that we can build such componentized systems easily.
For example, last I heard, reconciling monomorphized generic types and static dispatch with loaders like GNU ld was still an unsolved problem and Option<T>, Result<T, E>, Vec<T>, etc. are pervasive in Rust code, with the limitations imposed by “vtables are referenced by the fat pointer to the struct instance, not stored in the struct instance itself” making dynamic dispatch something you reach for when the discomfort merits it.
Taking lessons from C++ and from Firefox being forced to implement -webkit--prefixed CSS properties, Rust has doubled down on refusing to let their default ABI become de facto stable, though they areworking on an opt-in stable ABI akin to how, if you want to expose a stable ABI from a C++ library, you’re expected to use things like the PIMPL pattern. (And, likewise, there’s the third-party abi_stable crate which is essentially a PyO3/Helix/etc.-esque binding generator/data-marshalling abstraction, but for generating bindings from Rust to Rust via the C ABI instead of Rust to something else higher-level than C.)
(I get the impression that reproducible builds are the only reason they didn’t make it a default thing to randomize ABI layouts when there are multiple solutions to the automatic struct packing to push back against Hyrum’s law.)
Unfortunately, easier said than done. Rust takes all the reasons that dynamic linking struggles with C++ and turns them up.
For example, last I heard, reconciling monomorphized generic types and static dispatch with loaders like GNU ld was still an unsolved problem and
Option<T>,Result<T, E>,Vec<T>, etc. are pervasive in Rust code, with the limitations imposed by “vtables are referenced by the fat pointer to the struct instance, not stored in the struct instance itself” making dynamic dispatch something you reach for when the discomfort merits it.Taking lessons from C++ and from Firefox being forced to implement
-webkit--prefixed CSS properties, Rust has doubled down on refusing to let their default ABI become de facto stable, though they are working on an opt-in stable ABI akin to how, if you want to expose a stable ABI from a C++ library, you’re expected to use things like the PIMPL pattern. (And, likewise, there’s the third-party abi_stable crate which is essentially a PyO3/Helix/etc.-esque binding generator/data-marshalling abstraction, but for generating bindings from Rust to Rust via the C ABI instead of Rust to something else higher-level than C.)(I get the impression that reproducible builds are the only reason they didn’t make it a default thing to randomize ABI layouts when there are multiple solutions to the automatic struct packing to push back against Hyrum’s law.)