Not exactly true. Google uses Bazel for Rust code. Also there are definitely nice features of Cargo compared to other build systems, especially C build systems.
But I think you're mostly right. Fragmenting the Rust build ecosystem would be quite annoying.
Google uses pure Bazel, rather than just a Cargo wrapper? I was under the impression that Bazel was for plugging build and dependency systems into - that's certainly how I've seen it used.
Bazel is generally much more useful when it can manage the entire build. https://github.com/bazelbuild/rules_rust implements this logic for rust. It calls rustc directly, without cargo for the build, and interacts with cargo through a shim to fetch/vendor dependencies.
I would assume though that any software they release that might be useful to the general public will also have the cargo files. Which will then be well-maintained and in-tree.
As well as the features that bazel provides you. The caching, packaging, code gen, cross-language deps/interfacing, and other magic that make bazel extremely amazing to use.
> Internally at Google the vendor all source code and make it build using bazel.
It sounds like that is done for consistency, to make it easier for Googlers to move between projects written in different languages, and to lower the cost of setting up new projects into their existing tooling and infrastructure?
I don't think that's really a comment on whether Cargo is good or bad, so much as a language agnostic approach to managing code that Google finds works well for them.
If you're not Google, you're probably better off using Cargo.
This is not done only for consistency reasons. Cargo does not support building other languages than Rust well. When you have projects that span multiple languages, your build system needs to know about dependencies between pieces that cross the language boundary and also needs to know about how to produce libraries, perform linking, etc. On top of that, lots of infrastructure features like remote workers, build artifact caching, etc are just not supported by Cargo.
Disclaimer: I don't have insider knowledge of how stuff actually works at Google, but I've been using Bazel in cross language environments for a couple of years now and I have read the papers on Googles build infrastructure.
Cargo works well for building C dependencies, in my experience. I haven't really needed (from Rust) to depend on anything written in Java or some other random language, so my experience there is mostly non-existent.
Advanced "infrastructure features" you're describing just aren't important for most companies that aren't Google-scale. Compile time on CI is plenty fast without that, in my experience using Rust professionally.
I've got a python project that depends on a c binary that depends on an shell script that depends on another binary.
Bazel let's you do this without caring about how your deps work with hermetic assurances on top.
Obviously this doesn't mean cargo is bad or worse or anything like that. It's just that it targets a different use case. Bazel targets many languages, with many targets, by many teams, in many ways. Cargo targets the Rust ecosystem, isn't hermetic, ist't reproducible by default, etc. BUT it's a great experience for rust.
> Advanced "infrastructure features" you're describing just aren't important for most companies that aren't Google-scale.
I've seen several C++ code bases with a few hundred developers working on them taking several hours to compile. I'd turn your statement around and say that any non-trivial commercial C++ and Rust code base will need compiler caches and other advanced infrastructure or productivity will go down the drain.
CircleCI offers build caching that works well enough, for example. It's not the super advanced stuff that Bazel can do, but you don't need Bazel to do build caching.
When the Linux kernel (~27 million LoC) can be compiled from scratch in under a minute on modern machines (30 seconds on some of the beefier machines)... there's clearly a lot of low-hanging fruit in that "hours long" compilation that has nothing to do with build caching.
Whether you can get stakeholders to buy into paying down technical debt or not is an unrelated discussion. Sometimes it's easier to sell fancier build systems as the solution instead of better code organization and simplifying overly generic code.
But I think you're mostly right. Fragmenting the Rust build ecosystem would be quite annoying.