3 ms·

As an operations person who cares about deploying repeatable systems at scale, Rust's package management (and the toolchain's "packaging" itself) is an absolute

As an operations person who cares about deploying repeatable systems at scale, Rust's package management (and the toolchain's "packaging" itself) is an absolute nightmare. But at least I with MUSL can I have a 100% statically linked binary, which really should have been easier but that's another argument. Seriously though, Rust team needs to have its Come To Jesus moment about not piping shit off the internet to sh.

conradludgate 5y ago
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 5y 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 5y 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 5y 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
myrrlyn 5y ago
rustup is available in your package manager's repository
- busterarm 5y ago
  No, it isn't. There is a package but it just symlinks to rustc & cargo. You still need to have run the installation manually. And if you're still running something like CentOS 7, everyone just tells you to go download a Snap for it. eff that.

conradludgate 5y ago

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 5y 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 5y 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 5y 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

myrrlyn 5y ago

rustup is available in your package manager's repository

busterarm 5y ago
No, it isn't. There is a package but it just symlinks to rustc & cargo. You still need to have run the installation manually. And if you're still running something like CentOS 7, everyone just tells you to go download a Snap for it. eff that.