1. 14
  1.  

  2. 5

    I don’t think I like this.

    pyca/cryptography users have been asking for support of Debian Buster (current stable), Alpine 3.12, and other platforms with older Rust compiler versions.

    First, precompiled wheels should work fine (at least on Debian, I guess Alpine is a different story, since it uses MUSL), since there is no Rust dependency for binaries. Secondly, if maintainers and users of some distributions want to use old or even ancient versions of software, power to them. But then you also get to carry the burden of maintaining fixes and compatibility against old versions.

    I think the real issue is not that the Rust ecosystem is progressing, but that some distribution package systems are not really well-adapted to modern language ecosystems. Let’s not put Rust/Go, etc. in the same situation as C++ where we have to wait years to move forward, because some people are running Ubuntu 14.04 or 16.04 LTS.

    1. 5

      Note that Red Hat releases Red Hat Developer Toolset so that stable distribution users can use the latest toolchain. It’s Ubuntu and Debian’s fault, not fault of stable distributions in general.

      1. 5

        Secondly, if maintainers and users of some distributions want to use old or even ancient versions of software, power to them. But then you also get to carry the burden of maintaining fixes and compatibility against old versions.

        I think this needs a specific scale to be meaningful. Rust 1.41 is 1 year, 2 weeks old. This feels pretty new to me. Especially considering that this is a foundational package (so it imposes MSRV on all reverse dependencies), and considering that it targets non-Rust ecosystem.

        1. 4

          It’s not just that “distro packaging systems are slower”. Packaging Rust can be a nightmare. Typically distros will have a wider set of supported platforms than Rust has in tier 1, so package maintainers are receiving the tier2 and tier3 experience of Rust, which is significantly worse.

          Any release of Rust needs to be built with a previous version of Rust, and in a tier2/3 system this means someone has to create a bootstrap binary for a wide set of platforms. It’s not uncommon for this process to run into issues because tier2/3 platforms are also not tested.

          This process has to be repeated every 6 weeks per the release schedule, so you never catch a break from it.

          Our current trouble with rust is that our way of building Rust bootstraps is building them for an older system (so it runs on all the newer ones), and shipping the bootstrap binary with the libraries it needs. Then, Rust is built properly against the actual libraries for the system. This is starting to fall apart because Rust is really hard to build on these tier2/3 platforms, including “simply running out of address space on 32-bit platforms”. Someone will have to re-do the whole thing from scratch and ship a binary-only compiler, and somehow find an answer that doesn’t require us to rebuild a bootstrap binary every time the packages it depends on get updated.

          Python adopting Rust in fundamental packages means that as long as these fires haven’t been put out, a huge chunk of packages will no longer work.

          Realistically, we are probably going to package the pre-Rust versions and whenever Rust doesn’t work, switch to the old one. But this possibility has a limited shelf life.

        2. 2

          Rust people like to say Rust releases every six weeks, comparing to C++ how hard it is to use even C++17, but going forward, the days when you could use new Rust features within a year will be gone and won’t return. It is sad but a natural process.

          1. 2

            I’m still targeting the latest stable only, and get away with it. At Cloudflare we update Rust the day it’s released, and it’s in production within a week.

            1. 3

              I used C++17 at work in 2018, but no, that’s not representative. I think it will be the same for Rust.

              1. 1

                At Cloudflare we update Rust the day it’s released, and it’s in production within a week.

                How many engineers work with Rust there? (compared to a small startup).

                1. 2

                  At least 3 startups worth of engineers ;) It’s now powering many critical components and user-facing services.

                  Since Cloudbleed things are moving to Rust where possible. Rust is regularly picked for new projects (Golang and some other memory-safe languages are used too).

                  So far compiler upgrades haven’t caused any major problems. The biggest issue was regression in compilation speed in 1.46.

              2. 2

                I think this will be more of a concern for packagers than developers.

                I don’t believe a lot of people that actually develop in any of the newer language like Rust or Go, or even older languages like Node.js, Python or Ruby, care about how their application is packaged. You either use the language ecosystem, provide binaries, or provide another standalone installation method.

                Packaging only becomes a concern once a packager shows interest, and then it’s too late for large changes to the build & release process.

                1. 4

                  It may be true that developers don’t care, but users definitely do. So developers should care, once they acquired enough users.

              3. 2

                This is just obviously good policy. Depending on language or library features so bleeding edge that they aren’t in Debian stable yet is not a good look for production code.

                1. 8

                  For Rust it’s quite the opposite actually. It often runs into buggy corners of LLVM, and needs to patch it. OTOH Linux distros that unbundle it and make Rust use a prehistoric version of LLVM ship with known-broken Rust.

                  The “bleeding edge” Rust is well tested. The team performs “crater” runs that compile and test for regressions nearly all public Rust code, so the latest release and the ecosystem stay in sync. Distros fall behind.

                  Rust takes cue from the Web, where the Chromium model of small regular incremental updates turned out to work better than the traditional IE/Netscape model of irregular big changes and leaving bugs in the wild for a long time.

                  1. 1

                    Rust takes cue from the Web, where the Chromium model of small regular incremental updates turned out to work better than the traditional IE/Netscape model of irregular big changes and leaving bugs in the wild for a long time.

                    I wonder if it’s time we made that shift in our base server operating systems too. Using a rolling-release distro like Arch Linux on production servers seems crazy. And I think it is, for traditional systems that are upgraded in-place. But what about for container images, or immutable container host operating systems?

                    1. 1

                      I think you’re glancing over the fact here that it can by definition only test the public crates, so if your org has a sizable codebase that works on Rust 1.X they probably have tested it on 1.X and not 1.X+Y.

                      I’m not saying you’re wrong, but you can’t satisfy some people/orgs who are very averse to updating anything.

                      1. 1

                        The public collection is quite large, so the chance of private code doing something completely unseen before is small. Obviously you need to test your private code anyway.

                        I think it all comes down to the cost of testing. If an org relies on manual testing, then infrequent big releases are the only way to make that cost effective. But if you have good coverage of unit and integration tests, canaries, monitoring, phased rollouts and reliable rollbacks, then you can take advantage of that and release smaller changes more often.

                    2. 7

                      New features in Rust are rarely bleeding edge. Features that are stabilized in Rust have often lived in nightly for quite a long time already. Pretty much every Rust developer develops on and deploy with the latest stable Rust version.

                      Do you have examples of language or library features in Rust from over the last 1-2 years that turned out to be problematic for production?