When using Rust libs you also have some faith that the lib will not have some sort of memory corruption and introduce instability to your app. This is why C/C++ can never have the Rust crate system, no matter how user friendly the package manager.
C and C++ don't have bespoke build and module systems because it wasn't really a thing back when they were conceived, that's it. And bolting that stuff as an afterthought on top of existing, widely popular languages is extremely difficult.
One could, but no one has. That's the whole discussion, there are multiple partial implementations with limited adoption.
These solutions need to be almost ubiquitous to be truly useful.
Then you want to add a library that compiles fine on Fedora, but fails on ArchLinux, because they've moved some header file from `/usr/include` to `/usr/include/subdir`.
Then you want to add another library, but you want to statically link it, only to find out that the package manager installs a version of the library that allows only dynamic linkage.
Then you want to add Windows support, and the whole thing detonates because Visual Studio uses completely different compilation switches than what you'd expect from a compiler in a unix world.
Next there are 1000 other problems, including people who insist on using raw Makefiles because they think they know better.
By the way, the fact that C doesn't use rich signatures is a problem, not a feature. C ABI can also be changed by using different compilation options, but the user won't even know it until the app explodes (crashes). At least C++ will emit a linker error in such case (sometimes, other times it will explode as well).
This is why pkg-config exists.
>Then you want to add another library, but you want to statically link it, only to find out that the package manager installs a version of the library that allows only dynamic linkage.
This sounds like a problem in such "package manager" or problem in the upstream build system.
>Then you want to add Windows support, and the whole thing detonates because Visual Studio uses completely different compilation switches than what you'd expect from a compiler in a unix world
This is a valid point. Visual studio already has its own solution however. I personally avoid visual studio anyways, because it sucks for C.
>Next there are 1000 other problems, including people who insist on using raw Makefiles because they think they know better.
These aren't really problems unless you rely only on the upstream build system. PKGBUILDs, nix recipes they can do their own thing.