A little over 18 months ago, 1.0 was released. We've had very strong compatibility guarantees since then.
To recap, in Rust, to make additions to the language:
1. Small additions mean make a PR.
2. Big additions mean make an RFC, then a PR if accepted.
3. These PRs go behind a feature flag that lets us track the feature, and only allows it on nightly.
4. People who desire the new feature try it out. (This is what you refer to.)
5. If any issues are found, they're fixed, or, in the worst case, the feature is removed.
6. The feature is made available to stable users, the feature flag is removed, and backwards incompatible changes can no longer happen.
What would be un-healthy is if everyone had to rely on nightly for everything. At the moment, most people use stable Rust. And of the people that use nightly, the largest single feature will be stable as of the next stable release for Rust. But some people are always going to be using nightly features, and that's a good thing: it means that by the time it hits stable, it's already undergone some degree of vetting.
However, many popular or important libraries like Serde or Rocket require the use of nightly. I recall the article a very short while ago on the front page that noted how Rust has effectively diverged into two languages, stable and nightly.
Rocket just came out; I think it's an extremely interesting library, but https://crates.io/crates/rocket shows that it's been downloaded 618 times. It hasn't exactly taken the world by storm yet. I think it shows great potential though! But it's not a good case of showing that the Rust ecosystem largely depends on nightly.
The article you refer to contained a number of factual errors.
> my barrier to entry was anything harder than pacman -S rust cargo
Today, that also wouldn't be the case: "rustup update nightly" and "rustup run nightly cargo build" or whatever, with extra stuff to automatically switch per directory.
These "popular or important libraries" are nice use cases what you might be able to do with Rust in future. But relying on them right now and using them in production is not really a good idea.
- Rocket is an amazing example of innovation, but it's currently just an experimentation.
- Serde works on stable for a long time but they experimented a more ergonomic version on nightly. They iterated upon it with Rust developers to create a new and well thought stable API which will land in the next version of Rust (macro 1.1 in february).
Rocket is likely to follow Serde's path during 2017 and will eventually work on stable in 2018. Building a great langage takes time ;)
1. serde, the best serialization/deserialization library. This works on stable now using the `serge_codegen` crate and a custom `build.rs` script. This will Just Work on stable with no extra setup once Macros 1.1 lands, theoretically in about 5 weeks. But I'm using it on stable now in a half-dozen projects, thanks to a `build.rs` script.
2. Diesel, the high-level ORM library for Rust. This works on stable using a `build.rs` script, and 90% of it will work on stable without the `build.rs` script once Macros 1.1 ships.
There are a few other experimental libraries like Rocket (which looks very slick) that only work on nightly Rust. But I don't think any of them are particularly popular yet.
Personally, I maintain something like two dozen Rust crates and applications, and only two use nightly Rust. Both need Macros 1.1, which should be on stable in about 5 weeks.
How many breaking changes happened in the past 18 months?