1. Rust has very strong stability guarantees. If you want to you can continue coding like it's Rust 1.0 even on the latest compiler.
2. The rate of releases is independent of the rate features are added. Nightly is a playground for feature additions and whatever else. Many may not ever make it into stable, and many might hang around for many years before they are read to be stabilized. A consistent release schedule of every six weeks, whether there's much new or not, means there's no harm in delaying something for a release or three. This vastly reduces the pressure compared to a 3 year release cycle where missing the window means a very long wait.
Rust's releases tend to be very small. Even the big async addition was only the async MVP, not the final product. I think this is probably the source of most complaints because it does introduce some genuine churn for async projects.
But as always this is hard to discuss in the abstract. At least not without some idea of what features people think shouldn't have been stabilized or which they think were rushed.
Btw, here's a good article that attempted to look in to this more objectively:
> 1. Rust has very strong stability guarantees. If you want to you can continue coding like it's Rust 1.0 even on the latest compiler.
There have been at least two cases where Firefox build broke due to having a too recent version of Rust installed. The stability guarantees may be fairly strong but it's definitely not perfect.
Use of uninitialized memory is Undefined Behavior. So in a sense, that code never worked properly, but authors didn't know about it until Rust caught it explicitly.
It's undefined behavior. Anything can happen, by definition.
I understand what you're saying, but anyone who knowingly relies on undefined behavior deserves whatever pain they get, and anyone who didn't know they were relying on undefined behavior, needed to know about it.
Rate of features added being high could be directly proportional to our code going obsolete sooner than later. Wouldn't it?
I also understand that Rust is quite backwards compatible which is good but a planned better version of releases would be easier for everyone to keep track, update codes, etc.
Is the rate of features being added high? Things that wouldn't even be a footnote in a new C++ release announcement can be highlighted in a Rust release announcement which may give the impression of lots being added but it ultimately doesn't amount to much.
As long as the compiler remains backwards compatible nobody forces anyone to rewrite programs that deliver their requirements at the time they were developed.
Major compatibility breaks occur on a very long time-frame and most certainly with a version bump prominent enough to draw anyone's attention. Personally, I expect builds to suddenly break on dependencies rather than anything else.
1. Rust has very strong stability guarantees. If you want to you can continue coding like it's Rust 1.0 even on the latest compiler.
2. The rate of releases is independent of the rate features are added. Nightly is a playground for feature additions and whatever else. Many may not ever make it into stable, and many might hang around for many years before they are read to be stabilized. A consistent release schedule of every six weeks, whether there's much new or not, means there's no harm in delaying something for a release or three. This vastly reduces the pressure compared to a 3 year release cycle where missing the window means a very long wait.
Rust's releases tend to be very small. Even the big async addition was only the async MVP, not the final product. I think this is probably the source of most complaints because it does introduce some genuine churn for async projects.
But as always this is hard to discuss in the abstract. At least not without some idea of what features people think shouldn't have been stabilized or which they think were rushed.
Btw, here's a good article that attempted to look in to this more objectively:
https://steveklabnik.com/writing/how-often-does-rust-change