What I say is, that the current infrastructure and distributions doesn’t treat rustc+stdlib as its own thing, that nobody will target it and everyone assumes Cargo. That’s just an assumption you are making. In fact, if anything, it’s easier to assume rustc than it is to assume cargo, because cargo needs rustc, but rustc does not need cargo… so if you really were looking for the most universal cross-distro assumption, then it would make more sense to assume rustc (which has to be installed to have cargo anyway) than to assume cargo. I think the g++ comparison doesn’t hold here, because it’s not the only way of using the language. I’m not sure what do you even mean by that… Well it needs to be a standard in most common distributions. No one wants to rely on something that is found in one distribution only. A lot of things aren’t standard across distros. gcc itself is packaged differently often… do you think nobody wants to rely on it? How many distros do you need to do the same? Debian doing this means that essentially all apt-get based distros follow the same approach of separating rust and cargo (Ubuntu, Mint, and all the variations). Also in Fedora / RHEL / AlmaLinux / Rocky Linux… “rust” contains rustc, cargo is split to its separate “cargo” subpackage. Also Alpine Linux, cargo is a separate package from rust. Void Linux, also cargo separate package from rust, NixOS, has pkgs.rustc and pkgs.cargo as separate derivations.