Rustup automates this process so much that it costs you nothing to compile from a specific nightly release without compromising your existing configuration.

I downloaded the nightly within a minute, and I compiled a release within 125 seconds. Immediately after I changed back to stable. It took two cli commands to swap between. NPM couldn't get all my packages for my React crud app that quickly.

One thing that Rust really seems to be doing right is tooling whether it be Cargo's package and compilation management or Rustup's toolchain management, and their 2017 roadmap is pretty much entirely about tooling: https://github.com/rust-lang/rfcs/blob/master/text/1774-road...

You don't even need to swap back and forth. The README for Alacritty tells you to use `rustup override` to set the compiler, and rustup remembers overrides on a per-directory basis, meaning that invoking rust from anywhere outside the Alacritty working tree will still use your globally-configured default compiler.

Made a pull request to switch it almost completely to stable. https://github.com/jwilm/alacritty/pull/131

I didn't remove the dependency on proc_macro since that stabilizes in the next release and I'm lazy (if someone else wants to try, go for it!)

Looking at the code, it looks like this basically only relies on two things: inclusive ranges, and clippy. But you don't have to use clippy this way; it's just one way of doing it. So it's really one feature. EDIT: Oh oops, and custom derive, which is stable in a month.

> I really hope they're able to stabilize it

In general, "nightly" is never going to be stabilized. Remember, it's how Rust development works. Some people will always want to be on the cutting edge. I elaborated here: https://news.ycombinator.com/item?id=13277438

Also, nightly-only is less of a deal here, since this is mostly an application, not a library. End-users won't need to worry about having Rust at all.

My feeling is that having a lot of people running on different rust versions is likely to raise the bar to contribute to the project; for example if I go to hack on a python project the odds that I have to change my interpreter setup are basically zero.

In this specific example, I saw that building the project required mucking with my rust version/setup and decided that the cost of that was too high for me to proceed. Totally possible that I mis-evaluated the cost, but that was what happened in my head.

I don't at all mean to tell you what is best, I do think highly of your project and wish you all the success.

It is a little unfortunate, but Rust isn't blind to the problem. The community is converging on everyone using rustup (e.g. as of a few weeks ago, the install page recommends it https://www.rust-lang.org/en-US/install.html ) because it makes managing things like cross compilation[0] and upgrading stable compilers much easier. It also makes working with pinned compiler versions smoother: run `rustup override set nightly-2017-01-05` (or whatever date is recommended) in the project's directory, and that single command will both install that compiler and ensure it is used for the project (and only that project) when one invokes cargo or rustc. (I think it's great that Alacritty even helps people with the process, as I guess you noticed: https://github.com/jwilm/alacritty#prerequisites )

In any case, the nightly split is Rust deciding that it is good to allow people to use experimental features (i.e. working out if they're good/bug free) while also resisting infecting code that doesn't want to risk breakage---such projects use a stable compiler meaning even their dependencies won't be able to accidentally rely on something unstable---and thus hopefully avoiding defacto stabilisation of low quality features.

[0]: https://blog.rust-lang.org/2016/05/13/rustup.html

While it's nice that they want to converge on rustup, I greatly prefer using my distro-provided compiler in almost all cases. Right now that is rustc 1.14, which means that that alacritty is currently beyond my compilation capability.

I don't think this is nearly as bad as the grandparent suggested though. The language is young, I'd prefer experimental features remain in the experimental branch rather than get bad design stuck in the language.

I think if you're doing dev, it's completely reasonable to expect the dev to install a newer toolchain. Cargo makes all of the actually painful parts of contributing to a project pretty trivial.

Don't worry. The Rust community is sensitive to the desire to only install Rust with a package manager. There was even talk (a few days ago) of making an LTS version of the Rust compiler for use in more conservative distros that don't want to update it every 6 weeks.

On another front, Rust is working hard to get people off of nightly. This project, for example, uses 3 unstable features. Clippy can already work on stable (edit: code that is linted with Clippy can also build on stable in some setups), Custom Derive will be stable in less than a month, and inclusive ranges is a pretty minor feature.

I would expect this project to begin working on stable for Rust 1.15, but I'm not affiliated with it directly, that's just my guess.

> Clippy can already work on stable

No. But we plan to make it work.

Sorry Manish, I had meant that you can have code that can be built using a stable compiler while still using Clippy via another means. I typically use stable, but I run clippy on my code anyway. I realize that my post is confusing, I'll edit.

Ah, thanks!

> for example if I go to hack on a python project the odds that I have to change my interpreter setup are basically zero.

This doesn't match my experience at all - I frequently switch between projects that require python2 or python3, and I manage that using virtualenvs, which is a different problem than setup.py solves, just as rustup is separate from Cargo.toml

I have a lot of python experience and only a little bit of rust, but in my opinion the years-long python 2/3 split has been a lot more painful than the rust nightly/stable split... the fact that Rust produces binaries that work in any case vs. the user needing the right Python interpreter installed is a big part of this.

To be clear, this is not my project.

Yes, it is absolutely a barrier to contribution. That's part of the trade off a maintainer makes when choosing to use unstable features. It also means getting into distro packagers won't work; as they're all packaging stable only.

Most users are on stable, and with 1.15, the next release, the most used nightly feature is being stabilized. We're working on it!

> In this specific example, I saw that building the project required mucking with my rust version/setup and decided that the cost of that was too high for me to proceed.

Agreed it would be nice if you could compile it with your package manager's provided version of rust.

Sibling comments mentioned rustup; with it this is the entirety of the mucking required [as described by alacritty's readme, and confirmed by compiling it myself]:

    rustup override set $(cat rustc-version)

The override is local to the project of the directory you set it in. This will also download that version of rust if necessary.

Rustup makes it painless, though. I have a ton of versions of Rust installed. I use different versions for different projects. Some versions I just tested to find where the performance regression was, so I could just remove them, but they don't bother me.

Just for completeness, there is one other major unstable feature that Alacritty requires. #![feature(step_trait)].

I forget the precise details, but I believe this was required for using newtype wrappers as a `Range` for indexing. Specifically, the grid can be indexed as a range like

    grid[Line..Line]

I'm sure it can be replaced by custom trait work, though.

Using nightly for a single build and going back to stable for regular work is not hard. It's a command or two to build and switch, and a command to switch back.

Using nightly rust to build a project in development to check it out is like using a beta release of a library to build a project to check it out. In both cases, you expect that it will likely be using stable dependencies in the future, and you can still take a look now.

It seems like the Cargo.toml file for binaries should be able to specify this, and cause the crate to be built with the nightly if it is installed. This way you only have to enter cargo build --release.

Cargo isn't in charge of selecting what rustc you use; that's the job of Rustup.

In general, _some_ feature like this is desired; nobody has put in the required work yet.