[kbknapp]

Many (most?) disagree with this line of thinking, but I believe the "Rust will never have a 2.0" style thought is what ultimately leads these multi-year pursuits of perfect (or at least good enough to last "essentially forever"). The Editions provider a certain release valve for some styles of breaking changes, but I don't believe it's quite enough ultimately over the entire lifespan of a language which will undoubtedly grow cruft that even Editions cannot remove.

[steveklabnik]

I would certainly agree that it is a pressure in that direction. But like anything, you take the design constraints you have, and do the best you can with them. Paralysis is not the only possible outcome. Accepting that nothing is ever perfect, that you will make mistakes and then have to deal with it later, and that's okay, is another. There are many instances of the latter happening over the history of Rust's development in the past. It would be nice if the Project could figure out how to strike that balance again.

[infogulch]

There are two ways to take it, "Rust will never have a 2.0 ... therefore everything added to it must be perfect." or "Rust will never have a 2.0 ... so don't try to force it to be something that its not and lets make Rust the best it can be."

A language with Rust's priorities but designed with an effect system from the start could be epic. But Rust is not that language and maybe it can't be. And that's ok. We can give Rust a pass since effect systems weren't even invented yet when it was being designed.

[bananapub]

> I believe the "Rust will never have a 2.0" style thought is what ultimately leads these multi-year pursuits of perfect

probably, but if it had instead had a "Rust will break your code once a year/biyear" style thought then it likely would have been yet another nice ML-y language no one cared about.

[acomar]

it also doesn't help that the fix for the increased difficulty in implementing AsyncIterator for devs (assuming the approach advocated for in the OP winds up being the one selected by the language team) relies on the as yet (?) unstabilized generators/async generators feature. I'm not really why it's not available yet as the necessary compiler features are already in place and have been for years but because it's not, this is kind of a hard pill to swallow.