I am a big fan of Rust. But I am afraid or at least many people that have heard of rust that it is unstable in the sense of languages components coming and going away overnight. Although I know that is not exactly the case it is hard for me to find a release cycle for Rust similar to something that Microsoft puts out for .NET and C#. Could someone please enlighten me?
https://users.rust-lang.org/ is the place to ask these questions. If you use nightly rust and enable unstable features, yes, you will see language components coming and going away overnight, because that's the point of a nightly channel, testing new features. Stable rust, of which a new release comes ever 6 weeks, has strict stability guarantees. You can read the details here: 2052-epochs - The Rust RFC Book (epochs were renamed to editions)
Stability as a Deliverable | Rust Blog may also be relevant. It is the original introduction of the stability guarantee.
every 6 weeks!
11 Likes
Oh, yup, sorry 
1 Like
No worries, sometimes our brains just canʼt be helped in their desire to auto-“correct” this seemingly ridiculously short release cycle length. I've seen people going further with this kind of confusion than a simple typo and comparing Rustʼs release cycle to Javaʼs, calling them the same. (Java has actually 6 months cycle, and honestly thatʼs still very fast if compared to the situation before 2017 having irregular releases with multi-year gaps, the longest being almost 5 years between version 6 and 7. Admitted, this comparison may be inaccurate, there were of course updates for e. g. security in between those Java releases.)
4 Likes
It's important to note that it doesn't mean new features are invented, designed, and released within 6 weeks.
Most features in Rust took many years to develop, and lots of them are still in progress. The 6 week cycle is just a periodic snapshot of what has been finished and is ready for use.
17 Likes
As far as I understand, a new Rust edition doesn't break interoperability with old code (that still uses an old edition). At the same time, Rust development seems to address bad design choices of the past (see the plans for Rust Edition 2021). To me, this appears to solve the issue of the seemingly contradictory goals of not messing with the ecosystem and fixing bad design choices at the same time.
Looking at Haskell, for comparison, I was very frustrated how the applicative functor monad integration still doesn't seem to have been completed 100% yet (due to issues with breaking code, if I'm right; correct me if I'm wrong). The original paper on applicative functors has been published over a decade ago.
Or if we look at Python, there was a split of the ecosystem into versions 2 and 3 of the language (and the transition from moving everything to Python 3 still isn't completed in many places).
Apart from the amazing language concepts, Rust also has a development model that allows to further improve the language while maintaining stability guarantees that are required in larger real-world projects. Great job, and a big thumbs-up from my side! 
7 Likes
Yeah, that's the idea. It does limit some changes, but they're mostly thing we won't want to do anyway (too much breakage). One interesting experience was implementing IntoIterator for arrays in the 2021 edition.
Exactly. And I believe the 6 week pace actually contributes heavily to making the language more stable.
When you have a long release cycle like 6 months or 12 months, or sometimes even 3 months, the cost of "missing the release" is much higher, so there's a tendency to push to get features done by the deadline. That can mean a feature doesn't quite get the polish or review that it should.
6-8 weeks feels like about the longest amount of time for which you can comfortably say "things are ready when they're ready, if they're not ready they can catch the next train and that won't be too long".
Rust editions, by contrast, happen every 3 years. As a result, Rust's first edition, 2018, did end up motivating people (myself included) to push some key features hard to get in. This didn't necessarily impact the quality of implementation, but it absolutely affected the degree to which some of those features lacked clear documentation and similar. Some key bits of the documentation weren't fully fleshed out until well after the edition release.
Many people have remarked on the Rust 2021 edition feeling "smaller". I think that's a natural consequence of this edition not being the first, and people feeling confident there will be another in the future. Rust 2021 doesn't feel like it includes anything that was not entirely ready and even clearly documented. (And even despite that, I think some of the Rust 2021 features will end up being quite impactful on how people use and learn the language, and how easily people can work with Rust.)
17 Likes
One thing I'm curious about is who tests the beta releases. Everyone seems to either insist on being on stable or is on nightly (particularly if they rely on features that are stuck in nightly for significant periods of time).
1 Like
Patches for bugs found on nightly can be ported to beta. If a bug is found quickly by a nightly user and fixed quickly (both within ~6 weeks or even a bit more depending on where in the release cycle we are), it’s effectively caught on beta. Also there’s the crater tool that will AFAIK be used to test each release while it’s in beta.
Note that the status/stability of each beta release changes significantly throughout its 6 weeks of existence. Right when it comes out, it’s just as unstable as nightly, containing all the latest commits of PRs up to the point of its creation. Then over time it accumulates beta-backports of regression fixes and gets tested with crater at some point (I’m not actually quite sure when exactly that happens(*)) all incrementally increasing its stability more and more until its finally considered as stable as a fresh stable release. And then it becomes the next fresh stable release.
Edit:
(*) Here we go… According to Rust Forge:
A crater run for beta should be started as soon as we have beta out.
Which is, thinking about it, the only reasonably approach – the sooner the better.
This means that beta is indeed a weird choice for productive use. It’s not really any more stable than nightly when released, so you don’t really get stability benefits, and when you don’t want the stronger stability of a tested release, you might as well use the cutting-edge / latest nightly which will often get the bug fixes faster than beta (the approach: first fix on master, then backport to beta is not uncommon). The beta release makes more sense for dedicated testing than for productive use. Towards the end of its lifetime it can be used if you can’t wait any longer for a new Rust release. Regarding testing: it’s used for crater runs, as mentioned (AFAIK); and usually all undiscovered bugs in beta are also undiscovered bugs on nightly, so bugs discovered on nightly are most often immediately tested on stable and beta, too, by the person that finds them.
Elaborating on that last point: If you find a compiler bug on nightly, you (the reporter or someone else) will usually check if it’s a regression. You’ll check a reproduction of the bug on the current and older releases and also beta to get a quick / rough time frame of how old the bug is. For this to be straightforward, it’s important that you can just as easily access beta with rustup as you can nightly, stable or older releases (by their version number). In case the bug is quite new, it might be
- only on nightly
- on
nightlyandbeta, but not on the lateststable - on
nightly,betaand lateststablebut not on olderstable
Depending on which is the case, you’ll then get a feeling of urgency: How fast do we need to fix it? In the 2nd case, when will the next stable release be? (The bug will, if unfixed, land in that release.) Perhaps even a point release of the current stable is needed? (In the 3rd case, if the bug is important.)
See also:
4 Likes
Actually beta fits well for the developer machine. It has same release cycle with stable, tries to be stable without any feature flags, and most importantly, you can play with newly stabilized features 6 weeks before it lands to the stable. You won't get any stability issue if you run CI/CD on stable.
Is that an advantage over nightly?
If you don’t use any feature flags, nightly tries to be just as stable.
On nightly, you can play with newly stabilized features immediately when they’re stabilized.
So, what’s the advantage of beta over nightly?
I’m not sure I understand what you’re saying here.
With 6 weeks release cycle you can rustup update freely without much consideration, usually without any breakage, every components are just there. This is a huge advantage if you don't actively track the toolchain internals.
What kind of breakage are you referring to? AFAIK, rustup will skip nightly versions where components that you opt into are missing.
TBH I can't name any specific breakage here. What I wanted to mention is that I hardly feel "It just work" experience on nightly. Versions published every night, components become broken and fixed, It's hard to track where I am if you're not used to it. And it's mostly intentional to rapidly develop the Rust project itself.
To me the beta has similar product-ness with the stable - it's just one minor version above the stable, and 6 weeks less tested.
FWIW, this isn't true.
Beta gets new releases roughly every time a beta backport happens. This is easily less often than nightly, but clearly more often than stable gets updated.
And I do actually typically do my develoment on beta, personally. I have a number of projects that have a nightly override, but my rustup default is beta. My reasoning is using tomorrow's stable today, but dodging (most) stable-then-reverts and only ever having to wait one train to publish a library.
That, plus just a little bit more of beta testing.
What about documentation? When a fix is applied to the git repo (nightly), when will it show up on https://doc.rust-lang.org/? Is there a site to read documentation changes before that date, like https://doc.beta.rust-lang.org/ or some such?
std - Rust is always the latest release.
Nightly stdlib docs are available at std - Rust
And so are versioned docs: std - Rust (or beta)
It's the same for (some) other books on that domain.
4 Likes