3 ms·
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 custo
by 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 agoDepending 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 agoRelated: https://news.ycombinator.com/item?id=23351145 https://news.ycombinator.com/item?id=23351145