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'm not entirely thrilled with the cargo solutions here, but when I compare them to the options in other languages I think they're adequate.
If you're making a small change, you use a [patch] section in the Cargo.toml for your workspace if you're using one, or the Cargo.toml for your binary/.so/.a if you're not, and it will cause your entire dependency tree to use your forked library. You don't need to fork the entire ecosystem as you suggest.
The [patch] works at the "workspace" level (and you generally should stick your entire complex system under one workspace), so if you use that feature properly for your "complex system" (keeping everything under one workspace), it is a one line change to replace the dependency for your entire system. If you use multiple, well, one per workspace that produces a binary/.so/.a.
Also, for big enterprise projects, I would assume you would use a private registry in the first place, which is apparently well supported (though I haven't used it). That's how the enterprise places I work at have dealt with python dependencies for instance (I haven't used rust in a enterprise).
I can sort of understand people trying to maintain LTS linux distros complaining that for their purposes this is a bit of a pain compared to C style shared libraries (because they need to modify a lot of rust workspaces)... but to be honest I think that's a question of their package management tooling not rust's. Rust provided the tools they need to make their custom tooling work. As a user the number of times shared libraries have caused me pain makes me think that this static linking is the superior method of packaging.
When I started programming, static linking was the only way of packaging software in mainstream computing, if it was so superior we wouldn't have moved away from it.
Also although we are talking about open source here, in many OSes, and enterprises, distribution of binary libraries is a very important subject, which cargo doesn't allow for.
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.