> Having run up against limits of the Python standard library several times in years of writing production software in it and not just learning it, I find the batteries-not-includes-but-easy-to-install approach better on the whole.
Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you have to get permission for every third party library you bring on to the network. Many networks were essentially "airgapped", so it's not like you could just ignore the rules. The bureaucratic process alone meant that we preferred large bundles like Anaconda or Qt. Trying to use Cargo as it is typically used and documented would be a complete non-starter.
>Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you have to get permission for every third party library you bring on to the network.
Situations like this will really make you appreciate "batteries included". I think this particular issue is fairly revealing of the attitudes common among programmers of different languages. I think it's a good thing to be skeptical of a program pulling in a bunch of standard libraries over the Internet. It worries me when I find something on Github I want to try and I can't download and compile it without it pulling in 30 or 100 other libraries that I haven't looked at or decided to trust come along for the ride. I don't like that way of doing software, and unfortunately it's the norm in node and starting to become a norm in Rust as well. Real security fails have been caused this way in node's case at least.
Even in cases when Python programs depend on external libraries, I usually don't need to use pip for anything because Python programs will pull in dependencies provided by your distribution just fine. (My distribution doesn't even have any Rust libraries, so even if dynamic linking is possible in Rust not many people are shipping software that way.)
"Download by default" is a worse way of doing things, and it makes me sad to see newer languages like Go and Rust embracing it.
Standard libraries serve several functions. One of them is to bless certain versions of certain libraries as "known good". This can be done outside the standard library too, without incurring the penalties of actually moving things into the standard library. Rust definitely needs more work in this area though.
Yes, my own employer is similar (you don't need permission, but production systems have no internet access and so you need to pre-download all your tarballs etc.), and cargo doesn't work right. But I think there is work on pointing cargo at an internal mirror.
We do have an internal PyPI mirror (with devpi) and we point `pip` at that, and it works pretty well.
You can use `conda install rust_osx-64` on macOS and `conda install rust_linux-64` to use `cargo` with the Anaconda Distribution libraries and tools (including its compilers).
Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you have to get permission for every third party library you bring on to the network. Many networks were essentially "airgapped", so it's not like you could just ignore the rules. The bureaucratic process alone meant that we preferred large bundles like Anaconda or Qt. Trying to use Cargo as it is typically used and documented would be a complete non-starter.