If you look at the way the rustup-init.sh script is written it's safe to be used with this "anti pattern". I see your objection though but unfortunately this ship has sailed, you might as well complain about websites that don't work without Javascript...

The advantage of this method is that it will work on any linux distro (and even BSD, Darwin and mingw) and you'll get the latest stable version. I don't see the advantage of using potentially outdated OS packages for installing a compiler, it's not like it's a dependency for other packages.

It also makes it easy to manage the various components of the toolchain, for instance if you later want to crosscompile for an other target, use the nightly version etc...

That makes no sense. If one curls to bash obviously they can't "look at the way the rustup-init.sh script is written".

The ship hasn't sailed and neither has the sites without JS one. You have made a decision to favor covenience instead of security and you're trying to make it look like it's the normal state of affairs.

Rust can be installed by downloading the appropriate package and checking it with gpg.

Recommending curling stuff to bash is ridiculous and makes a mockery of the idea of safety.

You're planning on downloading binaries and gpg keys from that site anyways. Either you trust it, in which case you might as well curl | bash, or you don't, in which case you shouldn't be running that script no matter how carefully you inspect it.

And of course you can inspect the bash script (not that it does you any good), curl > file; bash file. It's just that most people don't so that's not what is recommended .

No, you're completely wrong. The key is available in multiple places and has been available for a while, so there is some verification that can be done.

The binary will be checked by gpg, it shouldn't matter where it's from.

Finally, if the recommmendation is to run curl foo | sh, the bash script can literally not be inspected.

Just separate the steps? Curl to a file, inspect it, and then execute it? I don't see the problem. Most users just don't care because it's official anyways.

Rust is a language in active development, continually getting improvements and new features. Using Rustup is the best way of managing up to date toolchains (and multiple toolchain versions if you have to).

It's no harder than apt-get install, and sets the best practice early on so that someone doesn't get confused and have to switch later.

"curl | sh" is only an anti-pattern in the sense that you have to trust the source (and therefore "curl | sh" without https is bad). It gives exactly the same ability to execute arbitrary code on your machine as downloading an RPM/DEB does, or adding a vendor specific repo (e.g. Docker). Distro package repos probably have broader scrutiny of the contents of packages, but there are a lot of packages so how sure can you be?

I agree with your main point, but would like to add that apt does have additional signature verification with gpg, so it's a bit more secure than just https (e.g. anyone with access to a trusted CA and your network can mount an active attack against you).

HTTPS also doesn't guard you against someone replacing the binaries on the server (e.g. what happened to transmission). It also doesn't protect you from misconfigured corporate or state level MITM firewalls that don't check certificate validity.

HTTPS is intended for transport security. Using it for package authentication is generally a mistake. That's why most distributions accept the additional complexity of PGP instead of only relying on HTTPS.

I think distros package rustup too. Here on Arch it is pacman -S rustup (instead of the curl | sh thing) then proceed normally.

Installing an outdated toolchain makes little sense because after this example people interested in Rust may want to do other things, and will encounter an artificial roadblock when they (or a worse, a dependency) needs a newer Rust.

I think the Rust packaged in the distros is meant to be a build-dependency of software written in Rust (for example, ripgrep), not for Rust developers.

This is true for the rust compiler included in the opensuse repository - its only there to build packages (of which the newly released Firefox is and has been since 54)

Arch has Rustup? Today I learned. That's amazing!

I edited the article including a reference to rust-toolset which is available on RHEL repositories `yum install rust-toolset-7` https://developers.redhat.com/blog/2017/11/01/getting-starte...

Rustup is very useful for managing toolchains. For someone new to Rust, it's probably best to be familiar with it from the outset.

> using Rust 1.14 of Debian/Stable should be fine, shouldn't it? Same of Fedora, etc.

That is a RedHat developer blog. Is rust available on RHEL already? Looking at CentOS (which should have nearly the same packages), it doesn't appear to be available yet.

This stuff is in preview https://developers.redhat.com/blog/2017/10/04/red-hat-adds-g...

You can download the rustup bootstrapper if you don’t like curl to bash. I would recommend against using the debian packages.

Debian packages integrate better with the system, are authenticated by gpg, and have at least one more critical pair of eyes on them.

If you're willing to stick with an older version of cargo and rustc, why not?

Because the ecosystem is not. A lot of what’s on crates.io needs the latest and greatest version.

That's a very good point. However, choosing to use a specific version already implies forgoing anything newer than the next release. This would include language features and crates (generally).

Thankfully, crates.io lists the dates next to crates so that users can select a version that is released before or during the release cycle of their compiler, thus guaranteeing compatibility.

Packaging Rust for Fedora/RH distributions is a work in progress ATM:

https://fedoraproject.org/wiki/Changes/Packaging_Rust_applic...

You can install rustup using your package manager and then use it to manage your Rust installs.