FWIW, the stable release purposely having this functionality removed is pretty annoying. Using periodic versioned releases is much nicer than sporadic snapshots (I've avoided the issue by not mucking with STM32 stuff in a while). A flag like #![use_unstable_features] would be friendlier.
The stable release does not have functionality removed, only deprecated. As in, this functionality was never present in a previous stable release, and now is.
Sure, but the functionality was present back when snapshots were the only game in town. I'd hope progress to versioned releases meant that users could make their life easier by using them rather than having to stay using snapshotted nightlies.
I'm glad now libraries are at least supported, which is good enough for my purpose (linking done with gcc, no idea if that's still state of the art for rust-on-stm32 or what), but it had been an annoyance. But I believe procedural macros are still in the same boat.
Somewhat tangential, this is the kind of blind spot encouraged by the rustup.sh degeneracy.
When snapshots were the only game, it was all unstable. There's no difference from today.
EDIT: sorry, it seems I've mis-read you. I get it now. Unfortunately, we have a strong compatibility story, and so must take strong measures to enforce it. You can use the nightly released on the same night to get a build that's like a particular stable, but allows features.
> Unfortunately, we have a strong compatibility story, and so must take strong measures to enforce it. You can use the nightly released on the same night to get a build that's like a particular stable, but allows features.
Unfortunately, the crates.io system does not follow the same policy, and crates regularly require feature flags.
Yup! The majority of crates do build with stable, but many require features. We've been talking about a way to expose this in the UI so you can tell, but it's slightly more complex than you'd think at first, and nobody has put the time in yet.
Sure, that is simply stating a different way. With the resulting implication that if one wants procedural macros, the stable 1.x releases have unfortunately been empty progress.
Breakage from forwards-incompatibility isn't my problem, it's potentially having to tackle it every morning rather than in batch mode when there's a new release.
edit: If this compatibility story really dictates that releases can't contain beta features, even with a #![unstable_beta_features_1_6] directive, then a separate beta release would be nice. But now it looks like I'm asking for something additional.
Oh yeah, forgot about that. Different purpose than what I'm talking about though. Perhaps mine would be more appropriately named "1.6 with alpha features".
I think the issue here is the difference between "is" and "essentially". Having a guaranteed matched release with alpha features would apparently be useful, for at least one person. Not being guaranteed could cause some real headaches under certain circumstances.
What are those circumstances? There are no stability guarantees for unstable features, so I don't see how a nightly build that happens to correspond to a major version has value over any other nightly build. The stability you would get by sticking to "1.6 + features" seems precisely equal to the stability you would get from picking a recent nightly and sticking to that build.
It sounds to me like the real issue here is that procedural macros aren't stable, not anything about the release process.
Stabilizing procedural macros would fix this one issue, but IMHO a different release process would have fix the pain as well. My case specifically:
Wanting hard-to-stabilize features like procedural macros and no_std.
Using external dependencies that work with stable, but when used with unstable they expect you are updating nightly.
Not updating nightly due to a wacky idea that people should control tools and not vice-versa. The first time I open a project in a week is not the time I want it to fail compiling due to language/library changes.
Maybe my impression is caused by the previous rapid change of nightlies (renaming in libraries, etc), and using month-old snapshots wouldn't be too bad these days. But still after several major releases I'd hope the stable tarballs would have been suitable for general use.
Instead of removing not-yet-stable features, they should be put behind a feature gate. With the idea that anybody who explicitly opts-in to unstable features and then complains when they're not forward-compatible can simply be told to pound sand.
By complaining that when you update nightly you have to update your code that uses unstable features, you are in effect asking us to stabilize everything. Unstable means unstable.
> ith the idea that anybody who explicitly opts-in to unstable features and then complains when they're not forward-compatible can simply be told to pound sand.
This never works in practice. We'd have too many crates that depended on nightly features. There would be 10x the number of complaints here on HN if we did what you suggested and enabled unstable features on stable. The only option would be to de facto stabilize everything.
Again, it really sounds like your complaint is just that procedural macros aren't stable. I'm sorry they've taken longer than you wanted to finish, but we have lots of work on our plate.
> By complaining that when you update nightly you have to update your code that uses unstable features
This isn't it. I feel like, when using unstable, that I've had to update packages that would not have needed updating were I using stable (and still would have worked fine). Maybe I just got a bad impression and switched away from nightlies around the time wider-demanded features started to stabilize.
> Again, it really sounds like your complaint is just that procedural macros aren't stable.
No, this really isn't it. I fully expect that code using unstable features is going to require changes when I update. I think the root of my gripe comes about from intermediate versioning being punted to "just run nightlies", meaning that rather than being able to reference older versions of packages that work with my compiler version, I'm effectively forced to upgrade and create breakage in my code right then.
> I'm sorry they've taken longer than you wanted to finish, but we have lots of work on our plate.
Please take whatever time is required to get them "right". And thank you in general.
But a new nightly shouldn't be breaking stable features, only unstable ones. That's why I'm confused as to why upgrading nightly could possibly break packages, aside from changing unstable features, which you shouldn't be using if you want stability.
I'm trying to remember/piece together what happened.
I believe I added a dependency that wouldn't compile with the snapshot I was running (10JUL2015?). So then I updated to a new snapshot (14AUG2015?), and a previous dependency would no longer compile (since it hadn't been updated). I think this could have been due to libc changes, which I guess were marked unstable (and this was the result of them being removed from the main rustc distribution?). I did some manual tweaking, and/or the problem fixed itself in a few days.
I next came back to rust a few months later, where after that experience, I went ahead and updated to the 1.4 release. I figured libraries should generally aim to keep working with numbered releases, regardless of the upgrade treadmill. I guess (in your framework) that's applying unstable expectations to numbered releases, which is what I've been doing this whole thread - I don't care that code will break at future point, but I do desire consistency in the meantime!
I was next surprised to find out that the syntax extensions for eg serde were used completely differently with the numbered releases because procedural macros were disabled (I hadn't yet touched my own projects that use procedural macros or libcore).
The snapshot story is probably better these days, given that libraries should be more stable. It has always been annoying feeling like my rust is continually "out of date" and dependencies could break and require me to update, involuntarily breaking my code. This has been a problem all along, and I had hoped it was over with numbered releases. Alas.
From my perspective the main source of pain is that rust eschews having traditional numbered unstable releases. Instead creating a harsh dichotomy between uber-stable releases and uber-changing snapshots. One can alleviate some of that pain only if they're willing to take the web 2.0 give-up-control-of-your-computing plunge and run eg rustup.sh, which of course helps the fundamental problem to persist. Granted, the problem will be moot as rust libraries become more stable and the stable distribution becomes more featureful. We're apparently just not there yet for my purposes.
Cuil, a downvote for detailing my perspective? I only bring up this meta issue because it's another symptom of the same problem.
If one is onboard with the butt model of constant updates, then of course my problem looks odd and self-imposed. But such assertions that one's own perspective is universal is a source of many of the world's problems.
> By complaining that when you update nightly you have to update your code that uses unstable features, you are in effect asking us to stabilize everything.
No, I think the point is to just have a specific unstable that corresponds to a specific stable as closely as possibly, and designated as such., Conceivably crates that needed unstable features, but not bleeding edge, could require at least that unstable release, while others that really need bleeding edge features could use nightly. The issue here is that your release procedure treats unstable features differently than everything else, making any crate or code that wants to use any unstable feature resort to using a nightly of some sort. Admittedly, I can see reasons why this might be by design.
You might have good reasons why you think that won't work or be useful (I can think of a few, such as not wanting to promote people building on a specific implementation of an unstable feature). At a minimum, it is at least slightly more work to make sure this new item is released, depending on the release process.
P.S. The prevailing wisdom so far when wanting to use unstable features from a point release is to use a nightly form the same day, but the release policy seems to indicate that the nightly from that time is actually two release versions ahead of the stable that was released the same day:
> This process happens in parallel. So every six weeks, on the same day, nightly goes to beta, beta goes to stable. When 1.x is released, at the same time, 1.(x + 1)-beta is released, and the nightly becomes the first version of 1.(x + 2)-nightly.[1]
I'm a bit unclear on what the best thing to do would be if I wanted to use features from something that is as close as possible to a particular stable release.
I had the same response when I realized a feature I really wanted was only on nightly (and would probably still be interested). However, in the last month-ish I've been using a fresh nightly every day, multirust has made it super easy to update, and I've only had breaking changes to my dependencies once.
I only switched to building releases at 1.4 because I thought the nightly treadmill could finally be over. Alas I guess I'll skip installing 1.6 and just switch back to sporadically-updated checkouts whenever some dependency has breaking changes (ooh, such stable).
I'm not looking to get the rats on my face and switch to butt-based development ala rustup/multirust/etc.
Really? Last time I checked it still didn't work. Will have to try when I get home.
The problem was that the config is compiled into a dynamic library and gets passed the config struct. The old alloc method kind of died on me when the dynamic library was trying to alter that struct. So I had to enable jemalloc to keep it from crashing.
Hmm. Yeah, I mean, jemalloc is the default allocator, so something must be wonky here. You don't need to explicitly use jemalloc. That's what you get by default.
Quite the opposite; jemalloc has been the default, and using the system allocator has been the "hassle" since well before 1.0.
However a few key platforms have jemalloc disabled because it's buggy (deadlocks or worse). I think as of a few days ago it's pretty much universally off on windows.
Also whether jemalloc is used depends on how you build your thing -- dylibs use the system allocator (because they're subordinate), static libs (rlibs) inherit from the thing they're linked into, and executables use jemalloc (because they're in control).
