Hacker News Reader

Comment by dman | Hacker News Reader

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

View on HN

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.

> Right now, a lot of people want nightly (and [Rust 2018]) for NLL.

9 more days!

NLL is stable in 1.31?

For 2018 edition code, yes. 2015 will come later.

I am incredibly excited for this!

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

What's a "large project" to you, incidentally?

We know of several codebases that are over a million lines. To some people, that's big, and to many, it's not.

(Note also that this data shows a majority of people do use stable.)

> To some people, that's big, and to many, it's not.

This boggles my mind, so I have to ask, who considers a million lines of code in a code base not a large project? I mean, sure there are plenty of projects larger than that, but when considering whether a project is large or not, I think I would consider a million lines of code well into the "large" category.

As with most things, people's experience is colored by their previous experience. There are people who work on 10MM LOC codebases that say "oh well you don't even have one of those", or for example, take Google's C++ codebase, which last I saw is estimated at something like 2 billion lines? Yes, that's a bunch of small projects, but since it's in a monorepo and uses one big build system, to people thinking about scale, they consider it one, or so I've heard.

Add in a general sense of bragging rights, and well, I've heard people say "call me when you have a real project" about more absurd (to me) things than just this in the past...

Maybe I should have said "used in large project more often"

> (Note also that this data shows a majority of people do use stable.)

Well, that kinda proves my point then, right?

> What's a "large project" to you, incidentally?

It's more that the larger the project (either in code or number of devs working on it), the more tool-stability becomes a requirement. Just my experience, and it is quite understandable.

Ah, cool, thanks :)

In case anyone else was wondering what this jargon meant, "non-lexical lifetime":

https://github.com/rust-lang/rust/issues/43234

Took me a bit of websearching to figure out what people were excited about.

Good call, thanks.

Additionally, even that is kind of jargon. The simplest answer is “the borrow checker will allow some kinds of code that is sound, but the previous borrow checker could not understand that it was sound.”

I see that NLL makes the borrow checker easier to work with for developers, but does NLL actually change when objects will be dropped at run-time?

NLL does not affect things that implement Drop. This is called "eager drop", and while it would only affect unsafe code, we deemed it to be too likely to cause problems with said code. Even though it's unsafe, we don't want to make that even harder to understand.

That makes sense. A developer writing unsafe code can more easily and clearly control their drops by introducing new scopes than deciphering where the eager drop happened.

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.

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

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

This is what I'm talking about.

> 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`

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.

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.

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.

Yes. Note that there’s also lag, this survey was taken much earlier this year. And so:

wasm, clippy, embedded, and proc macros aren't nightly any more. NLL, 2018 edition are coming soon. (December 6)

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.

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!

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.

Neat! That sounds like a great use-case. Thank you :)

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.

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

While this is true (Windows is another example), that doesn't stop people from doing this. It's how Go works most of the time, for example.

The majority of system calls are going through the syscall crate, but system calls not yet supported by the syscall crate are being called with assembly directly. However going forward I plan on just updating the syscall crate so it supports newer system calls and make a pr into the syscall repo, instead of manually calling system calls with assembly.

I believe you’ll have to fork the crate, the owner of it no longer programs in Rust.

They may also be willing to hand it over to you, I don’t know.

Any reason you can't use libc::syscall?

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.

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.

They also announced this recently: https://developers.redhat.com/blog/2018/11/20/support-lifecy...

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

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

It's not the end of the world for distros; they pick a single Rust version, and so shared libraries work for them.

They do need to recompile the world when they update the compiler, but it's a single recompile each time.

Right - and so you get same situation that you have in C++-land (if I'm understanding you correctly) where compiling arbitrary rust programs with the distro compiler level may benefit you if you want to depend on the system-provided rust shared libraries.

Yep.

DLL hell on Linux.

Not really; there's a few substantial differences between shared objects with SONAMEs and link-time vs run-time file system names and LD_LIBRARY_PATH and /etc/ld.so.conf vs DLLs and searching PATH (starting with ".").

I don't know much about modern Windows (SxS, etc) so things may have improved there, but last I looked (a while back admittedly) DLL hell and shared object issues were in different leagues.

Well, I might have misunderstood the original problem.

>so I don't need to distribute libstdc++ and libgcc_s with my program

Could you explain why you want to avoid that?

That's because the libraries come from the same source and work together. Rust/cargo is it's own little universe ignoring the rest of the system.

That's mostly because those two are stable, and there is near to no gain on going into the bleeding edge. When people gain something from an upgrade, they do it.

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

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.

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.

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.

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.

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.

The big one is that Actix is able to use async IO, but Rocket is sync.

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

I think it works on stable these days.

I don't believe so.

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.

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

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.

Reply on news.ycombinator.com