I don't get why you're explicitly arguing against postfix await. If you're worried about language complexity, then any form of async/await at all is going to be about equally complex. I can't see the postfix-await kvetching as anything other than pure bikeshed painting; it made lots of noise because it's a surface-level discussion that anyone can form an opinion on.
The endless proposals for control-flow operators, implicit conversions, delegation, and inheritance are leaving me a bit concerned, though. Rust can't do all of them, so no matter what the core team does, most of them are going to leave disappointed. Disappointed community members aren't fun to be around.
No... I already said why
curl | sh was a bad way to install things:
There's no good way to inventory all of the software installed on the machine. Configuration management systems want to inventory the installed software so that they detect whether a to-be-installed package is already installed or not.
There's no good standard way to operate a local package cache. The advantage of having this when you want to provision a couple dozen CI build servers should be so obvious that I refuse to bother writing it.
There's no good standard way to attribute files to the application that provided them. I, for one, prefer to be able to understand why files exist on my computer.
There's no good standard way to lock the version. I would like to be able to recreate a fresh system with a setup that used to be in play a few months ago, to be able to bisect issues and figure out which change introduced them.
Now, to the credit of the Rust release team,
rustc is not that hard to package. The Rust compiler doesn't need to run any system services, and it automatically discovers all of its paths relative to the
rustc executable. You basically just unpack the tarball, move all the files into place, and add rust's
bin folder to your PATH.