Projects never have to argue whether Cargo is better than Mergo or Ronan or Rustfiles or their grandad's bash script. All the tooling knows how to build any project. Every editor knows where to look for files. https://docs.rs can generate documentation for 40000 different projects using the same build command.
Because own, or project-specific package recipes, which contain dependency and build instructions, can just be added to the public package definitions (https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix...), this allows to deterministically and hermetically build multi-language projects on top of a very solid base. And for testing with another version of a C dependency (say, alsa-lib 1.1.9), one just needs a branch with another version number in the build recipe.
edit: How does it handle python wheels and other non-source language-specific packages?
Yes. You can install Guix as a package manager on top of your POSIX OS. Then, you have profiles, and you can install packages into your personal profile in your $HOME, or into temporary project-specific environments. You can also define the environment by writing a manifest file which list requested packages and their versions, and put that file under version control.
How it is used is documented here:
https://guix.gnu.org/manual/en/guix.html#Package-Management
> How does it handle python wheels and other non-source language-specific packages?
Of course you can install Python packages:
https://guix.gnu.org/packages/P/page/12/
If there are no pre-built packages for your machine architecture (say, you are developing on ARM), they are built and installed on your machine (or, a build server which you defined), otherwise you get automatically a compiled package from the Guix server. Also, and in difference to pip and so on, any needed C libraries will be installed as well, with the right versions. So, it is a bit like Conda, but it will also work if your project happens to mix, say, Python, C, C++ and Rust, and perhaps runs on mips or armhf. (My next side project will be a Game with a strategy engine in Rust, and a GUI written in Racket, just as an example).
I have not yet tried it with Python, but I can confirm it works with Common Lisp libraries. Basically, you can get anything which is FLOSS, and if you need proprietary stuff you might be able it via a non-free package channel (similar to Debian).
First, GNU Guix requires a POSIX system, and it will happily run e.g. on top of Debian in a suitable VM. (It will also run as a stand-alone OS which is nice if you want a bootstrapped, totally deterministic system - not good for gaming or casual development yet but there are serious long-term applications for that.)
Also, as said it will build from source only if there is no pre-built binary package available for your platform, otherwise it will use cached binaries. That's, for example, a great use if you need to use cargo with a complex multi-architecture set-up. Just don't forgot to add plenty of disk space - here is a good use for Terabytes-size disks. Further, you can also set up your own build server, which caches binaries.
The decision that it depends on the source code being available is rooted in the philosophy of the project; Guix is a GNU project and is intended to support Free software, as in FLOSS. I think this is also technically a good decision, because if the source code is not available, this leads sooner or later to practically unsolvable problems; think in all the expensive lab equipment in science which runs on decades old, obsolete, unsupported, unsafe platforms just because that expensive hardware requires a binary driver which won't run on more modern platforms. Or think in your scanner that stopped working after the last OS upgrade because the scanner vendor thought you ought buy a new one; that scanner will probably work fine under GNU/Linux, just as an illustration to the point being made.
The need to make software reproducible is especially important in science where the scientific method depends on that experiments, and their evaluation can be repeated, but there is just no budget to port everything to the newest Python3.x, or OpenGL Y, or Qt-Z, or Matlab-ω. Science is competitive, no less than business, and you don't make a career in science with porting old stuff.
But back to "Linux only" - right, there are platforms that Guix will not work on, like Windows. But complaining about that seems, at best, extremely naïve to me: By anyone who has the slightest knowledge in the matter it is well known that these proprietary platforms have literally spent decades on engineering to lock users in into their proprietary solutions. (And I think that the situation especially with C++ is in part a result of that, there is no inevitable technical reason that C++ does not have a standard ABI, or standard library discovery, it was just made that way to stop competitors similar to Borland's Delphi.)
Complaining that their OS (while claiming POSIX compatibility) does not support GNU Guix is justs as, perdon my french, just as silly as complaining that you can't fix the broken battery of your MacBook yourself by taking a screwdriver and replacing it with a standard part. You won't have a screwdriver that fits precisely because the MacBook's vendor thought that you are not supposed to fix it yourself. Of course, the marketing department will tell you that their platform is "compatible to open source" - I have a bridge to sell you.
These systems are just not designed for that, and the inability to use Guix on them is a consequence of your decision to use such a system; you are the one who will pay the costs of that, by having an obsolete scanner, or, far more expensive, by having obsolete, unmaintainable software years from now which is too expensive to port to a new supporting API.
As for the rest, I have long learned not to bring religion into enterprise.
If it is a market Rust wants to leave for C and C++ developers, fine, just don't pretend adopting something like Guix is a solution those shops care about. What they have now works and delivers business money, which is what counts at the end of the day.
But I think you're mostly right. Fragmenting the Rust build ecosystem would be quite annoying.
Google uses various non-cargo build systems to build rust. I don't think Google is actually using bazel for this internally, eg. Fuchsia uses https://fuchsia.googlesource.com/fuchsia/+/master/third_part...
These rules also show some of the open source versions of this work: https://github.com/bazelbuild/rules_rust
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.
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.
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.
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.
Your mileage may vary, of course.
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.
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.
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.
C++ code doesn't have to be super slow to compile: https://www.zverovich.net/2017/12/09/improving-compile-times...
I've been bumping into some tough limitations of Cargo lately, but it's still good enough to stick with it, and paper over them, rather than throw the whole thing out wholesale.