4 ms·

I'm interested if you could elaborate on that? My company deploys many Rust (web) applications to production and I've not experienced these issues with cargo

busterarm 4y ago
It's either a problem that you have or you don't, but also one that you have to have a specific mindset to even recognize. To start off with, please read this: https://lwn.net/Articles/889924/ 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).
- zozbot234 4y ago
  You can use cargo vendor to import specific versions of your dependencies into your project for easy auditing, or cargo fetch to simply be more explicit about when to download from remote repositories (when combined with the --offline flag). The typical Rust "dependency" is small; it's more like a single .c or .cxx file than a conventional "library", except that it also plays nice with generic code unlike these languages.
- conradludgate 4y ago
  I agree that Rust does suffer a similar problem to NPM where there are many small packages that people will use together. 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

busterarm 4y ago

It's either a problem that you have or you don't, but also one that you have to have a specific mindset to even recognize. To start off with, please read this: https://lwn.net/Articles/889924/ 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).

zozbot234 4y ago
You can use cargo vendor to import specific versions of your dependencies into your project for easy auditing, or cargo fetch to simply be more explicit about when to download from remote repositories (when combined with the --offline flag). The typical Rust "dependency" is small; it's more like a single .c or .cxx file than a conventional "library", except that it also plays nice with generic code unlike these languages.
conradludgate 4y ago
I agree that Rust does suffer a similar problem to NPM where there are many small packages that people will use together. 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