5 ms·

Distribution maintainers have already figured out how to package Rust in a modular fashion and build without touching the network. Cargo specifically provides f

Distribution maintainers have already figured out how to package Rust in a modular fashion and build without touching the network. Cargo specifically provides facilities to help distribution maintainers provide dependencies themselves. Based on those facilities, I built the initial prototype of Rust packaging for Debian ("debcargo"), and the current Debian Rust maintainers have made further huge advances in packaging. So no, Cargo doesn't "sidestep" distribution packaging, it works with distribution packaging. Also, neither the standard library nor the compiler have "churn"; we're very careful to make sure old code still compiles with current Rust.

daurnimator 7y ago
On arch we haven't yet. We use Cargo.lock files to get reproducible builds, but trying to get rust to follow normal practices has been difficult.
cycloptic 7y ago
Yes, debcargo is a great solution. Thank you for writing that. And really, I mean it, it's awesome. But my point (which you seem to be agreeing with) is that we have a while to wait while the distro people do their thing. Not just Debian. We can't just take random packages off github and put them in any distro, there is more to it than just running debcargo. >Also, neither the standard library nor the compiler have "churn"; we're very careful to make sure old code still compiles with current Rust. When did this happen? Last I checked Rust still had no LTS policy and there were no stability guarantees around the syntax, ABI, API, compiler flags, Cargo file format, etc. If some policy has changed here, please link me to any info.
- JoshTriplett 7y ago
  > Yes, debcargo is a great solution. Thank you for writing that. And really, I mean it, it's awesome. Just to reiterate: I wrote the initial prototype, and massive credit goes to the current maintainers who picked it up and ran with it into production. > there were no stability guarantees around the syntax, ABI, API, compiler flags, Cargo file format, etc. There are absolutely stability guarantees around syntax, around compiler flags, around API, and around the Cargo file format. Code from old Rust and old Cargo will build and run with new Rust and new Cargo. We take a great deal of care to preserve that stability guarantee. The policies here have remained essentially the same since 1.0 (https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html), though we've since taken further care to specify them more precisely and to stabilize further areas. (Source: I'm one of the leads of the Rust language team, and I'm on the Rust cargo team. Other Rust teams, such as the Rust library team, follow the same principles.)
  - cycloptic 7y ago
    That post doesn't have any concrete promises about what stability actually means. Furthermore I don't see that in practice. To be able to say you're stable you have to have a spec and stick to it over a number of years. Is there one? Unit tests in rustc don't count because contributors just regularly delete or change those. I still see statements coming out from other contributors describing regular regressions and breakages to the core language happening even in the last few months: https://www.pietroalbini.org/blog/shipping-a-compiler-every-six-weeks/ https://www.pietroalbini.org/blog/shipping-a-compiler-every-... https://blog.ryanlevick.com/rust-2020/ https://blog.ryanlevick.com/rust-2020/ Disclosure, I don't work on Rust or any other language, I just keep an eye on it out of interest. I give it another few years before these big regressions stop happening. Please keep at it and don't take any of my statements as being discouraging.
    - jcranmer 7y ago
      Compilers are big, complex programs, which means they of course have bugs in them. If you think rustc is unstable because of a half-dozen regressions in the last release cycle, then gcc must seem to you to be a dangerously rickety piece of software: https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&chfield=%5BBug%20creation%5D&chfieldfrom=6w&chfieldto=Now&order=Importance&query_format=advanced&short_desc=regression&short_desc_type=allwordssubstr https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_ty... That query lists all regressions filed in the last 6 weeks, and there are nearly 150 of them.
      - cycloptic 7y ago
        I don't see how that's relevant. Most of those bugs are in GCC 10 which isn't released yet specifically because those regressions are all still open. Meanwhile, GCC 7 just got a bugfix release a few months ago. It just doesn't make sense to compare C/C++ compilers to rustc; my point is that rustc doesn't have a stable LTS release yet. The only way I could see this happening is if developers of other Rust compilers put pressure on your team to make a spec and stick to it for a number of years. Otherwise you're headed for a situation like Haskell where there is only one real compiler and it's permanently in a state of flux. Distro packaging for Haskell and its libraries is still a pretty complex task BTW.

daurnimator 7y ago

On arch we haven't yet. We use Cargo.lock files to get reproducible builds, but trying to get rust to follow normal practices has been difficult.

cycloptic 7y ago

Yes, debcargo is a great solution. Thank you for writing that. And really, I mean it, it's awesome. But my point (which you seem to be agreeing with) is that we have a while to wait while the distro people do their thing. Not just Debian. We can't just take random packages off github and put them in any distro, there is more to it than just running debcargo. >Also, neither the standard library nor the compiler have "churn"; we're very careful to make sure old code still compiles with current Rust. When did this happen? Last I checked Rust still had no LTS policy and there were no stability guarantees around the syntax, ABI, API, compiler flags, Cargo file format, etc. If some policy has changed here, please link me to any info.

JoshTriplett 7y ago
> Yes, debcargo is a great solution. Thank you for writing that. And really, I mean it, it's awesome. Just to reiterate: I wrote the initial prototype, and massive credit goes to the current maintainers who picked it up and ran with it into production. > there were no stability guarantees around the syntax, ABI, API, compiler flags, Cargo file format, etc. There are absolutely stability guarantees around syntax, around compiler flags, around API, and around the Cargo file format. Code from old Rust and old Cargo will build and run with new Rust and new Cargo. We take a great deal of care to preserve that stability guarantee. The policies here have remained essentially the same since 1.0 (https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html), though we've since taken further care to specify them more precisely and to stabilize further areas. (Source: I'm one of the leads of the Rust language team, and I'm on the Rust cargo team. Other Rust teams, such as the Rust library team, follow the same principles.)
- cycloptic 7y ago
  That post doesn't have any concrete promises about what stability actually means. Furthermore I don't see that in practice. To be able to say you're stable you have to have a spec and stick to it over a number of years. Is there one? Unit tests in rustc don't count because contributors just regularly delete or change those. I still see statements coming out from other contributors describing regular regressions and breakages to the core language happening even in the last few months: https://www.pietroalbini.org/blog/shipping-a-compiler-every-six-weeks/ https://www.pietroalbini.org/blog/shipping-a-compiler-every-... https://blog.ryanlevick.com/rust-2020/ https://blog.ryanlevick.com/rust-2020/ Disclosure, I don't work on Rust or any other language, I just keep an eye on it out of interest. I give it another few years before these big regressions stop happening. Please keep at it and don't take any of my statements as being discouraging.
  - jcranmer 7y ago
    Compilers are big, complex programs, which means they of course have bugs in them. If you think rustc is unstable because of a half-dozen regressions in the last release cycle, then gcc must seem to you to be a dangerously rickety piece of software: https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&chfield=%5BBug%20creation%5D&chfieldfrom=6w&chfieldto=Now&order=Importance&query_format=advanced&short_desc=regression&short_desc_type=allwordssubstr https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_ty... That query lists all regressions filed in the last 6 weeks, and there are nearly 150 of them.
    - cycloptic 7y ago
      I don't see how that's relevant. Most of those bugs are in GCC 10 which isn't released yet specifically because those regressions are all still open. Meanwhile, GCC 7 just got a bugfix release a few months ago. It just doesn't make sense to compare C/C++ compilers to rustc; my point is that rustc doesn't have a stable LTS release yet. The only way I could see this happening is if developers of other Rust compilers put pressure on your team to make a spec and stick to it for a number of years. Otherwise you're headed for a situation like Haskell where there is only one real compiler and it's permanently in a state of flux. Distro packaging for Haskell and its libraries is still a pretty complex task BTW.