In C++, there is at least a good way to link many separate libraries that need to share the static into a single DLL. The rustc dylib crate type can't be used in that way, and bundling crates into a cdylib library to achieve the sharing has the disadvantage that you have to define & expose a C ABI from it and unsafely interact with it from the rest of the application.
This incompatibility can lead to basically three different outcomes:
- greatly inhibits adoption of generic statics (because it breaks clients of your libraries; and if this is a concern then using generic statics internally in your library becomes a semver-breaking change)
- effectively kill the remaining uses of
dylibbecause they can't use a large portion of the ecosystem - a middle way, splitting the ecosystem into code that (transitively) uses generic statics and code that is compatible with
dylib
The first and last option are clearly pretty bad outcomes. I wouldn't mind killing dylib, but if one wants to go that route then one should be honest about it and formally gather consensus to really kill dylib as well as hypothetical future ways to build Rust applications that involve any sort of transparent dynamic linking.