On 2018-01-22, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
I'm not sure we're understanding each other here -- my point was that the *only* Rust project which has this policy for compiling new versions is the Rust compiler. No other Rust project requires this. That's what I meant by "exception, not the rule". So I agree with what you wrote, but it doesn't have much to do with what I was trying to say, which is that the following quote ...
So, you say it's guaranteed that only the Rust compiler will only ever use particular code that will be deprecated in release N+1 or only available in release N-1?
I'll be honest that I am not sure of the reason why the Rust compiler is special in this sense. However, from the discussions I've had with folks from the Rust community, it's related to the fact that the standard library is "special" (in the same way that Go's "runtime" and "internal" libraries are quite special) and it should not be possible for a crate (that is built on stable) to have the same properties as the Rust compiler.
I did build test it myself. I tried building Rust 1.22 with Rust 1.20 which failed with actual compiler errors, not just a warning that I have to use the proper version. And I think it's absolutely not unlikely that Rust project X will run into such a problem as well. What keeps Rust project X from using certain language features that were only recently added or removed?
The problem with Rust is simply the lack of stabilization. It's absolutely insane that they think it's ok to break compatibility in minor versions and it blows my mind that so many people find that acceptable.
As has been discussed in the rest of this thread, Rust has a very specific stability guarantee which is effectively following: "Any Rust crate which builds on a stable version of Rust today is guaranteed to build on a future stable version of Rust tomorrow. If it does not, it's a bug." You have given two examples where this was not true: * The Rust compiler, which as we've discussed is not a "Rust crate". * A Firefox version which was broken by the removal of some keyword. From what you describe this sounds like a bug, and a violation of their stability guarantee. Mistakes happen -- though this one seems to be quite large to not have been mentioned anywhere else -- and I hope that you submitted a bug report, because I'm sure that they would've resolved the problem. You mention that Go does a lot of testing to avoid regressions, *so does the Rust community*. They do a "crater run" (rebuild and unit-test of all crates on crates.io) on a regular cadence during development, when large features are being considered for merging, and for gating releases. If they find an issue they either fix it in the compiler (if it's a regression) or they go to the project itself and submit a patch (if it's actually a bug in the project). This is one of the things that is mentioned in literally every talk about the Rust development process. If they really did break Firefox, then I would like to see a post-mortem for why their regular crater runs didn't pick it up. But the right thing to do in this situation would've been to report a bug, rather than to conclude that Rust is unstable and move on without telling anyone.
Rust upstream lives in a universe where they think that distributions are an outdated concept. This is why they are shipping their own package manager and consider such breaking changes in minor releases acceptable.
I agree that their attitude toward distributions is a problem (for us obviously, but also for users IMO). But this is also an attitude that is shared by a very large number of languages and projects these days. I cannot help but think that the root cause of this problem is that we have not done a good job (as distribution developers in general) of convincing people of the benefits of having a distribution that has a global view of packaging of a system.
Finally, one problem with Rust that I ran into when working on the Rust compiler code itself is the high volatility of the language and the code. Things that used to build fine with Rust 1.19 would break with 1.20 and so on. From a distribution maintainer's point of view, this can be very tedious and annoying.
... is not accurate for any project other than the Rust compiler (and the reason for the Rust compiler having this requirement is so that they can use new language features in the compiler itself, not because of stability issues with the language). Any other Rust project must be able to build on 1.x and 1.(x+1) with no changes (and the Rust compiler team tests this quite heavily).
What keeps project X from using certain features of Rust? I have seen projects which would only build with Rust Nightly.
I think us trying to ship projects that use Rust Nightly would be absolute madness (I also think it's mad to depend on Rust Nightly features for a "stable" project, but that's a separate topic). However, we can avoid the nightly problem by not shipping things that depend on nightly (neither Firefox nor the library that spawned this discussion depend on Nightly). However, Rust Nightly != Rust Stable. The "certain features" you refer to are unstable features that cannot be used if you compile with the stable compiler.
So, if SLE wants to update to the next ESR release of Firefox, it will also have to include Rust in the same maintenance request.
We ship a new Go package with most new Docker releases as well (as they usually update the compiler they use every couple of releases, and in the past there were bugs where Docker would break if it was built with the wrong compiler version). This is not really a new thing.
I don't think you always need the latest version of Go for updating Docker. I have worked with both codebases myself and never ran into this issue.
Not always, but there have been cases (we're talking ~2 years ago) where a Go upgrade has broken Docker in subtle ways. This was before runc was a separate project, and they were still using "os/exec" for parts of container setup (which obviously proved to be a horrible idea, and now we have the whole nsexec magic that I'm tasked with maintaining upstream). These days most new Docker releases use a new Go version, and so we bundle a Go update "just in case" (and usually they do actually use newer language features).
Upstream Go always ensures that golang-go can be built with gcc-go. Rust has mrustc for that, but that one isn't supporting anything beyond x86 at the moment.
Hmmm, this is a policy that appears to have changed after the compiler rewrite to Go. I distinctly remember watching a talk where rsc described that they would require you to have version (n-1) of the compiler in order to build version n -- so that the compiler could take advantage of new language features -- and you would start the bootstrapping at go1.4.
Huh? If it changed after the compiler rewrite in Go, wouldn't that mean that before that the compiler wasn't written in Go which means that you didn't have that problem in the first place?
I meant that the policy they *planned* to have was the whole (n-1) bootstrap thing, and the *policy* appears to have changed after I looked into it. If you'd like to see what I mean, you can Google rsc's talks about the Go compiler rewrite from a few years ago. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>