The Rust split: stable vs. nightly | Hacker News Reader

The Rust split: stable vs. nightly

xion.io

37 pointsbretthoerner27 comments

This is incorrect and seems inflammatory. Please don't turn this into Python 2 vs 3 debate, because this is nothing of the sort.

Nightly isn't stable because we don't want features to land prematurely. Rust is a great language precisely because it it well thought out. Don't rush things into stable and leave us with legacy cruft for the rest of time. That's dangerous and hurts everyone.

Anyone developing their library as nightly-only should expect to see little adoption. I only develop against stable and I'm quite productive with the tooling. Iron and Hyper are excellent web frameworks, and rustc_serialize gets the job done.

I can't wait to see Steve or another core contributor weigh in on this piece.

> Anyone developing their library as nightly-only should expect to see little adoption.

As evidence of this, it hasn't been so long since 1.0 that anyone's forgotten that "I don't want my code to break" was, in polls, the absolute #1 reason for people not using pre-1.0 Rust, by leaps and bounds.

The biggest difference to the situation with python 2 vs 3 is that code written in stable rust also runs in unstable rust.

A related thing: So far I have only written code using stable rust. I see some people using nightly, but I've never seen someone talking about using beta. Are there numbers about beta downloads? Does beta still fulfill its task if barely anyone is using it?

There's some discussion of allowing beta for nightly Firefox builds. Since the Rust release cycle is slightly shorter than the Firefox one, this means Firefox release will always ship on stable Rust. Meanwhile, nightly can get bug fixes or features slightly ahead of the normal schedule.

Beta is almost exclusively used by Travis CI and other automatic builders, as far as I know. But a huge number of Rust projects are built against it on every commit.

to his credit, xion recommended that crate authors not "build castles on foundations of sand," and is simply commenting on the fact that a lot of people are apparently doing it.

I've been following Rust since way before 1.0 and one of my fears when 1.0 was announced was that it seemed rushed. On the other hand, I completely understood the need for stabilization for people that actually use Rust in production (i.e. not me).

People aren't building castles on foundations of sand. They are building sandcastles, experimenting and building along as the language and ecosystem evolves and matures. Every nightly-only crate should be regarded as highly unstable and experimental. If a lot of people are building sandcastles surely that means that the language wasn't yet ready for that particular castle being made of stone.

And this is a good thing! AFAICT without nightly-only crates being so pervasive due to compiler plugins, Macros 1.1 wouldn't be so close to stabilization. Isn't that exactly what nightly is for? If some nightly feature is used a lot, that means it should promptly be polished and stabilized.

At such an early stage in the language's life the evolution is mutual. The development team responding timely to such issues is just another sign that Rust is a healthy (even if in its infancy) language.

Stable Rust is dead, long live Stable Rust!

You have correctly framed this situation. The linked article, however, was a complete misrepresentation as it declared,

> Stable Rust is dead. Nightly Rust is the only Rust.

Many people and orgs are using Rust stable. In production.

Nightly is a playground.

We shouldn't misinform those unfamiliar with the language or give them the opinion that Rust isn't well managed. Doing so can steer new talent and interest away. We are all relying on newcomers for more widespread adoption and faster growth of our community.

The author probably didn't mean any harm, but I feel like the article is disingenuous and should have a retraction before it causes any confusion.

this is such a good response. i dont think xion would disagree with the notion that rust is well on its way to being great.

I'll ask for a citation for "a lot of people". The only evidence given is a single web framework that was announced 24 hours ago, by someone who up to now is entirely unknown in the Rust community. The only two projects in Rust that run on nightly are Serde and Diesel, and those do already also run on stable, thanks to deliberate effort from their authors, and they will both be completely stable as of Rust 1.15 in February.

(And for the record, I think Rocket is the perfect sort of project for helping us get experience with using unstable features, and helping us prioritize which should be stabilized first. I don't want to knock it just for using unstable features! People are too eager to forget that, as of two years ago, every Rust project was de facto unstable, and we've been making steady progress toward a majority-stable ecosystem since then, as expected.)

You forgot Servo in your list, which runs only on specific nightlies, though we do try to make most of the dependencies buildable on stable.

I was referring specifically to libraries and frameworks that would require common end users to have a nightly compiler to "infect" their own code. I'm more-or-less fine with Servo being a heavy user of nightly given how much that helps us test new language features on a, er, captive audience. :P

I maintain a dozen or two Rust libraries and programs, and close to half of them are real-world production code.

Exactly one of them requires nightly Rust, and that's because it uses a feature (Macros 1.1) scheduled to show up in stable in just under 6 weeks.

There are two reasons not to use nightly:

1. Stuff breaks. I remember the bad old days before Rust 1.0 and its iron-clad stability guarantees. I spent my time fixing a endless stream of GitHub issues reports across a half dozen projects. Modern nightly isn't so bad, but I'm still guiltily sitting on a PR about nightly breakage (as usual). But something that works in stable Rust just keeps working.

2. Stuff goes away. Nightly only features do get removed, and then you're stuck only building with an ancient nightly build.

There's so much incorrect information in this post that I almost know where to begin to refute it. An RFC to stabilize extensions was accepted literally last week. The vast majority of code that is only on nightly is because of unstable deriving, which will be stable in less than six weeks. The community is emphatically not embracing nightly, exactly the opposite. A Python scenario is impossible because stable is a strict subset of nightly, and even using unstable features on nightly requires explicit opt-in. And so on.

This seems like mostly hyperbole. Rust 1.15, which is a bit over a month or so away, is slated to have macros 1.1 which covers much of the need for compiler plugins. As I understand it macros 1.1 was in part prioritised by the Rust team so that users wouldn't have to use nightlies.

If no one develops serious bleeding edge bullshit against rust nightly, the features that are only in rust nightly aren't gonna get any real-world experience that can inform whether they should go into rust stable, so it sounds like the dichotomy is working as designed to me.

I do agree that there is a problem with the nightly/stable split in Rust, but I think a big part of this problem will be solved by macros 1.1: https://github.com/rust-lang/rfcs/blob/master/text/1681-macr...

The comments on /r/rust are worth reading

https://www.reddit.com/r/rust/comments/5k4sep/a_tale_of_two_...

One real issue with the nightly/stable split is that it hasn't been entirely clear when things will actually be making it into stable. I understand that software development is full of uncertainties and sometimes you just don't know how long an implementation will take until you actually build it. But right now, to someone not involved in developing Rust itself, it's hard to get an idea of what the nightly-only features are, where they are in the stabilization process, and when they might be expected to appear in stable. For a concrete example, I only found out that custom derive will be out in 1.15 because I happened to read Hacker News. And there doesn't seem to be any index of RFCs or where they are in the process at all, or at least not anywhere that I could easily find. In the core team's defense, they're eyeballs deep in this stuff all day every day, so they have a pretty good idea about what is where and how far along things are. But us users who only glance at what's in each new release and only upgrade every 6 months would really like to know whether to bother to bother installing nightly for the shiny new feature or just wait for the next release that will have it and be actually stable.

Following this week in rust helps me keep track of what's happening. I also occasionally skim the the internals discourse to see what kind of topics are being discussed.

There's another distinction that is not made here!

I recommend the nightly toolchain for development, but to target the stable Rust platform. This is possible because Rust is that good and unbuggy. Use nightly to get the best development tools, stable for the best platform (that doesn't break builds randomly).

> at least one feature that won’t get stabilized ever: > #![feature(plugin)]

> This is how they are utilized by Diesel, for example, a popular ORM and SQL query interface; or Serde, a serialization framework.

Diesel and Serde are going to be fully available on Rust 1.15, which is < 6 weeks away. This is actually an example of the complete opposite: the Rust project is working hard to get important projects to work on stable Rust so that people don't need nightlies.

Dependence on the nightly channel has been one of the biggest risks in Rust. The problem is not solved yet, but it will be. The Rust stable / nightly split is disimilar to the Python 2 / 3 transition in important ways. The notion that 'nightly Rust is the only Rust' is premature, and Rustaceans should be cautious about encouraging that notion.

It's undeniable that there is a significant amount of Rust software still reliant on unstable features, but I have not seen any numbers that would put it in perspective. Having consistent measurements of nightly vs stable adoption would help a lot, inform any conversation, and efforts to move off nightly.

So I think it's premature to say that 'nightly Rust is the only Rust', The article suggests that people are using nightly as the de-facto recommended toolchain, without evidence (though I'm sure somebody has recommended nightly be default). I'd encourage people not to recommend nightly and for Rust library developers to aim for their crates to be compatible with stable. I personally don't have the same sense as the author that Rust application or library developers are using nightly more than they have in the past. Rather I know that developers of key nightly-only libraries are actively involved in ecosystem migration off of nightly.

One of the biggest difference between the 2 / 3 split is that stable is generally compatible with nightly, and is intended to catch up with nightly, whereas Python 2 is not such a strict subset of Python 3 and its development is done. That is, nightly is intended to be a staging ground for stable; Python 3 does not have that same relationship to Python 2.

(Edit: I stated this awkwardly. In this comparison nightly=Python 2, stable=Python 3. The point stands that the relationships between the two branches are different between the two languages. Nightly development feeds into Stable, Python 2 doesn't feed into Python 3, it is not under active development.)

Because of this relationship there's still reason to have confidence this dependency on nightly will shrink over time. But not disappear. We would always expect some people to depend on nightly. That is its intended purpose - as a breeding ground for future features.

Some of the biggest features keeping people off stable Rust are coming, and their biggest users are actively migrating. In the near future there will be fewer reasons to use nightly, not more. And beyond that the reasons to stick to nightly will evolve as Rust evolves. The next demographic of users who will be stuck on nightly will be embedded developers, and that contingent will increase over time. But even as that group increases, the group that is freed up to use stable Rust will grow also. And slowly the stable ecosystem will coalesce for all classes of users and all types of code.

Though I don't believe it's happening to the extent the author does, I'd rather not see Rustaceans who care about Rust's future to adopt a nighly-first mindset. More things will get more stable, faster, by working together. But regardless of people's dispositions to the stable / nightly split, more of the ecosystem is going to work on stable over time - that is how the Rust feature pipeline works - and eventually stable Rust will be the only Rust.

I still expect it to all work out ok.

i often encounter xion in the rust irc and he is always a great help. cheers.

It seems odd that someone connected with the community would make a statement like "Stable Rust is dead. Nightly Rust is the only Rust." given much of his argument deflates in a month or so. Perhaps important developments are not being disseminated as well as I'd thought.

AFAICT the author appears to be hastily overreacting to the announcement of Rocket yesterday, which is a web framework that uses unstable features.

xion knows many languages and if i had to guess, i would say that he sees rust in an objective manner because he doesnt latch on to any one language. his presence in the rust community shows that he thinks rust is worth while, though. im glad to have his opinions.

Reply on news.ycombinator.com