What do you all think about how the entry point to Rust is (almost) always through Cargo? Users almost never invoke rustc/rustdoc/rustfmt directly; instead cargo is used. As a result, you rarely invoke a command with "Rust" in it. Other languages (e.g., Elm, Go) use the language's name as the entry point to all the tools, and I could imagine a world where you use rust build, rust fmt, rust test, etc.
I don't have anything against Cargo and neither way is necessarily better, and also it doesn't make sense to change at this point, but I'm curious to hear what you think.
As a long-time make user, it makes no difference what the name of the command is, you still have to learn it. There are no intuitive command line invocations, they're all learned idioms.
One interesting thing that I just realized about if we used a rust base command is that several commands (at least rustfmt and rustdoc) would look extremely similar – perhaps too similar – to their package-level equivalents:
It's a fun idea. rust as a top-level command would work well for many things. It does indeed seem far too late to entertain the possibility of such a substantial shift, but it would work.
I think it's pretty great actually. It means I have to be intimately acquainted with fewer tools on a day-to-day basis, and it provides a natural integration point for the ecosystem.
As for the fact that the current command cargo is used rather than something with rust in it: personally I care more about how difficult it is to type (and happily, typing the word cargo takes little effort) or how long it takes me, than the actual term. What's in a name, anyway?
That said, rust doesn't take a lot of effort to type in either.
I distinctly remember discussions of the "unified rust tool" at the all-hands in 2018. I think there's some merit in merging rustup & cago from the UI point of view, but it also makes sense to keep them separate from the implementation point of view.
I don't see the cost is prohibitive, if the roll out is three stage: first we add rustup&other capabilities to cargo, then we add rust alias and shims in place of the old binaies, then we say that rust is the preferred new default.
One specific aspect of this unification we should pursue though, is putting the target management into cargo (where it belongs logically), such that cargo build --traget tripple just works without doing rustup target add tripple. But this depends on all kinds of "fun" cargo features, like build-std and binary dependencies.
I would love to see rustup integrated into cargo for another reason: we've talked about allowing a crate to declare a dependency on a binary, and that could include a target: "build xyz for wasm32-wasi".
Would also allow dependencies on a newer Rust version.
I think the current situation is fine. Cargo isn't Rust. Cargo projects aren't the only way to use Rust (even though it's by far the most common).
You write cargo fmt, because it formats the current Cargo project.
If anything, I'd rename rustup to rust. rustup doc opens Rust documentation, but that has nothing to do with rust updates.
There's also a bit unfortunate functionality overlap between cargo install and rustup component add (e.g. clippy used to be in both places). Rustup supports precompiled binary packages and auto-updating of already-installed packages, while Cargo doesn't. OTOH rustup isn't installing from an open registry. Cargo planned to expand its installation capabilities, but maybe it should be rustup opening up its installation?
The conclusion of these discussions as I recall was that it would be great to unify the rustup CLI with cargo's CLI(and frankly, revisit the rustup CLI entirely, because the current CLI is quite a mess), but that rebranding cargo as rust didn't seem like a good idea at this point. cargo has a strong existing brand.
In terms of addressing known problems naming doesn't affect the technical merits
though the point being raised is that it does represent intangibles. In this
case crates.io absolutely underlines what makes Rust awesome and has developed
a well-earned identity and positive reputation as a result of the clear logical
(and naming) consistency between the tooling and the platform.
Cargo as it exposes dependency management within Rust crates can be very
surprising for deeply technical reasons. Simplicity is beauty and cargo has an
important role in keeping Rust easy to approach. There are some interesting
suggestions here on how these surprises could be addressed. Without very much
tangible to contribute I have idly wondered at times about having more specific
tools with respect to whether the crate is a library or binary for example.
To me it's very important that Rust maintains its rich and diverse set of
developer tools which support a clear logical separation of coding from
building, formatting, and documentation generation, while on the other hand not
overvaluing various inputs or approaches being towed along stemming from
decisions made many decades ago simply because they may appear to be 'largely
correct' or 'conventional'.
Personally, I strongly prefer the former (Cargo expanding its capabilities) if we are going to choose one. I do not want to have to think about whether it's safe to install something via rustup – I want every component on rustup to be official and trusted. I think rustup should keep its niche of managing your Rust installation, not the installation of arbitrary 3rd-party tools.
Every time I try and propose fixing the CLI of rustup I get massive pushback from people. Even when all I want to do is to deprecate (not even remove) non-promoted aliases for commands.
Could the pushback just be a result of a selection bias, i.e. only people who are engaged power users of rustup are the ones who respond to such proposals, and majority of rustup users wouldn't mind?
Personally, I'm surprised that there's any pushback, and I didn't even know rustup had command aliases. But I don't use rustup much beyond running rustup update once in a while.
I think it's always fair that the people who complain are power users to some extent; but also just people who don't want to change their CI etc. It's possible I'd get away with quietly "just doing it" but it may make more sense if a unified interface with cleaned up UI were to be built, for that to organically take over from rustup etc, rather than being pushed as "the only new way".
you basically just did it.