I doubt that a Rust LTS by the Rust project rather than a distro would solve anything in that area at this time. Distros appear to be packaging Rust apps the way they package Go apps: Dependencies as source to enable in-archive builds, but the app is statically linked. There doesn't appear to be huge pressure to change that at this time. Also, an upstream doing an LTS doesn't mean that distros will trust the upstream to do exactly what the distros feel they want. (E.g. Ubuntu LTS ships their own LTS kernels and not kernels from a kernel.org LTS branch. Debian does their own versioning for security patches on top of whatever shipped with a distro release originally, etc.)
As a RHEL maintainer, I accept the burden of maintaining whatever version we snapshot for the duration of our support period, as you say. But note that we’re also not putting rustc in the base OS yet, only in the devtools SCL products that have a shorter support period. (But it can also get more frequent rebases that way.) Since you mentioned Ubuntu 14.04, note that rustc is in “universe” there, which community-maintained.
I am more concerned about the broader community though. I do think that crate authors should care about long-term compatibility, and I think it’s too dismissive to call enterprise users “invisible” or walled off. Enterprise developers certainly do write new software with their stable (old) tools, but I think they’re going to be less likely to choose Rust if the crate ecosystem is too much of a pain to find compatibility.
Take a look at popular C++ libraries – how many of them now require C++17? C++14? We may finally be to the point where at least C++11 is generally required. Yes, Rust is still quite young, but if it wants to move into such software domains, it will take some effort to understand those kinds of expectations (even as it pushes back new expectations).
Sorry if this is too rambling. I’ve had it in mind for a long time to write some kind of RFC for a Rust LTS/ESR/whatever, so I’m happy to see this thread, but I don’t really know what all the answers should be. It’s hard to balance this desire to use shiny new features against the stability needed for long term software maintenance.
6 Likes
In general, yes. However, universe is also the place where Firefox-required toolchain backports go. For comparison, the gcc-mozilla package lives there, too.
That was meant as a positive statement about the less entitled attitude of RHEL users relative to the more entitled attitude of (some) Debian stable users. (Note users rather than maintaners in that sentence.) The logic goes that since Debian is a community project, the larger community should help enable Debian users to build new upstream software with the old toolchain in Debian stable. As noted, the relevance to this discussion is two-fold: 1) if an LTS isn't behind a commercial subscription, there are more people who use LTS without a very serious need to do so leading to LTS appearing as a bigger addressable audience creating more pressure to hold new software back in order to be compatible with the LTS and 2) when the LTS is perceived as a community effort, people feel it's more OK to ask the larger community to bear the externalities of the LTS.
My conclusion from this is that Rust should treat the C++ situation as something to avoid. It's super-sad that in 2018, when the latest GCC, clang and MSVC are a download away, stuff like Abseil enabling users of C++ stick to C++11 while backporting some newer features is perceived as a valuable thing.
That is, I think Rust should identify what it is that makes people shy to take a free-as-in-beer compiler upgrade up from C++11 and then avoid making the same mistake in the Rust context so that we can get users of Rust to keep upgrading rustc instead of the library writers diverting effort into enabling them not to.
6 Likes
Frankly, there is no such thing as a problem-free upgrade in the general case. Even rustc's relatively strict language-stability policy has exceptions. The larger a system gets, the more likely it is to run into those exceptions. At some level, those systems are going to delay upgrades so they can schedule the inevitable work they will require.
And even if you could solve all of those problems (and I hope we can eventually!) there will still be logistical problems. In a large organization, you have a bunch of dev machines, a bunch of CI infrastructure, etc. and it all has to be updated at the same time because Rust's ABI is unstable.
I suspect that as Rust grows we will see more LTS-like behavior even if there's no official LTS release. So while I don't know if it's worth making one, it feels inevitable that people will want one.
2 Likes
Which is why the idea of an LTS release of the compiler is meaningless. You either are prepared to fully test and validate your software when it is built with appropriate automated and manual tests or you aren't. If you are, then using the next compiler version, which, due to the Edition System is guaranteed to be backwards compatible, is a trivial matter. If you aren't, then even applying a bug fix to the compiler version, hell, even changing an optimization flag or building on an updated CPU, is a complete unknown as to whether or not your software is reliable.
I just don't see what the idea of LTS, separate from the Edition concept, brings to the table? I'm going to freeze at some Edition/Compiler version, call it an LTS, but, then apply bug/security fixes to it and rebuild my software with confidence that?????? What?????? It doesn't make any sense whatsoever. I'm sorry, the whole concept is just utterly and completely flawed and doesn't even have internally consistent logic.
Why the hyperbole? You’re clearly missing whatever it is that drives people to use LTS releases of their software, so maybe chill out for a minute and think it through.
For example, maybe those bug fixes are much smaller in scope and easier to re-validate? Maybe they happen less often and can be re-validated in batches? Maybe they don’t need the level of validation that you assume? There are a lot of possible explanations, and denying reality is unhelpful.
3 Likes
Do GCC or Clang provide LTS releases of their compilers?
3 Likes
Yes, I'm missing it because it hasn't been clearly and logically articulated what the benefit of an LTS release is over the Editions. There is no hyperbole and no need to chill - no one is "heated" 
Just because someone disagrees with the proposal and doesn't agree that you've made your case, doesn't make things "heated" or "hyperbole". In fact, bringing words like "hyperbole" into the discussion is again flawed argument.
The explanation/proposal so far doesn't make sense and lacks even internally consistent motivation.
The proposal for an LTS seems to be:
- Someone wants a consistent/reliable platform to build against with guarantees that their software won't break
- They don't want to use new Editions because???? Why????
- They want to stick to whatever version they originally built with, but, they want security/bug fixes to that version over a long time period....Why? So they don't have unexpected changes/bugs in their software? So they don't have to do as thorough of testing?
I have software that builds and passes all my tests. I upgrade to a new Edition. My software, without changes is guaranteed (sans bugs) to build and be equivalent (sans bugs) without me having to change my software. How is that different from me building with a new "micro/security/bug-fix version" of the compiler? What does the latter offer me that the former does not? I haven't seen anywhere it articulated what the benefit is (beyond a lot of "Maybes"). That is why I say the idea/proposal lacks even internally consistent logic.
For #1, the Edition system accomplishes that. For #2, I can't even counter-argument because no reason has been provided. For #3, just doesn't offer anything of value beyond using a new Edition. In fact, it offers less. It requires back-porting (which can and will introduce additional/different bugs over time) of security/bug-fixes from the latest Editions with the potential of requiring odd work-arounds to make whatever patches are necessary compatible with the old code base. This seems like a higher risk rather than a lower risk. If the idea is that less testing/verification of the build is required, that is just not consistent with the idea that any change may introduce a bug/regression at any time. The way you avoid that, is through comprehensive, unit, regression, and integration tests. Not by gambling that somehow an LTS release with back-ported security/bug fixes is less of a risk than the latest/greatest compiler Edition.
Personally, I strongly dislike many additions and changes to Rust which are expected to land in the 2018 edition, and I feel they are causing it to steadily move away from the simple, orthogonal, systems programming oriented original path towards a model more akin to modern scripting languages which are not to be named here, with the language team preferring the addition of several infrequently necessary convenience features over keeping the core small, thus making the language bloated, unnecessarily complicated, and sometimes uglier, and so inevitably introducing misunderstandings and in turn bugs. Therefore, I would very much prefer sticking with the 2015 edition even in my new projects.
2 Likes
Again, I think you misunderstand “Editions”. You will be able to build your 2015 Edition Code with the 2018 Edition Compiler without change and without having to use any of the new features AND you will be able to inter-operate seemlessly with both 2015 Edition Crates and 2018 Edition Crates all built with the 2018 Edition compiler. So, again, where is the benefit of an LTS? I’m just not seeing it. (Seriously, I’m not trying to be a prick or anything like that.)
No, I don't think so.
Yes, I know this. However, once I start using the new edition, coworkers, contributors, etc. will inevitably start using new features / asking me to use them. So realistically, the "you don't have to" argument only works if I am the sole contributor to a crate. This is more of a cultural rather than a technical issue, but it's still important.
Ah....OK, I see where you are coming from, but, I just don't think that is a reasonable stance. That goes against the "Stability without Stagnation" mantra that is a hallmark feature of the Rust ecosystem. You are saying you want "Stability with Stagnation, with security/bug-fixes" and you want that to be called an LTS. That just doesn't seem like a reasonable thing to expect of the community (IMHO). I can see contracting with a commercial provider to provide that guarantee against some chosen Edition of Rust (and I'm sure as Rust becomes popular, lots of providers will be happy to provide, contract, and bill you for that service), but, it just doesn't seem like a reasonable thing to expect or demand from the community at-large.
Exactly my thought -- people here mostly talk about individual C++ standards and their support, but not about compiler versions themselves. For example, the GCC development plan keeps updating two major versions at any time. There may be updates to older compilers but I am not sure if any patches to older releases are by the GCC team or package maintainers.
So asking anybody with a better insight into the GCC/Clang development: What is the status of long-term maintained releases, and how often is it necessary to avoid updating to a new major GCC version to avoid some breakage? And what is usually the breakage cause? (E.g. your project code, code of third-party libraries, binary-only modules and ABIs, or perhaps outdated libraries required by the compiler in the linux distros?)
3 Likes
GCC releases major versions once a year, and generally issues updates for the past two.
LLVM (w/ Clang) releases major versions twice a year, and usually only issues updates for the latest. I think they're planning a spectre/meltdown update for LLVM 5 though, as an exception.
Compared to Rust every 6 weeks, even their regular releases look like LTS!
1 Like
The GCC team and package maintainers are overlapping sets.
1 Like
Yes, but, when a particular developer applies/back-ports changes/bug-fixes/security-fixes to an older compiler version (i.e. not the current/latest), would you consider that they have their "Package Maintainer" or "GCC Contributor" hat on? Perhaps, more importantly, which hat do they think they are wearing at that point?
That’s still a blurry line – changes could be motivated by their package needs or something external. Why do you think it’s important to distinguish their role?
If I'm the package maintainer for (for example) Debian Rust packages, but, I'm also a regular contributor to upstream development of Rust and Rust compilers, when I am performing my duties as a Package Maintainer, I have a certain set of goals and motivations (and responsibilities); however, when I'm contributing to development of the Rust compiler and ecosystem, I have a different set of goals and motivations (and responsibilities). So, if I were to back-port bug/security fixes from the current Rust development stream to an older (let's call it LTS) version, under which set of goals, motivations, and responsibilities am I conducting that activity? Similarly, if I am adding new features to the language or fixing bugs or security issues in the current release train of Rust which "Hat" am I wearing?
Just because I do both things doesn't have anything to do with which group is ultimately best responsible for a particular activity. This tends to make the fact that you pointed out that the two groups overlap somewhat irrelevant to the discussion, iif it is clear that the various activities naturally fall into one or the other roles (hats).
I (and probably many others) would argue that there is a clear distinction in these roles and responsibilities and that conflating them isn't useful in determining if having a Rust Community Maintained and Sponsored LTS Release is appropriate. In fact, I would argue that identifying under which role (hat) these activities are normally conducted pretty much makes the answer apparent.
I would be willing to bet that most, when pressed, to clarify under which role they were operating for the various activities would say:
- Package Maintainer: back-porting bug-fixes/security-fixes to older versions/LTS releases
- Compiler Contributor: New features/bug-fixes/security-fixes to the current compiler development (though there may be multiple branches considered "current")
If that is true, then the argument for a Rust Community Sponsored/Supported LTS, as opposed to a distribution package maintainer and/or commercially supported, release is fairly weak (IMHO).
I don't agree with that. If you are the crate owner, you simply set the Edition version in your cargo.toml and forbid PR's that change it. If you aren't the create owner, then, well......when in Rome.
It may well be that the “Rust Community Sponsored/Supported LTS” would be primarily driven by packagers, but it’s still valuable for such people to collaborate, rather than reinventing the same efforts in their own silos.