top | item 24448176

(no title)

Steve, thanks for all your work on Rust!

I'd like to understand more about the arguments for and against a URL-based module naming / resolution approach. Could you point me to any past discussions on this for further reading?

discuss

steveklabnik|5 years ago

You're welcome!

I am not 100% sure exactly what you're asking for, so if you could say a teeny bit more than that, that would help me understand what part of the space you're trying to explore. It would also be handy to know what problem you are trying to solve, there are several here.

andrewrothman|5 years ago

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!