Hacker News new | ask | show | jobs
by steveklabnik 2032 days ago
Rustup has been about managing multiple rust versions since the beginning too. The tool it replaced was “multirust,” even.

That said, I do think it has to do with the age and strategy used. Ruby and Python hark to the days of everything being global by default, and so these tools set up clean room environments. rustup doesn’t create an environment, it keeps track of various tool chains, and defaults their binaries to the appropriate one. Cargo dependencies are already local to the project, and aren’t “installed” globally like in older versions of those systems. So like, I think you’re spot on with the broader point, but rustup has always supported multiple tool chains well.

1 comments

I kind of wish to have a global environment where the same crate in the same version but with different feature flags (or other differences in the build) were treated as different builds. If this actually worked (and the global dependencies didn't interfere with each other), this could pave way to a binary cache over the Internet so that we don't need to recompile the same crates over and over and over again for each project.

Kind of like Nix and its binary cache, but for Rust. I mean, Nix handles global packages just fine (unlike Python and Ruby). An Internet cache for Rust could be hosted by the Rust team (for public crates on crates.io) or be provided as a service for private code like Cachix[0].

PS: I know there is sccache, but it isn't suitable for a global binary cache.

[0] https://cachix.org/