6 ms·

> Make sure you have the right Rust compiler installed. Alacritty is currently pinned to a certain Rust nightly Ok, I'll... um not do that. Hope you publish a

> Make sure you have the right Rust compiler installed. Alacritty is currently pinned to a certain Rust nightly Ok, I'll... um not do that. Hope you publish a build soon though! edit: more seriously, the nightly compiler situation on rust is going to become a problem as it gets more developer use. I really hope they're able to stabilize it. edit 2: I'm really sorry if I derailed the conversation in a not useful way, @jwilm

kbenson 10y ago
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.
- Paul-ish 10y ago
  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.
  - steveklabnik 10y ago
    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.
steveklabnik 10y ago
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 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.
- llimllib 10y ago
  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.
  - steveklabnik 10y ago
    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!
  - dbaupp 10y ago
    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 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 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 https://blog.rust-lang.org/2016/05/13/rustup.html
a_humean 10y ago
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-roadmap-2017.md https://github.com/rust-lang/rfcs/blob/master/text/1774-road...
- eridius 10y ago
  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.
Manishearth 10y ago
Made a pull request to switch it almost completely to stable. https://github.com/jwilm/alacritty/pull/131 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!)

kbenson 10y ago

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.

Paul-ish 10y ago
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.
- steveklabnik 10y ago
  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.

steveklabnik 10y ago

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

llimllib 10y ago
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.
- steveklabnik 10y ago
  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!
- dbaupp 10y ago
  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 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 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 https://blog.rust-lang.org/2016/05/13/rustup.html

a_humean 10y ago

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-roadmap-2017.md https://github.com/rust-lang/rfcs/blob/master/text/1774-road...

eridius 10y ago
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.

Manishearth 10y ago

Made a pull request to switch it almost completely to stable. https://github.com/jwilm/alacritty/pull/131 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!)