If stable and beta used PGO and nightly didn’t and was consequently 10–20% slower, then there would suddenly be an actual reason to not use nightly! I’m not sure whether that would be good or bad.
There are multiple reasons to avoid nightly. One of them is that you don't have to constantly rebuild the entire graph when you want to stay up to date because stable is "only" updated every 6 weeks. Another being that you are less subject to regression bugs hitting you.
You can "only"update nightly every 6 weeks as well, or every 6 months. Nothing says you have to stay up to date.
In practice I update when there is something I want in a more recent release. This happens more often with nightly because there are more bugs to be fixed and feature changes, but it isn't that often.
The problem I’ve found with working on nightly is that APIs and certain impls of features you might rely on are constantly in flux. This ends up requiring you to pin to a specific nightly build date. And then the ecosystem that might also be relying on night starts to shift, and all the sudden you don’t have a stable build anymore.
I never experience that on stable, and it’s been my primary reason for not recommending Rocket for so long, even though that it’s an excellent library in all other regards. (I believe it’s working with stable in the master branch at this point, and just waiting on a release of 0.5).
Yes, this is an issue, I avoid it by making it a rule for that either I nightly features and none of my dependencies do, or at most one of my dependencies do and I do not.
And if you find a bug? If it's in a recent nightly or a stable release, you can rightfully file a bug. It will be either fixed on master or a point release will be made. If your nightly is weeks old, you don't really know whether master has fixed it weeks ago or a bug report would be welcome. So you lose this advantage.
Anyways, that's not an exhaustive list. Not wanting to deal with rustup might be another reason so you use your distro rustc packages instead.
Finding a compiler bug is rare... but when I do being on an old nightly tends to speed up the reporting process. That's because this is the process
1. Search the bug tracker for the message/symptoms. If you find the bug (more likely on older nightly's) stop here.
2. Create a minimal test case by creating a copy of the code and then deleting large portions of it until you have a dozen or so lines and no dependencies that reproduce it and are all needed to reproduce it.
2.5. If using an old version of rustc, `rustup override set nightly` to use a recent nightly on this directory and see if the bug is gone/changed. This takes about 30 seconds (compilation is instantaneous since I've already deleted all but a dozen lines of code).
3. Search the bug tracker again now that we have a better idea what is going on.
4. If there really is nothing, report it.
The time savings by bailing out early at 1. greatly exceed the time cost introduced by 2.5.
If you're using nightly you should be using rustup... but since rustup is so easy to use that's a very very low cost.
