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.
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 think it's easier for Rust (and other languages such as D, Crystal), because they started from scratch. Cargo is accepted as the way to build and distribute stuff on Rust, full stop. There are no endless debates whether Cargo should be used, or something else.
Meanwhile, in C/C++ world, build systems are a mess. You have so many tools. Some folks just use what IDE provides, e.g. MSVC solutions. Some people use CMake. Some people have their handcrafted Makefile solutions. Sure, it works on their platforms, but it's very hard to make it portable. With Cargo and similar, you just go "cargo get" (don't know the exact command, don't use Rust) and you can expect the packages to download and build as needed.
I beg to disagree.
Sure, when you want to have a small project that only uses crates.io d'EPS, Cargo is simple and gets the job done.
But once you want to do something a bit more complex, (like getting a dependency of something not written in rust, or picking features based on some system configuration), you quickly get to the limitations and there is not much you can do.
Cmake on the other hand is very powerful and you can build very complex applications with 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.
As much as I agree that Rust needs a better story for builds and interacting with other languages, it sounds like you have a misunderstanding over what Cargo primarily does and what crates are. A crate is a single compilation unit of Rust. Cargo is a tool for compiling crates and pulling in other crates that it references.
build.rs is a half measure to include foreign symbols in compilation artifacts like static/shared libraries and executables. I'd go so far as to advise against using it for anything but specifying linker flags.
I don't think I've ever had a use case for specifying dependency versions at build time. That seems insane, and I do insane things in cmake with regularity. There's a reason versions are pinned to a config file committed to repos in almost every contemporary language.
fwiw, Cargo is a crate itself and you can use it as a library. You can even compile it with C language bindings to call through FFI in other build systems if you felt like it. The lang tools team has done a great job with keeping the scope of Cargo manageable and putting in the ground work to make better tooling around it.
For complex Rust builds, check out cargo-make. It does most of what you'd need in a predominantly Rust codebase. For polyglot environments, cmake with custom targets is the least bad way I've found to do it - and it's not hard to do that by shelling out to Cargo.
I just recently started learning rust a few months ago, and I came to the same conclusion as you about packages. Cargo seems like the biggest impediment to Rust. GCC-Rust may put Rust on track to have a decent STL since (presumably) GCC will not import a package manager. However, insisting that a package manager have first-class treatment for a systems language just seems wrong.
On the other hand, the Rust STL itself is full of bit-rotting functions that have been stable for years but are still somehow only in the nightly release and haven't made it out of "experimental" status. I assume that the presence of Cargo in the ecosystem and the mentality that you can just use a crate to do what you want is a big part of this.
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.
Cargo is not de facto better than vcpkg. That Rust has a blessed package manager instead of community of competing package managers is a lateral, neither better nor worse.
Here are the problems I've had with other build systems, as a noob, that I have not had with Cargo:
- Having to learn weird syntax and constantly look up the reference manual (CMake)
- Having to manually add source files (qmake)
- Sometimes it just needs a clean and nobody knows why (Visual Studio)
- Having to remember to set up debug and release builds and decide your directory layout for everything and figure out what 'a shadow build' is and who gives a crap since it all takes too much HDD space either way (qmake, CMake, make)
Also having tests built-in is really nice. Rust is the only language where I bother writing tests. Everything else makes it too hard, as if entry points into your binary are supposed to be rare and expensive.
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.
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.
> Rust and Cargo make it challenging to develop a project in a fully "secure" fashion, C/C++ has a better story there.
Complete absence of dependency management and a myriad of incompatible build tools is a "better story"?
You can have this "story" in Rust by just disabling crates.io centralized registry. Which still leaves you in a better position than C++ because you can use the build tool and dependency management locally and do whatever you're used to doing in C++ land (put 3rd party code in your repo, install them via some other packaging tool etc). Or if you insist on going the whole way, you can invoke rustc via your favorite flavor of make.
On a more realistic note, if you're working with in a very safety/security conscious environment, and still depend on 3rd party code: you could set up your local package registry and have people vet the 3rd party dependencies. Yes, it costs time and money but at least you get the tools to do it from the language ecosystem.
I've been professionally involved with the C/C++ way of doing things for decades and I find the Rust build and dependency management tooling a huge improvement.
The worst is that they keep messing with things outside the language.
It is normal to have a set of tools that you like or wish to retain. There may be a package installer (rpm, apt, msi, etc.), a build system (plain Makefile, autoconf, CMake, the Visual Studio project/solution files, etc.), a linker (link.exe, the old binutils ld, gold linker, etc.) and so on.
Most of us aren't looking to replace any of that. Even if we are, the stuff coming along with Rust is probably not what we are looking for.
Cargo is thus, to many of us, an unwelcome surprise.
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.
Rust is great. However, because of the ease of creating crates (packages), it seems to be beginning to suffer the same fate as Node and node_modules, with authors bringing in crates (just a `crate install` away) and ending up with ludicrous compile times for the end users.
I can tell you that bad programmers can write bad code in Rust.
reply