3 ms·
I suspect what OP is referring to is the fact that it's just hard to avoid Nightly entirely, even if you don't need the new features. All it takes is that one
by atombender 8y ago
I suspect what OP is referring to is the fact that it's just hard to avoid Nightly entirely, even if you don't need the new features.
All it takes is that one library you want to use requires Nightly. Since Rust adds features all the time, it's not uncommon for library authors to start using these features before they're in Stable. It's just the nature of a young language with an active community who likes being on the bleeding edge.
This also extends to the toolchain; it's not that long ago that RLS and Rustfmt were still Nightly-only, for example.
The presence of Nightly alone gives you a choice that usually doesn't exist with other languages. Not too long ago I went down the rabbit hole with some text stream stuff (Unicode is surprisingly poorly supported in places), and ended up with a temporary workaround because the std::io::Chars API wasn't in Stable yet and I just didn't want to deal with Nightly. But it was tempting. With other languages such as Go, the choice generally isn't there, even though you could theoretically download HEAD and go from there.
- burntsushi 8y agoIt's not hard to avoid nightly at all. I've been targeting stable Rust in all my applications and libraries since Rust 1.0 was released. The only exception is adding a new nightly-only feature, but always gated behind an Cargo feature. This is a classic case of our standards of success continually moving, and that some domains are better suited to stable Rust than others. For example, if you want ergonomic async/await, then you need to use nightly. But otherwise, the number of crates needing nightly has shrunk enormously over the last few years. > it's not uncommon for library authors to start using these features before they're in Stable I would say this is actually pretty uncommon.