I was just taking a look at the roadmap RFC again, and I was wondering what features/breaking changes we are planning to do for the proposed edition (or if we have settled that we want an edition). Is there a list of things that we want to complete by October supposing we do an edition?
I am not aware of any concrete proposals yet.
IIRC, there were some things that were being marked as deprecated in various areas; are they now old enough that it is time to remove them? The coffee hasn't kicked in yet, so I can't remember (or even properly search for) the things people were talking about removing.
BTW, I think (can't find the discussion, so I may be making this up) that it was decided that the deprecation life cycle was that anything that was marked deprecated in an edition would remain through the next edition. Thus, only things marked as deprecated prior to the 2018 edition being released could be considered for removal in 2021.
And, yes, I believe that we should have a 2021 edition. My personal belief is that a 3 year edition cycle is a good fit for Rust's train schedule model of development, and that we should stick with it. It makes planning for the future easier.
If there's going to be a next edition, be super careful about communicating this.
There's been "I can't keep up with idiomatic Rust" article making rounds recently. The response to this article from people who don't use Rust has been that they perceive Rust as releasing too much to fast, being too complex, and growing even more complex (which IMHO is an inaccurate view, but nevertheless it's becoming a meme).
Edition 2018 also caused confusion by advertising features developed that year together with the new edition flag. This has created an impression that "Rust 2015" and "Rust 2018" are different languages, with different feature sets.
I'm worried that outsiders who don't read Rust's release notes, and only skim the headlines will misinterpret any next edition, no matter how trivial, as Rust "changing everything again", and blow this out of proportion as there being three different incompatible Rusts to learn.
Personally, I share this concern very strongly, and I think it's a general perception of a lot programming languages these days, moat notably c++ and java.
I'm seeing that current consensus seems to move towards "Rust isn't really changing fast, it only looks like that to some". But is it possible that changing fast or slow is not an absolute, and that for some Rust truly is changing fast?
BTW I feel Java is changing horribly fast too. And C++. Keeping up is really not an option.
What do we do there in the trenches? We're using old editions. We're using Java 1.8 and I heard a neighboring project is using C++ ver 11 or smth like that
I feel like we're on the verge of snowballing into something unproductive here, when the language team hasn't even had their meeting about a possible edition yet. The perception of change is certainly relative, but it involves way more than just editions.
Personally, all I want to say about editions before some sort of official language team statement is this:
Please seriously consider not having an edition at all. I don't have a strong opinion either way on whether we should have one, but I'm on the fence about it, and I'm seeing a lot of talk that just assumes we will have one without consideration.
The circumstances right now are very different from 2018. In particular, I believe "editions" are largely perceived as a mechanism to enable breaking changes, and unlike 2018 we don't seem to have any "interesting" breaking changes to make right now (as opposed to removing deprecated stuff). I know the Rust blogosphere and language team communications have often presented epochs/editions as being at least partially about "clear chapters in the evolutionary story" and "community rallying points". Back in 2018 I was willing to give this broader interpretation a chance, but now I think it's questionable whether this aspect was ever a success (unlike the breaking changes part, which was hugely successful). So if all we have to show the world are non-breaking changes, we should seriously consider "just" doing a round of docs polishing and not calling it an edition. Or perhaps we wait to do an edition until (for example) every important post-MVP bit of
await has landed on stable, however many years that takes.
“The only breaking change in Rust 2021 is to remove long-deprecated syntax” could itself be a powerful statement of maturity/stability, if that’s where we end up.
I agree with this entirely, and I do believe we need to very carefully communicate the compatibility story. Our first messaging, right up front, should be how all code continues to compile, how we're not breaking 2018 or 2015 code, and how you can opt into 2021 independently for any given crate. We should explain all of that clearly before we start trumpeting exciting new features or cleanups.
This is absolutely on the table. We're going to carefully consider the set of changes we want to make, and consider whether those could be done without an edition. And furthermore, if the set of changes we consider that would require an edition don't seem sufficient to motivate an edition, we'll consider other alternatives more strongly.
We're not going to do an edition for the sake of doing an edition.
I think an interesting alternative is
The only change in Rust 2021 is to remove long-deprecated syntax
Ie, just remove things like bare trait object syntax. I feel such micro-edition would be an interesting design point:
- it keep the edition mechanism well-oiled
- hopefully, it doesn't really take a lot of bandwidth to implement
- it should be boring/irrelevant for most users
EDIT: that would be ember 2.0 edition
New Features in Ember.js 2.0
- <This space intentionally left blank!>
Major releases of most libraries try to do two things. They introduce new APIs, and remove deprecated ones. Our release focuses on doing one thing well: Instead of introducing new features, the goal of Ember 2.0 is to remove accumulated cruft.
Honestly, I'm in agreement with the "micro edition" idea, so long as it's conservative.
The only three things that an edition enables that I think we could benefit from currently:
- Removing (hiding) the (unambiguously) deprecated language syntax (that has a machine-applicable migration path),
- Removing (hiding) any (unambiguously) deprecated standard library API (that has a machine-applicable migration path), and
- Maybe a tweak of the prelude.
(My pet prelude "fix" is to add
Hash; the traits with the derive in the prelude but not the trait itself.)
I think an edition that explicitly only removes old deprecated syntax that has been linted against since edition2018 would be beneficial to messaging of stability, especially since edition2018 was a perceived bigger change.
Hiding deprecated API is a harder sell, would need implementing, and some story for documentation, and might even go against the stated principle of "nothing new".
So the real question seems to be between the perceived benefit of having a "nothing new" edition or actually having no new edition. And for that, I think the answer might be to let it wait.
Rust's standard release trains are fixed in when they come out. But this isn't to push out updates regularly, but more about features coming "when they're ready", and not being rushed to fit into some milestone release. (Rushing to fit things into edition2018 is probably the roughest point retrospectively.) So the edition should follow the same intent: make one when it's ready, not just because it's time.
So when will the next edition be "ready"? I think we should pribably have one at some point, to hide deprecated syntax. But it also needs to be perceived as a smaller change than edition2018 was, so I honestly don't know.
Editions, maybe accidentally, are more about perception than anything technical. Rust has a reputation (valid or not) for rapidly in flux "best practices," so it's important we don't accidentally make that worse. For better or for worse, changes a "C++" would "hide" as "for the library and compiler authors" are exposed to the end user more in Rust. (I say better: local clarity outweighs "do the “right” thing" implicitly.)
Looking far forward, I think the next "obvious" time to have the "marketing edition" would be "rust-analyzer unification", when the IDE story really is best-in-class for a systems language. Is it worth having minor "cleanup" editions in the long time between now and then? I honestly don't know.
"The only breaking change in Rust 202? is to remove long-deprecated syntax and API-s"
The problem with hiding APIs is two-fold:
- How do you handle it in documentation? It would be quite bad if you were reading code in a previous edition, went to the docs to find a function being called because you aren't familiar with it, and it's not there. Just showing all of the functions then removes most of the benefit of cleaning up the API surface, as it's still there taking up space.
- It's not implemented, unlike the framework for changing language semantics based on edition. It would require significant design an implementation work to create an edition gate on deprecation that doesn't exist for language semantics.
Hmm... are we allowed to remove or change APIs? I understood this to be not allowed under edition changes. That said, it would be awesome if we could have "edition-deprecated" APIs in
libstd where you can use the API until the deprecating edition (and after that, it's like it doesn't exist). And it would show up in the docs as "deprecated in edition 20XX" with a little caution sign or something.
Some people say that an edition every 3 years is appropriate, but Rust 1.0 was released in May 2015, and Rust 1.31 in December 2018; that's more than 3.5 years. If we continued at this pace, the next edition would be released in 2022, but I don't think that we have to do that. Just release a new edition when it makes sense.
New lore -- Rust editions are 31 releases long, so the next edition at 1.62 will be due 2022-06-30.
So now one question remains: does anyone have a feature they want that would require new edition? Or would the edition be largely for the purposes of deprecating syntax?