There are a couple of fairly popular libraries that were nicer to use on nightly Rust (serde and diesel), but could otherwise work on Rust stable. The "nicer to use on nightly" is going away with the next stable release of Rust. Other than that, the vast majority of the ecosystem is on Rust stable.

Unfortunately "the next stable is the one you want" has been the story for quite a while now. Since this is ostensibly a thread comparing with go, I'll note that their story is more like "the next release will be better, but don't wait for it".

> Unfortunately "the next stable is the one you want" has been the story for quite a while now.

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.

> Unfortunately "the next stable is the one you want" has been the story for quite a while now.

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.

[1] - https://tip.golang.org/pkg/sort/#Slice

Yeah, I constantly ran into this when parsing JSON. I hope you are right and it will be over soon.

I consider libraries using a nightly Rust to be proofs of concept, not actually usable tools. This might be possible in the future, let's push these features to the stable Rust and maybe we could have this kind of libraries in the future.

I always use stable compiler. Never had a need for nightly.

The main blocker on stable was a feature called "custom derive" or "macros 1.1" which will be stabilized in the 1.15 release in February. At this point any library tied to a specific nightly is using some extremely cutting edge features.

It's not really scary.

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!

I feel like every other crate I've run into claims to require nightly.

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".

Please, if you see this, file an issue against the project, so we can clearly mark those crates as working on stable.

> most of them will work on stable in just a couple of weeks!

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.

> Until they don't again because clearly the authors have no interest in being on a stable

This is false, most uses of nightly are because of macros, which will be stable in the next version of Rust.

> Until they don't again because clearly the authors have no interest in being on a stable compiler release.

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.

1.0 was what, 1.5 years ago?

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.

Cargo doesn't require that you use things from crates.io without vetting them. It's possible to, say, write everything yourself, or only use specific crates that you've decided are good (whether that's by reading the source, or only using the ones published by the Rust developers, or some other criteria) and even go as far as explicit pinning to specific versions of them in your manifest (although this isn't particularly necessary: Cargo pins versions by default, and won't upgrade without you explicitly asking for it).

The problem really is that you have to vet them at all. With golang's standard library, it's all going to be supported to some degree. (I believe the same happens with rust's standard library, it's just much smaller.)

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.

We have the Rust nursery as a curated library set.

The crates published by the Rust developers themselves seem quite similar to the standard library for this purpose. (But, yes, things like this are not as discoverable as they should be; it is one of many things people are working on.)