5 ms·

I'm totally fine learning the borrow checker. It's a investment I see value in. Even if it's just in me learning about solid rules for sharing variables. But th

I'm totally fine learning the borrow checker. It's a investment I see value in. Even if it's just in me learning about solid rules for sharing variables. But that nightly shit you describe is scary as fuck and makes me very concerned about the future of the language. Post 1.0 this shouldn't be an issue!

pimeys 10y ago
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.
tatterdemalion 10y ago
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.
burntsushi 10y ago
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.
- ajmurmann 10y ago
  Yeah, I constantly ran into this when parsing JSON. I hope you are right and it will be over soon.
- tedunangst 10y ago
  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".
  - pcwalton 10y ago
    > 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.
  - burntsushi 10y ago
    > 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 https://tip.golang.org/pkg/sort/#Slice
AsyncAwait 10y ago
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!
- serge2k 10y ago
  > 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.
  - AsyncAwait 10y ago
    > 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.
  - lomnakkus 10y ago
    > 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.
- yellowapple 10y ago
  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".
  - moosingin3space 10y ago
    Please, if you see this, file an issue against the project, so we can clearly mark those crates as working on stable.
serge2k 10y ago
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.
- dbaupp 10y ago
  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).
  - mook 10y ago
    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.
    - dbaupp 10y ago
      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.)
    - pcwalton 10y ago
      We have the Rust nursery as a curated library set.

pimeys 10y ago

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.

tatterdemalion 10y ago

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.

burntsushi 10y ago

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.

ajmurmann 10y ago
Yeah, I constantly ran into this when parsing JSON. I hope you are right and it will be over soon.
tedunangst 10y ago
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".
- pcwalton 10y ago
  > 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.
- burntsushi 10y ago
  > 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 https://tip.golang.org/pkg/sort/#Slice

AsyncAwait 10y ago

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!

serge2k 10y ago
> 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.
- AsyncAwait 10y ago
  > 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.
- lomnakkus 10y ago
  > 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.
yellowapple 10y ago
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".
- moosingin3space 10y ago
  Please, if you see this, file an issue against the project, so we can clearly mark those crates as working on stable.

serge2k 10y ago

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.

dbaupp 10y ago
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).
- mook 10y ago
  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.
  - dbaupp 10y ago
    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.)
  - pcwalton 10y ago
    We have the Rust nursery as a curated library set.