Yes. I might as well take the time to elaborate on the history here.
In the beginning, there was rustup. And it was good. Then, Rust matured, and we started the release channels. Now there wasn't just "Rust 0.9", there was Rust stable, beta, 1.0, 1.1... so many versions. rustup.sh wasn't really built to handle that.
And so, multirust was born. mutlirust was/is a bash-based shell script that wraps up rustup and gives you the ability to manage multiple installs of Rust. And fun things like "this project uses rust stable, but this project uses Rust 1.1" and "please update every Rust I have installed". Stuff like that.
But it was a bash script. Nobody knew that this whole Bash in Windows thing was happening. And we already have a perfectly good, general purpose programming language that runs on all the platforms Rust supports: Rust! So the multirust-rs project was begun, to re-write multirust in Rust.
And so, "rustup" was born. It's pretty much multirust.rs, but without trying to mimic the old multirust itself. There's still lots of stuff to do before it's ready to become the default way you manage rust installations: https://internals.rust-lang.org/t/beta-testing-rustup-rs/331... and https://github.com/rust-lang-nursery/rustup.rs/issues?q=is%3... And of course, many people will want to use their system package manager too. Choice is good. They also play together. But that's for another post, this one is already getting long.
It's always much preferable to have as few dependencies for bootstrapping a platform as possible. Therefore, this is a good development.
Similarly, I'm hopeful the Python requirement in the new Rust based build system for rust itself will be removed sooner than later. Building Rust already requires Rust, so what's more logical than replacing the Python part with Rust. It will definitely be easier to get going than having to install some Python modules first. Same improvement should happen in servo's build system which since a few months or a little longer depends on virtualenv.
In the beginning, there was rustup. And it was good. Then, Rust matured, and we started the release channels. Now there wasn't just "Rust 0.9", there was Rust stable, beta, 1.0, 1.1... so many versions. rustup.sh wasn't really built to handle that.
And so, multirust was born. mutlirust was/is a bash-based shell script that wraps up rustup and gives you the ability to manage multiple installs of Rust. And fun things like "this project uses rust stable, but this project uses Rust 1.1" and "please update every Rust I have installed". Stuff like that.
But it was a bash script. Nobody knew that this whole Bash in Windows thing was happening. And we already have a perfectly good, general purpose programming language that runs on all the platforms Rust supports: Rust! So the multirust-rs project was begun, to re-write multirust in Rust.
Once that started to become closer to being finished, we took a step back, looked holistically at all of this, and thought "If we started from scratch, what would we do?" https://public.etherpad-mozilla.org/p/rustup-new-experience
And so, "rustup" was born. It's pretty much multirust.rs, but without trying to mimic the old multirust itself. There's still lots of stuff to do before it's ready to become the default way you manage rust installations: https://internals.rust-lang.org/t/beta-testing-rustup-rs/331... and https://github.com/rust-lang-nursery/rustup.rs/issues?q=is%3... And of course, many people will want to use their system package manager too. Choice is good. They also play together. But that's for another post, this one is already getting long.
You can find rustup here: https://www.rustup.rs/