Seriously though, Rust team needs to have its Come To Jesus moment about not piping shit off the internet to sh.
My company deploys many Rust (web) applications to production and I've not experienced these issues with cargo
To start off with, please read this: https://lwn.net/Articles/889924/
As you start having to worry about deploying to 10^5 scale machines you want your mindset to be more like the longtime kernel development folks. You want minimal dependencies. You want to build with minimal pulls to the internet. You want repeatable static binaries built from a source tree you can reasonably audit.
At that scale of deployment your "business risk" goes up significantly.
Rust's approach to tooling/packages looks very similar to the Node.js ecosystem. It's a total free for all and dependencies are managed really poorly (in the sense that they grow in number completely out of control).
I do wonder what the solution is though because Go has the same problem as far as I can tell. It has a bigger stdlib so there's less need to reach out. But when you do, you're in the same state with lots of tiny packages that do 1 thing well.
I don't have much experience outside of Go/Rust/Node so I can point to maybe a few languages which I can see being the opposite:
C++ has a large stdlib, and boost. With C++ managing dependencies is your problem so I guess it's easier to have few megapackages.
Python feels the same for mathematical computing. Numpy, TF, Pandas are all huge. Conda is an event bigger bundle, again I think because using the standard pip tools is rather cumbersome and usually not what people want to do
So as far as I can see, it's either easy to share code for others to use, in which case you get dependency hell, or you make it hard to share dependencies, but you have larger more refined ones as a result.
Hard to say what's better
And if you're still running something like CentOS 7, everyone just tells you to go download a Snap for it. eff that.
The fact that you can cross compile a win10 .exe on a raspberry pi with a single command as easy as "GOARCH=amd64 GOOS=win go build ." it's very powerful and I don't know a single language that does it out of the box like go does.
Go tooling is one of the strongest point of Go you have all of that built-in:
- compilation
- testing
- benchamark
- dep managment
zig build -Dtarget=x86_64-windows
I suppose you can define feature flags in your Cargo.toml but that's about it.
Woe unto those who do not follow the idiosyncrasies of how golang handles versioning, package management, tooling etc.
if this is really your most important part of a language I would whole-heartedly recommend looking at rust which has been a breathe of fresh air in terms of package management and tooling.