3 ms·

Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind f

Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind feature flags/language pragmas, but it seems like a massive looming risk.

jph 6y ago
Developing based on Rust nightly has caused some learning curve gotchas, such as discovering a POSIX bug in the Rust install script, or needing to write a custom Docker Alpine Rust nightly container, or needing to write small system scripts to ensure that nightly is the same version on our various build machines. So far we've seen about 2/3 of nights fail for our code. The failure is totally obvious. So we revert to the previous night that we know works.
- estebank 6y ago
  Depending on the level of maturity of the nightly features you rely on, for CI there is an env variable that makes the stable compiler think it is nightly. We use this flag at day job to use latest stable but be able to enable a handful of quasi stable nightly features (custom testing frameworks mainly and getting rocket to play nice). This is a double edged sword: it is the same as a pinned nightly in the sense that it is a static target, but differs in that bugs affecting stable and beta have been backported where any arbitrary nightly has no assurances one way or another, but bugs affecting nightly features aren't backported to the stable release and only fixed on nightly. Also, for the love all that is holy do not publish a crate relying on that flag to enable the nightly features, it breaks the languages stability assurances and by extension the ecosystem.
  - zozbot234 6y ago
    Related: https://news.ycombinator.com/item?id=23351145 https://news.ycombinator.com/item?id=23351145
kibwen 6y ago
Not that as of Rust 1.45, coming out this Thursday, Rocket will be able to target stable Rust: https://github.com/SergioBenitez/Rocket/issues/19#issuecomment-630650328 https://github.com/SergioBenitez/Rocket/issues/19#issuecomme... I believe Diesel has been on stable for a long time now, so for this use case I don't think anyone will need to worry about using the nightly releases.
- thepratt 6y ago
  That's good news! Wasn't aware of the pin change for rocket.
  - estebank 6y ago
    One more thing: I build my final binaries with stable (when possible), but develop with recent a nightly. There are some features that require nightly (custom testing frameworks come to mind) but don't affect the final binary (only tests) and I get the new goodies (better diagnostics, speed bumps, fixes) up to 12 weeks ahead of schedule. Rustup makes having nightly and stable in the same machine painless, and I got in the habit of running cargo +stable build and cargo +nightly test. BTW, you don't have to do this, it just makes my experience a bit nicer.
adsjhdashkj 6y ago
Not OP, but: It does not for me, fwiw. However we release often, so i'm not releasing a binary into a distributed ecosystem where i expect it to live for years and years. In that scenario i would be wary of non-stable, since a looming issue in nightly could persist for an uncontrolled amount of time. However thus far we have never had to push a release due to a bug found in nightly. We also have never had a build break because of nightly, or even upgrading. The only breakage i'm aware of was, oddly, a semi-recent Rustup change. Our CI was not pinning the Rustup version, and the argument defaults changed so the downloaded Rustup did not have the components needed for our CI setup. We will however migrate to stable once Rocket becomes stable. Thus far however, we've not had any trouble on nightly. I can only assume this is a result of the Rust teams excellent QA/tests/care/etc, combined with the language itself being very easy to write error-free code.

jph 6y ago

Developing based on Rust nightly has caused some learning curve gotchas, such as discovering a POSIX bug in the Rust install script, or needing to write a custom Docker Alpine Rust nightly container, or needing to write small system scripts to ensure that nightly is the same version on our various build machines. So far we've seen about 2/3 of nights fail for our code. The failure is totally obvious. So we revert to the previous night that we know works.

estebank 6y ago
Depending on the level of maturity of the nightly features you rely on, for CI there is an env variable that makes the stable compiler think it is nightly. We use this flag at day job to use latest stable but be able to enable a handful of quasi stable nightly features (custom testing frameworks mainly and getting rocket to play nice). This is a double edged sword: it is the same as a pinned nightly in the sense that it is a static target, but differs in that bugs affecting stable and beta have been backported where any arbitrary nightly has no assurances one way or another, but bugs affecting nightly features aren't backported to the stable release and only fixed on nightly. Also, for the love all that is holy do not publish a crate relying on that flag to enable the nightly features, it breaks the languages stability assurances and by extension the ecosystem.
- zozbot234 6y ago
  Related: https://news.ycombinator.com/item?id=23351145 https://news.ycombinator.com/item?id=23351145

kibwen 6y ago

Not that as of Rust 1.45, coming out this Thursday, Rocket will be able to target stable Rust: https://github.com/SergioBenitez/Rocket/issues/19#issuecomment-630650328 https://github.com/SergioBenitez/Rocket/issues/19#issuecomme... I believe Diesel has been on stable for a long time now, so for this use case I don't think anyone will need to worry about using the nightly releases.

thepratt 6y ago
That's good news! Wasn't aware of the pin change for rocket.
- estebank 6y ago
  One more thing: I build my final binaries with stable (when possible), but develop with recent a nightly. There are some features that require nightly (custom testing frameworks come to mind) but don't affect the final binary (only tests) and I get the new goodies (better diagnostics, speed bumps, fixes) up to 12 weeks ahead of schedule. Rustup makes having nightly and stable in the same machine painless, and I got in the habit of running cargo +stable build and cargo +nightly test. BTW, you don't have to do this, it just makes my experience a bit nicer.

adsjhdashkj 6y ago

Not OP, but: It does not for me, fwiw. However we release often, so i'm not releasing a binary into a distributed ecosystem where i expect it to live for years and years. In that scenario i would be wary of non-stable, since a looming issue in nightly could persist for an uncontrolled amount of time. However thus far we have never had to push a release due to a bug found in nightly. We also have never had a build break because of nightly, or even upgrading. The only breakage i'm aware of was, oddly, a semi-recent Rustup change. Our CI was not pinning the Rustup version, and the argument defaults changed so the downloaded Rustup did not have the components needed for our CI setup. We will however migrate to stable once Rocket becomes stable. Thus far however, we've not had any trouble on nightly. I can only assume this is a result of the Rust teams excellent QA/tests/care/etc, combined with the language itself being very easy to write error-free code.