> Cargo always picks the newest version of a dependency, even if that version is incompatible with the version of Rust you have installed.
> PKG_CHECK_MODULES([libfoo], [libfoo >= 1.2.3])
This also picks the newest version that might be incompatible with your compiler, if the newer version uses a newer language standard.
> You're like "build this please", and it's like "hey I helpfully upgraded this module! oh and you can't build this at all, your compiler is too old granddad"
Also possible in the case of your example.
> What a bunch of shiny-shiny chasing idiots with a brittle build system.
Autoconf as an example of non-brittle build system? Laughable at best.
This is whataboutism to deflect from Rust's basic ethos being to pull in the latest shiny-shiny.
> This also picks the newest version that might be incompatible with your compiler, if the newer version uses a newer language standard.
It doesn't, it just verifies what the user has already installed (with apt/yum/dnf) is suitable. It certainly doesn't connect to the network and go looking for trouble.
The onus is on library authors to write standard-agnostic, compiler-agnostic headers, and that's what they do:
> This is whataboutism to deflect from Rust's basic ethos being to pull in the latest shiny-shiny.
No. You set a bar for Cargo that the solution you picked does not reach either.
> It doesn't, it just verifies what the user has already installed (with apt/yum/dnf) is suitable.
There's no guarantee that that is compatible with your project though. You might be extra unlucky and have to bring in your own copy of an older version. Plus their dependencies.
Perfect example of the pile of flaming garbage that is C dependency "management". We haven't even mentioned cross-compiling! It multiplies all this C pain a hundredfold.
> The onus is on library authors to write standard-agnostic, compiler-agnostic headers, and that's what they do:
You're assuming that the used feature can be represented in older language standards. If it doesn't, you're forced to at least have that newer compiler on your system.
> [...] standard-agnostic, compiler-agnostic headers [...]
> For linking, shared objects have their [...]
Compiler-agnostic headers that get compiled to compiler-specific calling conventions. If I recall correctly, GCC basically dictates it on Linux. Anyways, I digress.
> shared objects have their own versioning to allow backwards-incompatible versions to exist simultaneously (libfoo.so.1, libfoo.so.2).
Oooh, that one is fun. Now you have to hope that nothing was altered when that old version got built for that new distro. No feature flag changed, no glibc-introduced functional change.
> hey I helpfully upgraded this module! oh and you can't build this at all, your compiler is too old granddad
If we look at your initial example again, Cargo followed your project's build instructions exactly and unfortunately pulled in a package that is for some reason incompatible with your current compiler version. To fix this you have the ability to just specify an older version of the crate and carry on.
Looking at your C example, well, I described what you might have to do and how much manual effort that can be. Being forced to use a newer compiler can be very tedious. Be it due to bugs, stricter standards adherence or just the fact that you have to do it.
In the end, it's not a fair fight comparing dependency management between Rust and C. C loses by all reasonable metrics.
I listed a specific thing -- that Rust's ecosystem grinds people towards newness, even if goes so far to actually break things. It's baked into the design.
I don't care that it's hypothetically possible for that to happen with C, I care that practically, I've never seen it happen.
Whereas, the single piece of software I build that uses Rust, _without changing anything_ (already built before, no source changes, no compiler changes, no system changes) -- cargo install goes off to the fucking internet, finds newer packages, downloads them, and tells me the software it could build last week can't be build any more. What. The. Fuck. Cargo, I didn't ask you to fuck up my shit - but you did it anyway. Make has never done that to me, nor has autoconf.
Show me a C environment that does that, and I'll advise you to throw it out the window and get something better.
There have been about 100 language versions of Rust in the past 10 years. There have been 7 language versions of C in the past 40. They are a world apart, and I far prefer the C world. C programmers see very little reason to adopt "newer" C language editions.
It's like a Python programmer, on a permanent rewrite treadmill because the Python team regularly abandon Python 3.<early version> and introduce Python 3.<new version> with new features that you can't use on earlier Python versions, asking how a Perl programmer copes. The Perl programmer reminds them that the one Perl binary supports and runs every version of Perl from 5.8 onwards, simultaneously, and the idea of making all the developers churn their code over and over again to keep up with latest versions is madness, the most important thing is to make sure old code keeps running without a single change, forever. The two people are simply on different planets.
> I don't care that it's hypothetically possible for that to happen with C, I care that practically, I've never seen it happen.
I don't think your anecdotal experience is enough to redeem the disarray that is C dependency management. It's nice to pretend though.
> and tells me the software it could build last week can't be build any more. What. The. Fuck. Cargo, I didn't ask you to fuck up my shit - but you did it anyway. Make has never done that to me, nor has autoconf.
If you didn't get my point in previous comment, let me put it more frankly - it is your skill issue if you aren't fixing your crates to a specific version but depend on them remaining constant. This is not Cargo's fault.
> Make has never done that to me, nor has autoconf.
Yeah, because they basically guarantee nothing nor allow working around any of the potential issues I've already described.
But you do get to wait for a thousandth time for it to check the size of some types. All those checks are a literal proof how horrible the ecosystem is.
> There have been about 100 language versions of Rust in the past 10 years
There's actually four editions and they're all backwards-compatible.
> C programmers see very little reason to adopt "newer" C language editions.
This doesn't "pick" anything, it only locates and validates the version specified and installed by the user, it does not start to fetch newer versions.
> PKG_CHECK_MODULES([libfoo], [libfoo >= 1.2.3])
This also picks the newest version that might be incompatible with your compiler, if the newer version uses a newer language standard.
> You're like "build this please", and it's like "hey I helpfully upgraded this module! oh and you can't build this at all, your compiler is too old granddad"
Also possible in the case of your example.
> What a bunch of shiny-shiny chasing idiots with a brittle build system.
Autoconf as an example of non-brittle build system? Laughable at best.