
The Rust split: stable vs. nightly - bretthoerner
http://xion.io/post/programming/rust-nightly-vs-stable.html
======
echelon
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.

~~~
legulere
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?

~~~
metajack
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.

------
ekidd
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.

------
kibwen
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.

------
llamp
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.

------
ben0x539
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.

------
hiimnate
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...](https://github.com/rust-
lang/rfcs/blob/master/text/1681-macros-1.1.md)

------
gpm
The comments on /r/rust are worth reading

[https://www.reddit.com/r/rust/comments/5k4sep/a_tale_of_two_...](https://www.reddit.com/r/rust/comments/5k4sep/a_tale_of_two_rusts/)

------
crzwdjk
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.

~~~
ecnahc515
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.

------
kzrdude
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).

------
computerphage
> 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.

------
brson
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.

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

~~~
llamp
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.

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

