3 ms·

Is there a significant limitation in using Rust on the stable branch? Every interesting tutorial, book, or tool I find seems to use nightly. I know it shouldn't

Is there a significant limitation in using Rust on the stable branch? Every interesting tutorial, book, or tool I find seems to use nightly. I know it shouldn't be a big deal but it "feels dirty" and perhaps I should just view nightly as any other language's "stable".

steveklabnik 6y ago
For operating systems development, inline assembly is convenient, which is not yet stable. See the conversation below. The vast majority of Rust users use stable. You just happen to see a lot of folks who are interested in the cutting edge blog about things. (You may also run into older things where that thing is stable now, too, to be clear.)
gpm 6y ago
> perhaps I should just view nightly as any other language's "stable". It depends on the features you enable. Stable is basically just a pinned nightly version with no features enabled, and I'd definitely view "nightly with no features" as more stable than most languages. Using some of the more experimental features would make it less stable, you can generally get a feel for how stable a feature is by looking at it's tracking issue. These days most tutorials/books/tools don't seem to use nightly in my experience, though many still do. But if you're primarily looking at blog posts that are pushing the boundaries of the language (e.g. by writing operating systems) I expect that most of them would be using nightly.
- estebank 6y ago
  Stable is pinned nightly with disabled nightly features and beta backports applied. The difference might sound like semantics, but it is present and can impact you.
kbenson 6y ago
I think perhaps a lot of projects start out using nightly with the assumption that within 6-12 months those features they are using will be in stable. Whether that generally happens in reality, or people get into a loop of "well, this other new features is nice and in nightly, and we're already in it, so why not", I'm not sure.
- fluffything 6y ago
  > I think perhaps a lot of projects start out using nightly with the assumption that within 6-12 months those features they are using will be in stable. In my experience, that is rarely the case. People mostly use nightly features because they just need to get something done, and these features make that easier. The tooling around Rust is quite good (rustup, cargo, docker), so if you follow the language a bit, judge which nightly features you opt-into, pin nightly version in your build environment, etc. breakage only happens when you actually have time to fix it and the fixes are simple. So the bar for how much easier a nightly feature needs to make your problem to overcome its costs is quite low. The moment you are using one nightly feature, the cost of using more is even smaller.
monadic2 6y ago
> I know it shouldn't be a big deal but it "feels dirty" and perhaps I should just view nightly as any other language's "stable". There are two uses for nightly: 1. Access to unreleased features. I think I'm down to just needing this for associated_type_defaults (rfc here: https://github.com/rust-lang/rfcs/pull/2532/files https://github.com/rust-lang/rfcs/pull/2532/files). 2. Nightly allows passing extra compiler flags, which is occasionally useful for debugging things like macro expansion. Personally I've found that nightly is pretty solid and I do tend to use it more than stable, but I certainly would not consider it dirty in itself. Furthermore if you're looking at a tutorial or a book the features it relies upon may have gotten into the stable build.
- estebank 6y ago
  My advice is generally: nightly for development, stable for ci. If you don't rely on nightly features, nightly will still let you reap the benefits of improvements that will land in stable 12 weeks later.
sondr3 6y ago
I think just two years ago it was much more normal to use nightly because of some feature that you needed, this is mure rarer nowadays. I haven't used nightly in months, and then I only used it to take a look at Rocket. Unless you require something behind a feature flag (in which case you probably know what you're doing) you should be using stable.

steveklabnik 6y ago

For operating systems development, inline assembly is convenient, which is not yet stable. See the conversation below. The vast majority of Rust users use stable. You just happen to see a lot of folks who are interested in the cutting edge blog about things. (You may also run into older things where that thing is stable now, too, to be clear.)

gpm 6y ago

> perhaps I should just view nightly as any other language's "stable". It depends on the features you enable. Stable is basically just a pinned nightly version with no features enabled, and I'd definitely view "nightly with no features" as more stable than most languages. Using some of the more experimental features would make it less stable, you can generally get a feel for how stable a feature is by looking at it's tracking issue. These days most tutorials/books/tools don't seem to use nightly in my experience, though many still do. But if you're primarily looking at blog posts that are pushing the boundaries of the language (e.g. by writing operating systems) I expect that most of them would be using nightly.

estebank 6y ago
Stable is pinned nightly with disabled nightly features and beta backports applied. The difference might sound like semantics, but it is present and can impact you.

kbenson 6y ago

I think perhaps a lot of projects start out using nightly with the assumption that within 6-12 months those features they are using will be in stable. Whether that generally happens in reality, or people get into a loop of "well, this other new features is nice and in nightly, and we're already in it, so why not", I'm not sure.

fluffything 6y ago
> I think perhaps a lot of projects start out using nightly with the assumption that within 6-12 months those features they are using will be in stable. In my experience, that is rarely the case. People mostly use nightly features because they just need to get something done, and these features make that easier. The tooling around Rust is quite good (rustup, cargo, docker), so if you follow the language a bit, judge which nightly features you opt-into, pin nightly version in your build environment, etc. breakage only happens when you actually have time to fix it and the fixes are simple. So the bar for how much easier a nightly feature needs to make your problem to overcome its costs is quite low. The moment you are using one nightly feature, the cost of using more is even smaller.

monadic2 6y ago

> I know it shouldn't be a big deal but it "feels dirty" and perhaps I should just view nightly as any other language's "stable". There are two uses for nightly: 1. Access to unreleased features. I think I'm down to just needing this for associated_type_defaults (rfc here: https://github.com/rust-lang/rfcs/pull/2532/files https://github.com/rust-lang/rfcs/pull/2532/files). 2. Nightly allows passing extra compiler flags, which is occasionally useful for debugging things like macro expansion. Personally I've found that nightly is pretty solid and I do tend to use it more than stable, but I certainly would not consider it dirty in itself. Furthermore if you're looking at a tutorial or a book the features it relies upon may have gotten into the stable build.

estebank 6y ago
My advice is generally: nightly for development, stable for ci. If you don't rely on nightly features, nightly will still let you reap the benefits of improvements that will land in stable 12 weeks later.

sondr3 6y ago

I think just two years ago it was much more normal to use nightly because of some feature that you needed, this is mure rarer nowadays. I haven't used nightly in months, and then I only used it to take a look at Rocket. Unless you require something behind a feature flag (in which case you probably know what you're doing) you should be using stable.