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.