Rustup 1.23.0 | Hacker News Reader

Rustup 1.23.0

blog.rust-lang.org

104 pointspietroalbini5 comments

> What's new in rustup 1.23.0

> Support for Apple M1 devices

For those skimming

Kind of a meta point, but it's interesting to see some languages adopting the "-up" convention (rustup, ghcup) and some going for the "-env" convention (rbenv, pyenv, crenv). I'm sure there's a lot that I'm missing for both.

Probably partly with how they started. Pyenv is meant to manage multiple versions of Python. Rustup is meant to update Rust. It's possible to have multiple versions of Rust installed (not just stable + nightly, but multiple versions of Stable, for example) but that isn't the main point of the tool.

The "env" tools are about managing the environment the (interpreted) application runs in. The "up" tools are about managing the compiler & toolchain of a language, and make no difference to the applications.

Of course someone will go and make pyup to manage Python versions without changing the environment just to increase confusion.

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.

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/

Reply on news.ycombinator.com