I should be clear my interest is theoretical. I haven't run into any practical issues with "crates.io" and it's been working great for me.

I think the way Go and ES Modules (Deno / browsers) represent module naming and resolution by URLs has some nice benefits:

  * decentralized module hosting

  * could be extended beyond HTTP / Git (ie. import modules via "ipfs://")

  * re-uses existing web infrastructure for namespace ownership (ie. via DNS)

  * possibility of hosting backend and frontend modules for multiple languages in a single HTTP registry

However, I do see some important tradeoffs to that approach:

  * modules may become unresolvable from their original URL (link rot)

  * cannot guarantee immutability at the original URL

  * semver support becomes a concern of the registry, and some registries may not support it (ie. the logic to resolve "https://example.com/my-module/1.x.x/lib.rs")

  * more difficult to discover (browse and search) all available modules

I see some proposed solutions to the tradeoffs:

  * proxies and dep lockfiles of file hashes to help prevent link rot and immutability

  * possibility for open source registry implementations with built-in semver support

  * central index of modules which can be searched / browsed, if modules are submitted to it

However, those solutions don't guarantee fixes for every tradeoff.

I'd be very interested in learning more about the costs / benefits of the various approaches and the Rust team's discussions on modules. I really appreciate the team's thorough approach to design decisions, as it's manifested into a really cleanly-designed language.

Thanks!