7 ms·

How/why are so many people using nightly as their rust version? Usually companies are conservative about jumping onto newer compiler versions.

by dman 8y ago

the_duke 8y ago
At this point, I think it's mostly being used to it as nightly was more convenient for a long time. I've currently switched to nightly to use the 2018 edition changes already, which will soon be unnecessary. Almost all libraries work fine on stable now. (the new async/wait support is an exception, but it's still very experimental right now and not used by many) Important note: You can always develop on nightly and get potential speedups etc, but not use any features and then deploy only with stable.
cp9 8y ago
> When asked why they used nightly, people responded with a broad range of reasons including: access to 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm. as for how `rustup install nightly`
zellyn 8y ago
For a long time, there were really useful things that were available only in nightly, I believe. The Rust team has also done an unprecedented job of balancing stability and improvement.
- steveklabnik 8y ago
  Yes. Note that there’s also lag, this survey was taken much earlier this year. And so: > When asked why they used nightly, people responded with a broad range of reasons including: access to 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm. wasm, clippy, embedded, and proc macros aren't nightly any more. NLL, 2018 edition are coming soon. (December 6)
yoklov 8y ago
It's very easy to use nightly (install via rustup, then `cargo +nightly blah --args` instead of `cargo blah --args`), and there are (ugh, still) a number of somewhat popular libraries that require nightly versions of the compiler. In particular, using nightly allows you to opt-in to a number of experimental language features in exchange for maintenance burden. It's not a choice I make, although it's fun to do every now and then just to get a feel for what's available in the nightly builds.
- beatgammit 8y ago
  I've been able to find good libraries for everything I need on stable now that Diesel is on stable, so there's not really a requirement anymore to use nightly for most things. For example, I use actix, which works really well. It's not as ergonomic as Rocket, but it's way faster and quite useable. The same is true for pretty much everything I need, so I only use nightly when I'm dinking around with something that doesn't need to go to production anytime soon.
  - yoklov 8y ago
    I think `async/await` is the big one for network stuff. Rocket is the library I was thinking of when I wrote that, though. My (possibly mistaken) understanding is that my coworkers who do more web servery stuff than me prefer actix to rocket for other reasons too, and wouldn't use rocket even if it worked on stable. I don't really know the arguments around them, TBH.
    - steveklabnik 8y ago
      The big one is that Actix is able to use async IO, but Rocket is sync.
StreamBright 8y ago
Companies using Rust are not too conservative I think. Conservative companies use Java or C++, or something similarly stable and easy to hire for.
- ElBarto 8y ago
  It's not really a question of being conservative but of being professional, I would say. Using unstable anything on production software is not professional, on mission critical software it is reckless incompetence.
  - wongarsu 8y ago
    Depending on your testing and release process using an unstable compiler may not be a big deal. Unlike a webserver or a JIT you run the rust compiler once with your final product and can spend as much time as you want to verify the result.
    - ElBarto 8y ago
      But then the question is: what's the point? Any difference between production and dev/testing environments should be justifiable. Certainly in the last testing stage there should be no difference at all. Nightly builds of any software are only there to enable testing 'in the wild' of that software. There's no justification for any other use. Edit: The Rust community really needs to grow up...
      - dang 8y ago
        Would you please stop posting flamebait to HN? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
        ElBarto 8y ago
        I thought I had posted constructive comments on this discussion. If discussing good software practices is "flamebait" that deserves to be downvoted, which was what my "growing up" quip was about, then I am at a loss as to what to do...
jcelerier 8y ago
I've seen some people gladly using nightly rust but restricting themselves with the GCC and CMake that comes with CentOS 6. The damage done by distributions shipping development toolsets is never-ending.
- mroche 8y ago
  There’s a DTS that ships Rust 1.26 (rust-toolset-7), however, it requires RHEL/CentOS 7. Red Hat’s been doing a pretty good job with providing newer toolkit’s through the DTS system, but some of them didn’t find their way to RHEL 6.
  - steveklabnik 8y ago
    They also announced this recently: https://developers.redhat.com/blog/2018/11/20/support-lifecycle-for-clang-llvm-go-and-rust/ https://developers.redhat.com/blog/2018/11/20/support-lifecy...
- kbenson 8y ago
  > The damage done by distributions shipping development toolsets is never-ending. You say that, but we've already come out the other end of the period where linux was still on the upward swing of popularity and if a development toolchain wasn't as easily available a lot of software may never have taken off as quick. The ability to easily install a development toolset to compile (even if safely hidden behind a script to download and compile something like Ruby, Python, Perl, or a module for one of them) is a major boon, even if just used to create packages for the distribution's package system for local distribution (e.g. creating an RPM from spec). Given the choice between an easily installable default that might get old or no first party option provided, having a default available is vastly better. Blame companies for poor options they choose, not the people and organizations that do their best to provide even a single option.
- jjnoakes 8y ago
  The biggest reason (for me anyway) to restrict which gcc I use (and stick to the system-provided one) is so I don't need to distribute libstdc++ and libgcc_s with my program. The RedHat devtoolset was a nice solution to this (use a newer gcc version, but link to the system libraries), but if that isn't available, then building with the system compilers helps in this area. Rust doesn't have this problem when rust programs are statically linked, but if distros start shipping rust shared libraries which other programs start depending on, and/or some of the rust standard lib ends up in a system shared library, some of the same issues may arise (or maybe not, rust may have solved them in a clever way).
gpm 8y ago
Nightly isn't really as unstable as the name implies. Without invoking `#![feature(...)]` flags it's basically functions identically to stable. Sure, occasionally something breaks, then you type `rustup default nightly-<a date a few days ago>` and keep on chugging. Meanwhile you get access to more and better tools, which has no impact on the stability of your code base but a positive impact on productivity. It enables you to decide to bite the bullet and give up on language stability for new useful features if you want to (which I often do, for nll). So, what I do is develop on nightly, and make things I want other people to use work on stable.
- jnbiche 8y ago
  > what I do is develop on nightly, and make things I want other people to use work on stable. What do you do with the stuff you make on nightly? Use it only for yourself? Edit: oh, I think I see: you don't use any new features when you develop on nightly.
  - steveklabnik 8y ago
    Some people use nightly to actually build, but don't turn on any nightly-only features. This means that they get early access to bugfixes and improvements, but don't actually restrict their users to nightly. (This may not be what your parent is talking about, but it is a use-case I've seen before.)
    - gpm 8y ago
      This is what I'm talking about.
johncolanduoni 8y ago
The biggest one for me is the async/await support for futures, which is not stabilized quite yet. In Rust it buys you not only the usual ergonomics, it also allows you to handle lifetimes in futures in ways that are basically impossible when using only combinators.
2trill2spill 8y ago
Some of the packages I use require nightly, Like the syscall crate and iirc I had to use the nightly compiler for inline assembly as well.
- steveklabnik 8y ago
  Yes, inline asm is still nightly only, and the syscall crate uses it. Incidentally, what do you use the syscall crate for? I'm very curious!
  - 2trill2spill 8y ago
    Rewriting a system call fuzzer I wrote in C several years ago in Rust. I ran into many problems with the C version with memory management across multiple child processes. I figure rust would make the memory management much easier and it would be a great way to learn Rust. So far Rust is making the project much simpler and more robust, with similar performance to the C version.
    - steveklabnik 8y ago
      Neat! That sounds like a great use-case. Thank you :)
      - 2trill2spill 8y ago
        Yea when it's usable to people other then me I'll open source it. But so far it's FreeBSD only and I want to get Linux and MacOS support going as well.
        jcranmer 8y ago
        You're using inline assembly for syscalls on FreeBSD? My recollection when I last looked into it was that FreeBSD only defined syscalls as C function calls, and did not have a stable ABI at the assembly level. (I was looking into it because I was trying to do system calls without having a stack page mapped as part of an assembly sandbox).
Tuna-Fish 8y ago
Right now, a lot of people want nightly (and [Rust 2018]) for NLL. It makes the borrowchecking system a lot more precise and less conservative, which in turn makes the language much less annoying to use. Using nightly as the compiler is much easier in Rust than, for example, using Python 3 early on was, because unlike, say, Python 3, nightly is fully backwards-compatible to earlier stable releases. (While not being backwards-compatible to previous nightlies.) This means it's easy to limit yourself to the features used in stable + one major change you want, and if there is no change to that major feature, you won't even notice all the instability of the compiler. There has been some hope of people moving to stable versions as NLL hits them, I think most people will always want the next big feature (personally waiting for const generics) on nightly, at least until the language is a lot more complete.
- steveklabnik 8y ago
  > Right now, a lot of people want nightly (and [Rust 2018]) for NLL. 9 more days!
  - moosingin3space 8y ago
    NLL is stable in 1.31?
    - steveklabnik 8y ago
      For 2018 edition code, yes. 2015 will come later.
      - moosingin3space 8y ago
        I am incredibly excited for this!
- cies 8y ago
  > at least until the language is a lot more complete. Or used in larger projects. Or used in environments where (a) dev's prefs cannot be nightly.
hnbroseph 8y ago
when i was checking things out a while back, it felt like every interesting library required nightly. it was a significant turnoff. :\
- steveklabnik 8y ago
  Depending on when "a while" is, it may be significantly different now. We've had at least two big releases that have shifted a significant amount of the ecosystem, and many smaller ones that have improved things too.
Sharlin 8y ago
Companies? Only 30% of respondents reported using Rust at work. Presumably a majority of Rust hobbyists use nightly and less so for those writing Rust for a job.
the_mitsuhiko 8y ago
We ship all stuff on stable but I regularly use nightly for local development to get extra features for debugging (for instance cargo expand is nightly only).
- dochtman 8y ago
  I think it works on stable these days.
  - steveklabnik 8y ago
    I don't believe so.

How/why are so many people using nightly as their rust version? Usually companies are conservative about jumping onto newer compiler versions.

by dman 8y ago

How/why are so many people using nightly as their rust version? Usually companies are conservative about jumping onto newer compiler versions.

the_duke 8y ago

At this point, I think it's mostly being used to it as nightly was more convenient for a long time. I've currently switched to nightly to use the 2018 edition changes already, which will soon be unnecessary. Almost all libraries work fine on stable now. (the new async/wait support is an exception, but it's still very experimental right now and not used by many) Important note: You can always develop on nightly and get potential speedups etc, but not use any features and then deploy only with stable.

cp9 8y ago

> When asked why they used nightly, people responded with a broad range of reasons including: access to 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm. as for how `rustup install nightly`

zellyn 8y ago

For a long time, there were really useful things that were available only in nightly, I believe. The Rust team has also done an unprecedented job of balancing stability and improvement.

steveklabnik 8y ago
Yes. Note that there’s also lag, this survey was taken much earlier this year. And so: > When asked why they used nightly, people responded with a broad range of reasons including: access to 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm. wasm, clippy, embedded, and proc macros aren't nightly any more. NLL, 2018 edition are coming soon. (December 6)

yoklov 8y ago

It's very easy to use nightly (install via rustup, then `cargo +nightly blah --args` instead of `cargo blah --args`), and there are (ugh, still) a number of somewhat popular libraries that require nightly versions of the compiler. In particular, using nightly allows you to opt-in to a number of experimental language features in exchange for maintenance burden. It's not a choice I make, although it's fun to do every now and then just to get a feel for what's available in the nightly builds.

beatgammit 8y ago
I've been able to find good libraries for everything I need on stable now that Diesel is on stable, so there's not really a requirement anymore to use nightly for most things. For example, I use actix, which works really well. It's not as ergonomic as Rocket, but it's way faster and quite useable. The same is true for pretty much everything I need, so I only use nightly when I'm dinking around with something that doesn't need to go to production anytime soon.
- yoklov 8y ago
  I think `async/await` is the big one for network stuff. Rocket is the library I was thinking of when I wrote that, though. My (possibly mistaken) understanding is that my coworkers who do more web servery stuff than me prefer actix to rocket for other reasons too, and wouldn't use rocket even if it worked on stable. I don't really know the arguments around them, TBH.
  - steveklabnik 8y ago
    The big one is that Actix is able to use async IO, but Rocket is sync.

StreamBright 8y ago

Companies using Rust are not too conservative I think. Conservative companies use Java or C++, or something similarly stable and easy to hire for.

ElBarto 8y ago
It's not really a question of being conservative but of being professional, I would say. Using unstable anything on production software is not professional, on mission critical software it is reckless incompetence.
- wongarsu 8y ago
  Depending on your testing and release process using an unstable compiler may not be a big deal. Unlike a webserver or a JIT you run the rust compiler once with your final product and can spend as much time as you want to verify the result.
  - ElBarto 8y ago
    But then the question is: what's the point? Any difference between production and dev/testing environments should be justifiable. Certainly in the last testing stage there should be no difference at all. Nightly builds of any software are only there to enable testing 'in the wild' of that software. There's no justification for any other use. Edit: The Rust community really needs to grow up...
    - dang 8y ago
      Would you please stop posting flamebait to HN? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - ElBarto 8y ago
        I thought I had posted constructive comments on this discussion. If discussing good software practices is "flamebait" that deserves to be downvoted, which was what my "growing up" quip was about, then I am at a loss as to what to do...

jcelerier 8y ago

I've seen some people gladly using nightly rust but restricting themselves with the GCC and CMake that comes with CentOS 6. The damage done by distributions shipping development toolsets is never-ending.

mroche 8y ago
There’s a DTS that ships Rust 1.26 (rust-toolset-7), however, it requires RHEL/CentOS 7. Red Hat’s been doing a pretty good job with providing newer toolkit’s through the DTS system, but some of them didn’t find their way to RHEL 6.
- steveklabnik 8y ago
  They also announced this recently: https://developers.redhat.com/blog/2018/11/20/support-lifecycle-for-clang-llvm-go-and-rust/ https://developers.redhat.com/blog/2018/11/20/support-lifecy...
kbenson 8y ago
> The damage done by distributions shipping development toolsets is never-ending. You say that, but we've already come out the other end of the period where linux was still on the upward swing of popularity and if a development toolchain wasn't as easily available a lot of software may never have taken off as quick. The ability to easily install a development toolset to compile (even if safely hidden behind a script to download and compile something like Ruby, Python, Perl, or a module for one of them) is a major boon, even if just used to create packages for the distribution's package system for local distribution (e.g. creating an RPM from spec). Given the choice between an easily installable default that might get old or no first party option provided, having a default available is vastly better. Blame companies for poor options they choose, not the people and organizations that do their best to provide even a single option.
jjnoakes 8y ago
The biggest reason (for me anyway) to restrict which gcc I use (and stick to the system-provided one) is so I don't need to distribute libstdc++ and libgcc_s with my program. The RedHat devtoolset was a nice solution to this (use a newer gcc version, but link to the system libraries), but if that isn't available, then building with the system compilers helps in this area. Rust doesn't have this problem when rust programs are statically linked, but if distros start shipping rust shared libraries which other programs start depending on, and/or some of the rust standard lib ends up in a system shared library, some of the same issues may arise (or maybe not, rust may have solved them in a clever way).

gpm 8y ago

Nightly isn't really as unstable as the name implies. Without invoking `#![feature(...)]` flags it's basically functions identically to stable. Sure, occasionally something breaks, then you type `rustup default nightly-<a date a few days ago>` and keep on chugging. Meanwhile you get access to more and better tools, which has no impact on the stability of your code base but a positive impact on productivity. It enables you to decide to bite the bullet and give up on language stability for new useful features if you want to (which I often do, for nll). So, what I do is develop on nightly, and make things I want other people to use work on stable.

jnbiche 8y ago
> what I do is develop on nightly, and make things I want other people to use work on stable. What do you do with the stuff you make on nightly? Use it only for yourself? Edit: oh, I think I see: you don't use any new features when you develop on nightly.
- steveklabnik 8y ago
  Some people use nightly to actually build, but don't turn on any nightly-only features. This means that they get early access to bugfixes and improvements, but don't actually restrict their users to nightly. (This may not be what your parent is talking about, but it is a use-case I've seen before.)
  - gpm 8y ago
    This is what I'm talking about.

johncolanduoni 8y ago

The biggest one for me is the async/await support for futures, which is not stabilized quite yet. In Rust it buys you not only the usual ergonomics, it also allows you to handle lifetimes in futures in ways that are basically impossible when using only combinators.

2trill2spill 8y ago

Some of the packages I use require nightly, Like the syscall crate and iirc I had to use the nightly compiler for inline assembly as well.

steveklabnik 8y ago
Yes, inline asm is still nightly only, and the syscall crate uses it. Incidentally, what do you use the syscall crate for? I'm very curious!
- 2trill2spill 8y ago
  Rewriting a system call fuzzer I wrote in C several years ago in Rust. I ran into many problems with the C version with memory management across multiple child processes. I figure rust would make the memory management much easier and it would be a great way to learn Rust. So far Rust is making the project much simpler and more robust, with similar performance to the C version.
  - steveklabnik 8y ago
    Neat! That sounds like a great use-case. Thank you :)
    - 2trill2spill 8y ago
      Yea when it's usable to people other then me I'll open source it. But so far it's FreeBSD only and I want to get Linux and MacOS support going as well.
      - jcranmer 8y ago
        You're using inline assembly for syscalls on FreeBSD? My recollection when I last looked into it was that FreeBSD only defined syscalls as C function calls, and did not have a stable ABI at the assembly level. (I was looking into it because I was trying to do system calls without having a stack page mapped as part of an assembly sandbox).

Tuna-Fish 8y ago

Right now, a lot of people want nightly (and [Rust 2018]) for NLL. It makes the borrowchecking system a lot more precise and less conservative, which in turn makes the language much less annoying to use. Using nightly as the compiler is much easier in Rust than, for example, using Python 3 early on was, because unlike, say, Python 3, nightly is fully backwards-compatible to earlier stable releases. (While not being backwards-compatible to previous nightlies.) This means it's easy to limit yourself to the features used in stable + one major change you want, and if there is no change to that major feature, you won't even notice all the instability of the compiler. There has been some hope of people moving to stable versions as NLL hits them, I think most people will always want the next big feature (personally waiting for const generics) on nightly, at least until the language is a lot more complete.

steveklabnik 8y ago
> Right now, a lot of people want nightly (and [Rust 2018]) for NLL. 9 more days!
- moosingin3space 8y ago
  NLL is stable in 1.31?
  - steveklabnik 8y ago
    For 2018 edition code, yes. 2015 will come later.
    - moosingin3space 8y ago
      I am incredibly excited for this!
cies 8y ago
> at least until the language is a lot more complete. Or used in larger projects. Or used in environments where (a) dev's prefs cannot be nightly.

hnbroseph 8y ago

when i was checking things out a while back, it felt like every interesting library required nightly. it was a significant turnoff. :\

steveklabnik 8y ago
Depending on when "a while" is, it may be significantly different now. We've had at least two big releases that have shifted a significant amount of the ecosystem, and many smaller ones that have improved things too.

Sharlin 8y ago

Companies? Only 30% of respondents reported using Rust at work. Presumably a majority of Rust hobbyists use nightly and less so for those writing Rust for a job.

the_mitsuhiko 8y ago

We ship all stuff on stable but I regularly use nightly for local development to get extra features for debugging (for instance cargo expand is nightly only).

dochtman 8y ago
I think it works on stable these days.
- steveklabnik 8y ago
  I don't believe so.