1. 48
  1.  

  2. 18

    For folks wanting more context on how the “minimum supported Rust version” (MSRV) issue is treated in the ecosystem, this issue has a number of opinions (including my own) and some discussion: https://github.com/rust-lang/api-guidelines/issues/123

    As far as I can tell, there is no strong consensus on what to do. In practice, I’ve observed generally the following states:

    1. Some folks adopt an explicit MSRV policy but do not consider it a breaking change to increase it.
    2. Some folks adopt an explicit MSRV policy and consider it a breaking change to increase it.
    3. There is no MSRV policy, and the only guarantee you have is that it compiles on latest stable (or latest stable minus two releases).

    In general, I’ve found that (1) and (2) are usually associated with more widely used crates and generally indicates an overall more conservative approach to increasing the MSRV. (3) is generally the default though, as far as I can tell.

    There’s good reason for this. Maintaining support for older versions of Rust is a lot of thankless work, particularly if your library is still evolving or if your own crate has other dependencies with different MSRV policies. All it takes is one crate in your dependency graph to require a newer version of Rust. (Unless you’re willing to pin a dependency in a library, which is generally bad juju.) Rust’s release cycle reinforces this. It moves quickly and provides new things for folks to use all the time. Those new things are added specifically because folks have a use for them, so their use can propagate quickly in the ecosystem if a widely used crate starts using it. The general thinking here is that updating your Rust compiler should be easy. And generally speaking, it is.

    “Maturity” is perhaps the right word, but only in the sense that, over time, widely used crates will slow their pace of evolution and, consequently, slow their MSRV increases. This isn’t necessarily equivalent to saying that “maturity” equals “slow evolution,” because it is generally possible for crates to make use of newer versions of Rust without increasing their MSRV via version sniffing and conditional compilation. (Not possible in every case, but the vast majority.) But doing this can lead to significant complexity and a greatly increased test matrix. It’s a lot of extra work, and maybe doing that extra work is what this author means by “maturity.” Chances are though, that’s a lot of unpaid extra work, and it’s not clear to me that that is reasonable expectation to have.

    1. 4

      Perhaps part of the solution could be to make LTS versions of rustc and cargo? That way distro maintainers could preferentially use those, and package maintainers preferentially target those. Make the common toolchain setup procedure apt install cargo instead of curl https://sh.rustup.rs > sh and there’s at least a prayer of people preferring that. Debian 10 currently ships with rustc 1.34 for example, which IMO is a pretty good place to put a breakpoint.

      But for this to happen there needs to be agreement on what the LTS versions are. If Debian 10 ships rustc 1.34, Ubuntu 20.04 ships 1.37 and Fedora ships 1.12, then as a crate maintainer I’m not going to bother trying to target a useful minimal version, because it’s a lot of random work that will never be perfect. If everyone ships rustc 1.34, then it’s much easier to say to myself “well I’d like this shiny new feature in rustc 1.40 but I don’t really need it for now, it can just go in the next time I’m making a breaking release anyway”. This actually works in my favor, ‘cause then when a user tries to install my software on some ancient random system I can just say “sorry, you have to use rustc 1.34+ like everyone else, it’s not like that’s a big ask”. Then distro maintainers can backport rustc 1.34 to Debian 9 or 8 if they really need to, and only need to do it once as well for most people’s software to work.

      This happens already, hence why Debian 10 has gcc-7 and gcc-8 packages. It’s fine. The special cases just need to be uncommon enough that it’s not a huge hassle.

      1. 5

        Yes, people generally want some kind of LTS story. There was an RFC that was generally positively received about 1.5 years ago: https://github.com/rust-lang/rfcs/pull/2483

        It was closed due to lack of bandwidth to implement it, but it seems like something that will be revisited in the future. There’s just a ton of other stuff going on right now that is soaking up team bandwidth, mostly in the form of implementing already merged RFCs.

        1. 4

          It would be really sad to let Debian hold back Rust version adoption in the ecosystem the way Debian gets to hold back C++ version adoption via frozen GCC.

          It seems to me it would be a major strategic blunder for Rust to do an LTS instead of the current situation.

          1. 2

            Is Debian a factor anymore? I mean it was always pretty backwards, but does anybody use it, care for it anymore? How independent is Ubuntu from them?

            I only use fedora/centos/rhel or windows for work. I have only seen Ubuntu in use by others in large real-world deployments, but Debian? Never.

            1. 3

              Is Debian a factor anymore? I mean it was always pretty backwards, but does anybody use it, care for it anymore? How independent is Ubuntu from them?

              People do care about Debian and use Debian. That’s fine. What’s not fine is acting entitled to having code from outside the Debian stable archive build with the compilers shipped by Debian stable.

              As Ubuntu LTS releases get older, they have similar ecosystem problems as Debian stable generally, but in the case of Rust in particular, Ubuntu updates Rust on the non-ESR Firefox cycle, so Rust is exempt from being frozen in Ubuntu. (Squandering this exemption by doing a Rust LTS would be a huge blunder for Rust in my opinion.)

              In my anecdotal experience entitlement to have out-of-archive code build with in-archive compilers is less of a problem with RHEL. People seem to have a better understanding that if you use RHEL, you are paying Red Hat to deal with being frozen in time instead of being frozen in time being a community endeavor beyond the distro itself. Edited to add: Furthermore, in the case of Rust specifically, Red Hat provides a rolling toolchain for RHEL. It doesn’t roll every six weeks. IIRC, it updates about every third Rust upstream release.

              1. 3

                The company I work at (ISP & ISTP) use Debian as the operating system on almost all virtual machines running core software which requires n nines uptime.

                1. 3

                  I’ve found Debian Stable to be perfectly fine for desktop and server use. It just works, and upgrades are generally pretty smooth. Clearly, you have different experiences, but that doesn’t make Debian “backwards”.

                  1. 1

                    One department at my university is mostly-Debian for about 15+ years.

                    1. 0

                      I have seen Debian at a university department too, but not at places where actual money is made, or work is getting done. I had to use pkgsrc there to get fresh packages as a user to be able to get my stuff done.

                      University departments can afford to be backwards, because they are wasting other people’s time and money with that.

                      1. 3

                        Every place that I have worked primarily uses Debian or a Debian derivative. (Google used Ubuntu on workstations; at [Shiny consumer products, inc] the server that I was deploying on was Debian, despite the fact that they have their own server OS and they even supported it at the time; and the rest have been smaller firms or I’m under NDA and can’t discuss them). Except for Google, it was always Debian stable. So no, not just universities.

                        1. 1

                          BSD Unix was developed at a university.

                          Linus attended a university when starting to develop the Linux kernel.

                          The entire ethos and worldview of Free Software is inspired by RMS’ time at university.

                          The programming darling du jour, Haskell, is an offshoot of an academic project.

                          I’m really sad so much time and energy and other people’s money have been wasted on these useless things…

                          1. 2

                            Nice strawman!

                            And the infrastructure supporting these was just as backwards for its time as running Debian wasting the the time of students and tutors with outdated tools provided by the host institution…

                            1. 1

                              In the comment I replied to first , you write:

                              […] a university department too, but not at places where actual money is made, or work is getting done

                              University departments can afford to be backwards, because they are wasting other people’s time and money with that.

                              (my emphasis)

                              I find it hard to read these quotes in any other way than you believe that universities are a waste of time and money…

                              edit clarified source of quotes

                              1. 4

                                I can also mis-quote:

                                I find it hard to read […]

                                But I actually rather read and parse your sentences in their completeness.

                                My claims were:

                                a) I have only seen Debian used at places where efficiency is not a requirement
                                b) Universities are such places

                                I didn’t claim they don’t produce any useful things:

                                […] University departments can afford to be backwards, because they are wasting other people’s time and money with that.

                                Which should be parsed as: University Departments are wasting other people’s time and money with not using proper tools and infrastructure, for example using outdated (free) software. They are being inefficient. They waste student and tutor time, thus taxpayer money when not using better available free tools, but it doesn’t matter to them, as It does not show up n their balance sheet, Tutors and Students are already expected to do lot of “off-work hours” tasks to get their rewards: grades or money.

                                And yes, they are being inefficient:

                                • I had to find floppy disks in 2009 to be able to get my mandatory measurement data from a dos 5.0 machine at a lab. It was hard to buy them, and to get a place where I can read them… This one can be justified as expensive specialized measurement equipment was used and only legacy tools supported it.
                                • I had to do my assignments with software available only at the lab, running some Debian (then current) version shipping only outdated packages. OpenOffice kept crashing, and outdated tools were a constant annoyance. As a student my time was wasted. (Until I installed pkgsrc, and rolled my up to date tools)
                                • At a different university I have seen students working in Dosbox writing 16 bit protected mode in assembly in edit.com, compiling with some ancient MS assembler, in 2015, because the department thought the basics of assembly programming didn’t change since they introduced the curriculum, so they won’t update the tools and curriculum. They waste everyone’s money, the student’s won’t use it in real life anyway, because they are not properly supervised, as they would be if they were living from the market.
                                1. 3

                                  Thanks for clarifying.

                                  I realize it might be hard to realize for you now, but I can assure you that “the real world, governed by the market”, can be just as wasteful and inefficient as a university.

                                  1. 2

                                    Unfortunately that is also true, I have seen “bullshit jobs” (a nice book btw.) business from inside (been partly a box- ticker for a time), but the enormous waste I saw at universities make me feel that the useful stuff coming out from them is exception, the result of herculean efforts of a few working against all odds, complete institutions working on strangling people/projects leading to meaningful results.

                                    Wasting someone’s own money is a thing, I don’t care that much about that, wasting taxpayer money is not a good move, but to some extent I can tolerate it… Wasting talents and other people’s time is what really infuriates me.

                          2. 1

                            I had to use pkgsrc there to get fresh packages

                            Did you have root privileges as a student?

                            1. 2

                              pkgsrc supports unprivilieged mode!

                              https://www.netbsd.org/docs/pkgsrc/platforms.html#bootstrapping-pkgsrc

                              It worked like a charm.

                              But I did actually have root privileges, as the guy responsible for the lab was overburdened and sometimes some of us he trusted helped other students. Still I didn’t use that to alter the installed system, as that would be out of my mandate.

                    2. 1

                      Debian 10 currently ships with rustc 1.34 for example, which IMO is a pretty good place to put a breakpoint.

                      1.34 doesn’t have futures nor async/await that seriously impact the code design. Do I really have to wait for Debian 11 in 2021 to use them?

                      1. 2

                        No, if you need them then install a newer rustc and use them. But there’s plenty of code that also doesn’t need futures or async/await.

                    3. 3

                      Wow, I wasn’t aware that this issue has an acronym and even a place for discussion. Thanks for the pointer!

                      widely used crates will slow their pace of evolution and, consequently, slow their MSRV increases.

                      Exactly what I’m hoping for, and precisely the reason I’m not jumping off the ship :)

                      maybe doing that extra work is what this author means by “maturity.”

                      In part, yes, that’s what I meant. The other possibility is to hold off adopting new APIs (as you did with alloc in regex; thanks!). I understand both options are a PITA for library maintainers, and might not even make sense, economy-wise, for unpaid maintainers. Perhaps I should’ve used “self-restraint” instead of “maturity”, but that probably has some unwanted connotations as well.

                      1. 2

                        Here’s a cargo subcommand (cargo msrv-table) I hacked together (warning, just a hacky PoC) that displays the MSRV by crate version for any particular crate.

                    4. 10

                      The mastodon discussion that was linked to in the bottom, about the evergreen rust compiler and how that challenges “traditional systems” was really interesting.

                      1. 2

                        Kornel definitely thought about this and related issues for a while, e.g. see his #Rust2020 post: https://users.rust-lang.org/t/rust-2020-growth/34956

                      2. 5

                        I believe the issue here stems from something two-fold; there is no standard practice about “minimum supported Rust version” (MSRV), and projects typically don’t provide a table of MSRV to x.y version (in semver sense). As @burntsushi stated, there has been quite a bit of discussion around MSRV practices, and lists the three general (but not standard, as there is none) practices crates adopt.

                        My personal opinion (and that of my projects) is that a MSRV change should trigger at a minimum a minor version bump. Thus allowing downstream crates to use ^x.y version locks in their Cargo.toml (only increase patch version automatically).

                        Adding an easy table of “Project ver a.b has MSRV of 1.16, while c.d has an MSRV of 1.24, etc.” would make it easier for downstream crates to not only pick a version lock, but upgrade knowingly. Right now it’s a lot of trial and error.

                        This doesn’t fix everything, as typically there very little in the way of back-porting features/support to older project versions that coincide with older Rust versions. However, for an unpaid project maintainer to provide the above two items would be a large step in the right direction.

                        1. 4

                          Right, yeah. For 1.x crates (or beyond), I generally adhere to the “only bump MSRV in a minor version” rule. I think you were the one who started that. :-)

                          1. 2

                            Ah yes, I should have stated I meant >= 1.x, as I also view 0.x as the wild west where (almost) anything goes :-)

                          2. 2

                            Did you mean to say ~x.y? Caret(^) is a default. I would probably advise using ~ deps for libraries, because they can lead to genuinely unsatisfiable dependency graphs. ^-requirements are always satisfiable (with the exception of links flag, which is an orthogonal thing).

                            1. 1

                              I did, thanks for catching that!

                          3. 5

                            It’s disappointing that freezing the compiler is seen as maturity as opposed to being able to upgrade the compiler without breakage being seen as maturity.

                            That said, a big part of why this topic is painful is Rust’s former resistance to making MSRV part of the Cargo dependency resolution, which means that increasing MSRV breaks the build for folks who, for whatever reason, run cargo update on an old toolchain. Making an MSRV bump a semver bump is bad as seen with the recent base64 semver bump that didn’t involve API breakage. Either all crates that transitively depend on base64 also undergo a semver bump (disruptive when the dependency doesn’t involve types exposed in the outward APIs of the dependent crates) or they don’t, which would make base64’s semver bump pointless.

                            Fortunately, the Cargo MSRV RFC got accepted, so better times are ahead if only the RFC got implemented.

                            1. 2

                              If cargo and rustup had been rolled into one tool much of this could have been avoided.

                              Dependency uses nightly? You get nightly.

                              New dependency increased the MSRV? You get the new one when you update.

                              1. 1

                                It’s disappointing that freezing the compiler is seen as maturity as opposed to being able to upgrade the compiler without breakage being seen as maturity.

                                I’d say that upgrading without breakage is just a stepping stone to maturity. Also, as I pointed out in the discussion on the Mastodon, the issue is less about the compiler and more about the crates ecosystem.

                                1. 1

                                  Hm, I don’t think there were any resistance to MSRV in Cargo.toml post 1.0? IIRC, it’s rather that no one was willing to do design/implementation work.

                                2. 7

                                  Releasing new versions of Rust every 6 weeks is absolutely great for developers. But I don’t think it’s good for users that this has filtered into an expectation that everything everywhere should update to the latest Rust version and recompile everything every six weeks.

                                  1. 4

                                    My biggest annoyance as a maintainer of several Rust crates and Rust-based applications when it comes to dependencies: various high-profile projects bump up the Rust version requirements aggressively in patch releases and/or minor releases for x >= 1 (in the semver sense). I complained about this several times, but the line of arguing always boils down to ‘increasing the Rust required Rust version is not an API change’. I agree that this may be to the letter of the semver law, but it makes it very hard to maintain backward compatibility for older Rust compilers.

                                    Note that I am not arguing for stagnating Rust compilers in Linux distributions. But supporting, releases of say 6-12 months old wouldn’t be bad. E.g. looking at repology, there are still quite some distributions using 1.37.0 or so.

                                    1. 11

                                      but it makes it very hard to maintain backward compatibility for older Rust compilers.

                                      But bumping major version just to increase MSRV creates a lot of ecosystem-wide work, because then all reverse dependencies have to change their Cargo tomls and publish newer versions as well (which themselves new to be major if the dep is public). That is, the argument is not based on adhering to semver letter, but on minimization of total maintenance work.

                                      To test MSRV with relatively little effort, you need to commit Cargo.lock.min with minimal versions of deps you support, and use that on CI when testing with an old compiler for MSRV.

                                      1. 5

                                        Note that I am not arguing for stagnating Rust compilers in Linux distributions. But supporting, releases of say 6-12 months old wouldn’t be bad. E.g. looking at repology, there are still quite some distributions using 1.37.0 or so.

                                        That’s kind of what I try to do for very widely used crates. But it’s still an admission that “increasing the required Rust version is not a semver breaking change.” You just wind up delaying that increase more than perhaps most other folks.

                                        but it makes it very hard to maintain backward compatibility for older Rust compilers

                                        Respectfully, you’re kind of only looking at this from one angle. Maintaining backward compatibility for older Rust compilers is in and of itself a difficult end on its own, especially if you’re seeking to use newly stabilized features. This is kind of what it ends up looking like: https://github.com/serde-rs/serde/blob/27c283ab531271078b338aa4229e695e3da58ea3/serde/build.rs — Which isn’t too bad, until you realize that each of those knobs is used to influence functionality in the crate.

                                        This can become quite tedious over time and is a big maintenance burden. Some crates (like serde) go the extra mile to do this. I do it myself sometimes, but only within reason.

                                        I’m not against doing some extra work if there’s a commensurate benefit. But so far, I haven’t really found the stated benefits to be particularly compelling. Slower moving Linux distros are a common point (as you brought up), but combining a slow moving ecosystem with a fast moving ecosystem is anathema. If you’re going to opt into a slow moving Linux distro, then it seems quite reasonable to me that you ought to be limited to older versions of Rust libraries and applications that work on your compiler. Any critical security patches should generally become the responsibility of the distro to merge in their own packages while maintaining compatibility with the distro’s version of Rust. This can be quite hard to do in some cases, but it’s either that or shift the burden back to upstream or otherwise live with unpatched software.

                                        Yes, sometimes folks are too eager to use new and shiny things that come with Rust. Folks could exercise better judgment here. Not really sure how to fix that other than slowing down Rust’s release schedule, but that seems unlikely to happen. But many times, new features bring meaningful new functionality. For example, I’ve been waiting for quite some time before bumping the MSRV on regex so that I can use the alloc crate to provide an alloc-only version of regex. If I wasn’t so conservative, I could have done this months ago. I could have added it and only enabled it for newer compilers, but then I have to thread version sniffing through all my dependencies and write some fairly horrific conditional importing logic. It would be a mess to maintain. So I wait, because I recognize that folks do value support for older compilers.

                                        There was talk of LTS Rust releases a while back, but it seems to have fizzled out. In practice, many crates do maintain compatibility for older Rust compilers, but there is no unifying rallying point that folks can point to as a compelling Rust version to target.

                                        1. 3

                                          Respectfully, you’re kind of only looking at this from one angle. Maintaining backward compatibility for older Rust compilers is in and of itself a difficult end on its own, especially if you’re seeking to use newly stabilized features.

                                          I look at from the other angle as well, e.g. we have held back some Rust crates where new library features are appropriate. But I think it is good to give the ecosystem some slack (~6 months). Obviously, that’s not possible everywhere, since some features make things possible that were hard before (e.g. async/await). But there are a lot of places where policies do not allow upgrading to the latest stable overnight and/or is not possible (e.g. in some Linux distributions this entails a rebuild of a large number of packages).

                                        2. 2

                                          I have this experience just now.

                                          I have to move away from a crate because it started to use some new language construct and now it doesn’t compile on Rust 1.16 anymore.

                                          Oh, and it’s using that feature only in a test. Great.

                                          1. 2

                                            Can you stick with the working version you were using or is there a pressing need to update to the new release for security or something?

                                            1. 2

                                              True – I could try and pin the version to an older one. I just don’t know what happens if some dependency requests a newer version. Might be worth a try. Thanks!

                                              1. 3

                                                if some dependency requests a newer version

                                                That dependency will be removed from consideration, i.e. it’ll be downgraded to the version compatible with your pinned version. That’s exactly what I do with libz-sys to ensure compatibility with Rust 1.25+.

                                                1. 1

                                                  Ah, thanks! I will try this!

                                                  1. 1

                                                    Note that Cargo doesn’t always share dependencies between different crates, so that trick might not work. More details in this Reddit post.

                                                    (Comment prompted by a FOSDEM 2020 talk about a nifty tool called cargo-deny, which, among other things, audits for non-shared dependencies.)

                                                    1. 1

                                                      Interesting, thanks! Specifying an exact version seems to have fixed it for me, at least for now,

                                        3. 3

                                          If you are going to rewrite something completely in a new (and relatively immature compared to C++) language, it seems reasonable to not support old platforms. Why not make a clean break and ask existing users to migrate to the new version over the next few years?

                                          1. 2

                                            If you are going to rewrite something completely in a new language, it seems reasonable to not support old platforms.

                                            I agree. That’s why I waited for Rust to get packaged widely, and for a few key libraries to stop requiring just the latest compiler. After that, it seemed reasonable that I’ll be able to keep (most) of the support as long as I don’t require the latest features. If platforms that I want to support have a useable compiler, I’m ready to go, right? (“Useable” for my purposes, of course.)

                                            This broke down because: 1) I under-estimated how many dependencies Newsboat will accumulate; 2) I over-estimated how eager libraries will be in providing support for older compilers.

                                            Why not make a clean break and ask existing users to migrate to the new version over the next few years?

                                            This is dangerously close to the “why rewrite?” territory, so I’ll just say that gradual rewrite avoids the risk of ending up with a bit-rotten old version and half-written new version.

                                          2. 3

                                            This is a conflict of values:

                                            • Value stability: do not make breaking changes until as late as possible
                                            • Value novelty: move to the newest version of Rust as soon as possible. Not meant as judgemental sense of ‘Bright! Shiny! Must have it, damn the consequences’, more like ‘I want to contribute to Rust’s progress by adopting the latest versions’

                                            The problem is that if your dependency chart includes anyone who values novelty, you might be forced to upgrade.

                                            The only paths out of this are:

                                            • reduce your dependencies and your transitive dependencies (eg check how many friends of friends you are bringing in)
                                            • backport the dependencies - fork the problematic dependency and create a new version that is compatible

                                            I don’t think that the incentives are in place for people to make life easy for the original poster: If I was the maintainer for a random dependency, I know that

                                            1. I would be more interested in adopting the latest Rust and providing feedback on the future rather than unpaid support for the past, and
                                            2. I would prefer to use other dependencies than to write everything myself, and deal with updates as they come

                                            Once again, it comes back to who is paying for the time it takes to do the work. Complaining that people haven’t spontaneously done the work you need for free is not going to inspire much change.

                                            @Anyone want to start a small online consultancy that will take on these kinds of jobs for people, either as a one-off backport or as maintenance contracts similar to RailsLTS.com ?

                                            1. 0

                                              Value novelty: […] ‘I want to contribute to Rust’s progress by adopting the latest versions’

                                              Stability works toward that end as well: “I want to contribute to Rust’s progress by making it easier to use in as wide range of scenarios as possible”. The values end up being in conflict about how to achieve that common goal, not about the goal itself. We all want Rust to succeed <3

                                              I don’t think that the incentives are in place for people to make life easy for the original poster

                                              That’s surprising to me. My experience with other languages (mostly C, C++, and Haskell) made me believe that software authors are largely driven by a need for their software to be used. Perhaps I was fooled by a survivorship bias, i.e. I mostly see and use libraries whose authors are like that, so I assume most authors are like that.

                                              It’s absolutely fine to write experimental stuff that pushes the language to its limits, but (again, coming from other languages) such experiments are usually marked as such, and certainly aren’t the norm in more established, mature ecosystems.

                                              Once again, it comes back to who is paying for the time it takes to do the work.

                                              Sometimes support means not doing the work. Of course, bit-rot is a thing, and takes work to combat — but I’d argue that at least some of the bit-rot in the crates ecosystem is self-induced, unnecessary, and perfectly avoidable.

                                              Without straying into FLOSS sustainability, I think crates will naturally slow down their pace of innovation, which will, in turn, make it easier to provide more extended support. There’s a limit to how long a developer wants to drill down on a particular problem, and there’s a limit to how many new features one can apply to the problem at hand.

                                              1. 2

                                                That’s surprising to me. My experience with other languages (mostly C, C++, and Haskell) made me believe that software authors are largely driven by a need for their software to be used.

                                                This feels like a bit of a back-handed comment to me. I’m certainly driven by that desire, and yet, applications I release such as ripgrep explicitly target the latest stable release. (I do try to ensure that patch releases continue compiling with the same version of Rust as the previous patch release, but that’s about it.)

                                                I used to be conservative about this, but then I asked for feedback on whether switching to a “latest stable” release was okay: https://github.com/BurntSushi/ripgrep/issues/1019 — AIUI, Arch, Debian, Ubuntu, openSUSE, Fedora and Red Hat are all represented there. (In addition to VS Code, which is perhaps ripgrep’s largest deployment that I know about.) Every single one of them said, “yup latest stable is fine.” Nobody raised any concerns (other than the cargo install issue, which I address below).

                                                Very rarely, a user will try to compile ripgrep with their distro’s version of Rust and get upset when it doesn’t work. If this was a very common thing—my perception is that it isn’t, although of course there is survivorship bias here—then I’d perhaps be more willing to to accommodate that crowd. But it’s not. I almost never hear about it. And in those cases, I’m more than happy to ask them what their Rust version is and tell them which tag in ripgrep to checkout so that they can build it. Or otherwise advise them to use rustup. It seems entirely reasonable to me that a user who refuses to use any Rust compiler other than what their slow moving distro provides should be quite happy with an older version of ripgrep.

                                                So tell me, why am I going to spend a lot more time going out of my way to support older Rust releases? You could make the argument that I am not technically maximizing the number of people who use ripgrep—surely there are people who tried to build ripgrep with their distro’s rustc, saw the compiler errors and gave up in frustration without a peep—but of course, the goal isn’t really to strictly maximize the number of users at the expense of everything else. For example, there are certain features that ripgrep doesn’t have that might increase its users, but I resist them because I think they are incompatible with project goals or would otherwise be too much of a maintenance burden. Hell, even using Rust in the first place places some kind of ceiling, since C is invariably available on more platforms.

                                                ripgrep is not experimental software. I at least personally consider it to be a mature piece of software, or at least, I treat it as such. Yet I continue to target the latest stable release of the Rust compiler. I will continue to do so until there is a really good reason that I shouldn’t. So far, nobody has given me one.

                                                Without straying into FLOSS sustainability, I think crates will naturally slow down their pace of innovation, which will, in turn, make it easier to provide more extended support.

                                                I mostly agree that this will happen. Certainly, it has already happened to some extent. For example, the ecosystem used to be in enormous flux around serialization libraries. Once serde 1.0 happened, everything settled down there. Hopefully this will continue to happen.

                                                Personally, I characterize this more as “churn” rather than “maturity,” but I can definitely see the “maturity” point of view on that.

                                                1. 1

                                                  This feels like a bit of a back-handed comment to me.

                                                  I meant it mostly as an observation, and partly as an appeal to professional pride. I’m not sure how to rephrase it to remove back-handedness but keep it clear that it’s not just an opinion. But I assure you (and everyone else) that I don’t think that people who disagree with me are bad developers.

                                                  I’m not convinced that Ripgrep’s experience can be directly translated to Newsboat. Ripgrep was a Rust application from day one, so it’s safe to assume that it only found its way into places where Rust is present. Since the crates ecosystem pushes everyone towards bleeding edge, it’s likely that Ripgrep users already track latest stable for reasons of their own. Thus, they won’t oppose a change in support policy.

                                                  Newsboat is originally a C++ application, and relatively stagnant C++ ecosystem allowed it to spread wider than a Rust application would. By increasing MSRV, you merely loose some potential users; I, on the other hand, will loose existing ones. We’ll see how many at the end of this month, when Newsboat gets released and users learn about the planned MSRV change.

                                                  It seems entirely reasonable to me that a user who refuses to use any Rust compiler other than what their slow moving distro provides should be quite happy with an older version of ripgrep.

                                                  I agree that this is reasonable given the current state of Rust, but I don’t think it’s a good place to be in, long-term.

                                                  ripgrep is not experimental software

                                                  It might not be by itself, but if it requires bleeding-edge stuff, it gets the image of bleeding-edge software. From Debian stable perspective, Rust 1.27+ is bleeding edge.

                                                  Personally, I characterize this more as “churn” rather than “maturity,”

                                                  To me, “churn” means “change for the sake of change”; a related problem, but a different one.

                                            2. 3

                                              Most of the “scare” actually originates from the fact that a few very important things (say, native SSL support, but also crates that get compiled almost everywhere like aho-corasick, etc) didn’t make it yet in the standard library (where IMHO they deserve to be; but I guess noone will talk about it until some “epic npm fiasco” happens).

                                              Thus, I hope Rust crate ecosystem evolves to three tiers: “evergreen” (compiler and standard libraries), “tier one” crates directly supported by the Rust team (native SSL, async HTTP, etc: the most used crates should never feature a bus factor = 1, neither they should be fixed/upgraded/optimized “only when the maintainers have enough spare time”), and “normal crates”. That “tier 1” should be kept separated from standard library because it will cover specific (yet extremely common) use cases on specific platforms.

                                              The “evergreen” six-weeks release schedule, combined with cargo clippy and other goodies, is a real boon (and a demostration that Rust is a mindset, not just a tool). You don’t want your old software to bit rot. If you choose to recompile, you should be ready to work on it again. You don’t want to fix the rot only when some urgent bugfix request comes in, neither you want to install some old version of the compiler and libraries for that bugfix only.

                                              1. 13

                                                Most of the “scare” actually originates from the fact that a few very important things (say, native SSL support, but also crates that get compiled almost everywhere like aho-corasick, etc) didn’t make it yet in the standard library

                                                Speaking as the maintainer of aho-corasick, I would strongly oppose its inclusion into std. It would stagnate.

                                                “tier one” crates directly supported by the Rust team (native SSL, async HTTP, etc: the most used crates should never feature a bus factor = 1, neither they should be fixed/upgraded/optimized “only when the maintainers have enough spare time”), and “normal crates”.

                                                Who’s going to pay for this?

                                                1. 4

                                                  Author here. Sorry, but you missed the point entirely.

                                                  This isn’t about the bus factor. And not about developers, as this quote implies:

                                                  If you choose to recompile, you should be ready to work on it again.

                                                  There are two more groups of people who compile from source: distribution maintainers, and some end-users. For both groups, I (as an upstream author) would really like if those people didn’t have to patch my software to work with their setup. That wish has a limit, of course: e.g. if they don’t have a C++11 compiler, they’re on their own. With C++, that translates into “any compiler younger than 5 years”, but with Rust, it’s more like “a very recent stable, no more than few months old”. That’s too short to my taste, and that’s what the post is all about.

                                                2. 2

                                                  I just ran into a similar issue myself while packaging Librem’s squeekboard for Fedora. Fedora uses the newest stable Rust, and PureOS/Debian uses 1.2X. Luckily not too many changes were required to bring it up to date, but it was miles harder than packaging C++ dependencies.

                                                  1. 2

                                                    I updated the post with links provided by BurntSushi, so readers don’t get a (false) doom and gloom picture I was painting originally. Thanks for the discussion, everyone! <3

                                                    1. 1

                                                      Rust has editions, but it seems they are reserved for breaking changes, not compiler features and warnings.

                                                      1. 2

                                                        Yes; editions are orthogonal to this issue.