Bazel was first released to the public in March, 2015. By that time, Cargo had already been in development for over a year, had reached release 0.1.0, and was a

Bazel was first released to the public in March, 2015. By that time, Cargo had already been in development for over a year, had reached release 0.1.0, and was already the official build tool for most Rust projects. Furthermore, Bazel and Cargo are aimed at slightly different use-cases. Cargo is tailored towards Rust, is integrated with a Rust package repository, and can use it's knowledge of Rust to allow for builds of pure-Rust projects with a lot less configuration. Bazel is a more general purpose build system, but that means it requires a little more configuration. There's no reason you couldn't use Bazel for building a larger project that includes Rust and C, C++, Java, or other languages that need to be built, but Cargo makes it a lot easier and simpler to handle pure-Rust projects than it would be in Bazel. Many of the other tools that you mention don't require just more support from the build tool, but also significant engineering effort on the part of the compiler, or a separate static analyzer, or other development process tools. These tools are desired, there just isn't anyone who has had the time to design and build them. As to why Clippy is separate from the compiler, there are a couple of reasons. Adding more lints to the compiler, especially ones that are turned on by default, can cause problems as well. Any time you add a new lint, you may break people's code that has #![deny(warnings)] turned on. Even if people don't, a lot of people will still try to rewrite code to make it comply with lints; but that in itself can cause problems. I've seen many bugs introduced over the years by people trying to do too many lint cleanups at once, and making mistakes in some of their cleanups. For this reason, the Rust compiler is fairly conservative about adding new lints.. That said, it sounds like there are plans to integrate Clippy with the compiler and cargo, but probably as an opt-in separate command rather than being included in the default set of warnings: https://www.reddit.com/r/rust/comments/5ibr2a/cargo_check_has_been_merged_into_cargo_directly/db775vd/ https://www.reddit.com/r/rust/comments/5ibr2a/cargo_check_ha... Code coverage is another example. You can use some existing code-coverage tools with Rust (https://users.rust-lang.org/t/tutorial-how-to-collect-test-coverages-for-rust-project/650 https://users.rust-lang.org/t/tutorial-how-to-collect-test-c...). Because there are tools out there that work, there's less of a pressing need to get code coverage integrated with the Rust toolchain; I think that it would be a good idea to do eventually, as it will make it easier to do cross-platform and out of the box, but for now it's not the highest priority. So, I don't think that any of these omissions are due to a difference of philosophy; just a difference of focus. Rust is all about admitting that programmers aren't perfect, and that better tooling can help avoid mistakes and thus make developers more productive. Right now, that focus is on things like improving the compiler (adding MIR, which allows for fixing several bugs in the compiler and doing some Rust-specific optimizations before getting to LLVM), implementing the Rust Language Server which can be used as a backend for IDEs, improving the ability of the compiler to do incremental and parallel builds, and adding language features with a focus on making Rust easier to use.