Cargo is the one thing keeping me off the rust ecosystem. The fundamentals of the language are great, but the tight coupling of the rust language with cargo's package management really irks me - it introduces as many correctness and security problems as the memory model solves.
I like rust, but I detest cargo. I don’t like that it forces a particular structure that makes every project feel like a visual studio template. I also don’t like that it has an single authoritative registry that it pulls packages from on build. This means that someone somewhere has too much control over the build process, and that I can’t work where there’s no internet access.
I would be curious to hear what are your criticisms of cargo, too. Recently I am trying to study about dependency management in different languages, and cargo, along with bundler seems to be praised quite a bit. I can't correlate it with quality because both rust and ruby camps are quite vocal.
The problem with Cargo is it only builds rust. I agree it's the best language-specific build tool, but I love the monorepo pattern and future proofing insurances that modern language agnostic build systems like Bazel enable / provide.
It's unfortunate that Rust is so tied to cargo, and unfortunate that cargo insists on allowing multiple versions of a dependency. If you point out that cargo is poorly designed everyone just yells and you and says you don't understand.
I don't want anything in my Rust dependency tree depending on node packages.
By being hermetically sealed, the community can make progress on testing, repeatability, and lots of things that would become incredibly difficult if you introduced anything else into the mix.
Moreover, each language gets to innovate in its own way. Cargo is fantastic and fits the needs of Rust quite well. Custom builds, cross compiling, codegen, ...
I'd like to echo the author in that Cargo is the best language package manager/build system I've had the pleasure to use.
However, there is one serious problem with Cargo's packages: They simply aren't authenticated. Cargo's developers acknowledge this issue and there is a proposal to amend it by adopting the TUF [1]. but this issue doesn't seem to enjoy the attention it deserves.
As a person living in a country that increasingly edging towards going the Kazakhstan route where all secure traffic will be MITMed, simply relying on transport security as a way to secure crates is not sufficient. and that's ignoring compromises due to server security failures. At present, my only options are to include the entire dependency tree in crate or avoid dependencies altogether.
Even ignoring my problem (which wouldn't effect a large number of rust developers), Mixing transport security with authentication and integrity shouldn't happen in vital infrastructure like a language package system.
There are other problems like not representing system libraries that a crate depends on in the project manifest, but unauthenticated crates are a ar more serious problem.
I initially was interested in Rust because of performance + speed + safety, but now I have to say that cargo is a big selling point for me.
I always used to be scared of compiling software myself because I never seemed to be able to get it to work without endless headaches. Now, I generally find it easy to compile Rust programs if they aren't in my package manager, and with cargo install-update https://github.com/nabijaczleweli/cargo-update I find it easy to keep the software up to date. I have higher confidence that I can get hobbyist Rust software working, and the more Rust software I use, the more familiar I am with the ecosystem and the more comfortable I am.
If this was written in some obscure language I wasn't familiar with, I'd be less confident I would be able to run it at all, let alone keep it updated, and I may not bother even trying to install it.
I like many things about Rust, but Cargo alone is what initially got me started with it. I was in the process of setting up a fresh C++ project with vendored dependencies, and it was just an absolute nightmare. In contrast, it took me about 5 minutes to get a Rust project set up with comparable dependency complexity.
I've only started scratching the surface, but that rust really wants you to use Cargo, while we have our own homegrown package manager, and cmake creates a lot of friction.
I can tell you that bad programmers can write bad code in Rust.
I upvoted you for the first six lines, while feeling compelled to chime in that cargo is great, an example of Rust doing things right imho.
I'd rather have a thriving and single (looking at you Python) ecosystem of third-party packages, than a standards-driven pile-on of standard libraries, with all the footguns and deprecation that tends to come with it.
Cargo is built in a way that makes it very difficult to avoid and yet it fails to understand basic cross compilation cases correctly which make it (ironically) infuriating for people working on embedded use cases as well as for people attempting to do production binary deployments. Meanwhile, the tool just fundamentally refuses to support reproducible builds in such scenarios even though Rust is fully capable of it (I finally had to write a wrapper for the Rust compiler to munge a the arguments passed by Cargo to remove their semantic mistakes).
I feel like the problem is that it isn't just a package manager... it insists on simultaneously being not only "a" but "the" build tooling, which is trading way too much flexibility for a very small amount of convenience. And like, OK: maybe this is useful for people who are just getting started, but I would firmly argue that this kind of tooling should consider the needs of the expert and not make severe tradeoffs for the needs of the beginner unless it is trivially and obviously optional and there can be growth through changes in tooling (where maybe people "graduate" from Cargo to a more extensible tool... but since it is also the package manager, that's brutal).
The issues for the tool are then riddled with bugs that have been open for years (I think some of the ones that I've been blocking on might already be at 5 years, which is shocking to me as I don't even think of it being very old) that even often have multiple reasonable pull requests filed but where no progress ever gets made on fixing the problems because, even though it is often trivially shown that there is no way to use the tools correctly currently in the general case, they insist that the behavior of a working tool might break some theoretical user relying on the current inconsistent set of behaviors.
The result of all of this is that there are a ton of workarounds for Cargo that projects have started to have to embed almost as boilerplate into their projects, including a popular one that is going around right now (required for Linux->Linux cross) involving setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly. It is honestly infuriating and ridiculous and there are good reason why you keep seeing stuff like Google avoiding it entirely as part of their Bazel integration.
There's a lot of hype around rust which may or may not pan out, but cargo should really be the gold standard for package management/build systems going forward, it's incredibly well designed.
Everything is painless and integrated: builds, tests, benchmarks, publishing, installing dependencies, downloading cli binaries.
When you eventually have to go back to all the other hacked together Frankenstein alternatives out there it's a painful, frustrating experience.
Cargo is .. not a pleasant build tool to integrate into other build systems. If you have a project (like mainline ruby) where the dominant mode is C and you need to integrate some rust into it, you will eventually feel like it'd be a useful use of your time to bypass cargo and use the compiler directly.
Cargo is a fantastic tool, easily one of the best of its ilk, but real talk: it needs to be normalized that sometimes you don't want or need to use it. It is fit to a very specific set of tasks (mostly producing stand-alone binaries), and that set of tasks is a subset of the tasks rust as a whole is fit for.
cargo, at least, does this for the reason Fellshard gives - the Rust team essentially commissioned a copy of Ruby's bundler, without considering whether there was anything to learn from any other language's ecosystem.
What I don't really like in cargo is its' overcentralized and author-centric approach. What if some of your dependencies relies on the crate, which author doesn't support anymore and doesn't even accept patches? You will basically have to maintain a fork either with a different name (because you can't push it to crates.io) or have a patched version which you also can't push and have to manually update every Cargo.toml of every dependency in your project to use your fork. And what if you have not only one Rust project in your complex system? You will have to update or vendor everything. This is a real maintenance hell.
While in C/C++ I can just build a fork as dynamic library and put it to the system image or to the own package manager repo.
I mean for sure Cargo is great for small hobby projects, but for the big complicated enterprise projects it's not really suitable. Even Google doesn't use Cargo in Fuchsia and vendors everything.
True in principle. But once you divorce yourself from Cargo, almost all resources and advice when it comes to building Rust programs go out the window. I love the language, and I love the community, but the attitude of "rustup nightly and Cargo, or bust" is bit terrifying.
As a noob, I had to wade through endless "but don't do that, just get the latest from Cargo!!!!" when I asked for advice on how to use my system-provided Rust packages for my project.
reply