I don't recall anyone ever saying this, where "the one you want" means "the one that supports procedural macros".
We have had this discussion for a very long time, and it has always centered around serde and diesel. Those have been the biggest nightly users since 1.0, and probably before then.
Not really. serde and diesel have been more convenient on nightly for a long time now. It is only just now that we can say the "next stable" because that's when the particular feature they need will be stable.
> I'll note that their story is more like "the next release will be better, but don't wait for it".
I can't wait to use Go's `sort.Slice` function[1], but I'll have to wait for the next stable release.
Seriously though, I'd say the key difference between Go and Rust on this venue is that while Rust is stable, there's still more stuff we'd like to add. To that end, we encourage experimentation by making the acquisition of a nightly Rust compiler really easy. This naturally leads to people experimenting with nightly and publishing crates that either use it or require it. This is a necessary part of experimenting with new features and getting feedback.
Go's scope for experimentation is much smaller. Their changes are much more incremental and conservative. It's a really nice benefit of using Go.
My point is: this is a trade off and it should be presented as such. In Rust land, it requires that you---the user of Rust---ignore crates that require nightly or ignore features of crates that require nightly.
I always use stable compiler. Never had a need for nightly.
Very few projects require nightly features and of those that do, most of them will work on stable in just a couple of weeks!
Plus you can easily switch between versions with rustup!
In reality, they often work perfectly fine on a reasonably-modern stable, and simply haven't updated their documentation and READMEs to indicate "oh yeah, this nightly feature is now in stable, so just use a stable that's newer than version so-and-so".
Until they don't again because clearly the authors have no interest in being on a stable compiler release.
> Plus you can easily switch between versions with rustup!
I don't think people are complaining because switching versions is hard. Just unnecessary, risky, and yes kind of annoying.
This is false, most uses of nightly are because of macros, which will be stable in the next version of Rust.
Then use an older version of the package. Unless the package in question was relying on some "nightly" feature that never made it into stable, then you should be fine.
I'm not convinced the problem will just go away. Not as long as people are obsessed with the new hotness language features that require a compiler from the tuesday before last.
Cargo also makes me wary. How do I know what I'm choosing is any good, and if it is will it still be around next year. Nature of 3rd party libs I guess.
Basically, some people like having a curated library set; others do fine without and are happy to find things to use. The former set doesn't like rust as much in its current state.
All the libraries I have needed for my projects in Rust support stable. Maybe shortly after 1.0 some people were not playing by the rules yet.
The only exceptions I've found are some truly elite macro things and stuff to support code generation.
This is compiler version pinning. At least .toml files don't support that. Yet.
The "namespace hack" in Rust is having the "stable" namespace: a compiler that rejects all unstable code (and is forward compatible), so that people don't accidentally get pinned.
If someone wants to pin to a specific development version (of anything), there's nothing the project can do about that, other than being closed source and only publishing stable artifacts. Tooling like rustup that makes it easier to pin means that people who choose to experiment can still use stable by default (easy to switch back) and that others can easily collaborate on the experiments, both of which seem like strict positives.
I went through a similar experience in Haskell. It is worth going through until you get to the point where it is no longer a wrestling match, because then you are just as productive but any code you write is checked much more thoroughly than in a more weakly typed language.
> Fuck. This. Noise. I'm not learning a language where every project requires a separate compiler.
I guess just wait until it stabilises then.
Which is when? 1.15? 1.50? 2.0?
What was the point of that whole "1.0" thing?
This is a rhetorical question, as there's no way you've been around here so long without knowing what it is. For everyone else, however, the notion is that code written for 1.0 will continue to work for additional 1.x releases. It says nothing about iterating on not-yet-baked features--that's what nightly is for, and as they become baked they become part of 1.x releases. They're not breaking backwards compatibility; the major version remains the major version.
Very few projects require the nightly compiler and fewer still a specific version of it, but rocket is highly experimental and kind of a special case.