We had a production user call yesterday and found a little problem with the train model: it makes it easy to have our hands in the cookie jar that is nightly, because all of its features might be released “soon”.
I’ve got a little hobby: porting libraries that have the sentence “compiled on recent nightlies” in their README to stable Rust. In my experience, these changes are often pretty minor: for example, the
path_ext features are often used, but only to use one of their methods that is still into staging. Porting to stable is often just the work of having a look at the implementation of the unstable feature, port it over in some way and then run on stable.
We should - as a community - get used to using stable unless you do things that definitely need future nightly compiler infrastructure (e.g. for cross-compilation and embedded things). Especially, we shouldn’t ignore stable for things that are perfectly fine to be implemented in stable Rust, just for being a little less convenient. Also, finally, performance reasons are also not a good one: having a more efficient implementation for something available in a feature-gated API means that Rust stable just isn’t there yet - implementing something efficient and fast on top of that should always be seen as something not ready for the general public, but only for testing purposes - a toy, basically.
Stable gives a lot of guarantees and is what production users want to use - we should make sure that it is the baseline we implement against. It makes the work of those trying to propagate the language easier and makes sure Rust fulfills the guarantees it wants to give.