Rustup 1.23.0

Rustup 1.23.0(blog.rust-lang.org)

104 points by pietroalbini 5 years ago | 5 comments

danappelxx 5 years ago |

> What's new in rustup 1.23.0

> Support for Apple M1 devices

For those skimming

WJW 5 years ago |

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.

SAI_Peregrinus 5 years ago | |

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.

steveklabnik 5 years 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.