[simplotek]

> since it enables a lot of cool tooling

What leads you to believe that the lack of alternatives leads to enabling "a lot of cool tooling"?

> and great new features are introduced quickly in the official implementation.

That has zero to do with existing only a single implementation, and everything to do with having developers working on unstable releases and a poor job thinking things though by writing stuff down both as proposals and specifications.

If there is a specification that was discussed and thought-through by competent individuals, nothing stops anyone in the world from reading the specs and implementing the same features.

[pornel]

> What leads you to believe that the lack of alternatives leads to enabling "a lot of cool tooling"?

Rust projects have settled on Cargo, which gives them uniform way of building, testing, getting dependencies, docs generation (https://docs.rs), IDE support, etc. (https://lib.rs/development-tools/cargo-plugins)

Contrast this with C which has several compilers and plenty of build systems to choose from, often more flexible and advanced than Cargo, but the fragmentation means that C projects are snowflakes, and tooling needs to be configured for each project and compiler combo. For every build system X there's someone who says it sucks and you should be using Y instead.

However, I don't think GCC will cause similar fragmentation problems for Rust, because there are already 100K rustc+Cargo packages in existence, so it has no choice but to follow and be compatible with them.

[surajrmal]

Cargo is not universal. Many projects use rustc directly with an alternative build system such as bazel, make, or meson as they are in multilingual repos. The fact these projects exist doesn't affect your experience with rust. The fact a gcc tool chain for rust will exist should similarly not affect your experience.