The list of changes is tiny compared to the 2018 edition.
The module system was a big change, and the macro changes caused quite a bit of breakage. Both were important.
The changes here are nice to have, especially the partial struct borrowing. The prelude additions are convenient, but not terribly relevant anymore for me since rust-analyzer gained support for automatic trait imports. The new resolver is really helpful, but can also be changed in Cargo.toml. The new edition will just have the new resolver as the default.
This amount of changes would not lead to a breaking release in other languages. Which is a good thing!
Rust has been excellent about maintaining backwards compatability. The 2015 edition still works just fine on new compilers. Questionable changes are regularly tested against all crates on crates.io to prevent regressions. Developers also proactively submit fixes to crates for tiny breaking compiler/std fixes before they land.
The evolution of Rust has been very significant and impactful, while still remaining responsible and executed with a lot of competence, supported by good tooling.
I assume this edition is almost as much about maintaining institutional knowledge on how to do an edition as it is about the actual breaking features. It's quite easy to forget a lot of things over 6 years, so doing it regularly is important.
If they do the same as with Rust 2018, the actual list of changes in the Rust Edition Guide will be much larger, because they will list all of the major non-breaking changes since 2018 as part of 2021, even though most of them are available in all editions and have been ever since whatever version introduced them. The idea being that the editions guide documents "What is new since the day of release of the previous edition", in addition to documenting the changes specific to the new edition (which are generally breaking changes, or they would be made available to all editions).
But still, the list of breaking changes here is quite small, and mostly some edge cases that will not impact the overwhelming majority of code.
It's amazing to see how few backwards-incompatible changes have come out of three years of language evolution. Really speaks to how mature Rust has become.
Does it take the same effort to adopt for a Rust developer as learning C++ concepts for a C++ developer for example?
I'm not saying that C++2020 would be a bad change (it's not as it is modernizing the language), but the amount of things a C++ developer has to learn is tiring as the language improves.
What is the difference between Rust XXXX edition and Rust X.X version?
I suspect it's simply a limitation of features to let the compiler version improve but have an explicit list of supported/unsupported feature every 4 years to avoid the fragmentation.
But I can't find information about this on the article.
Editions are like different dialects of the same language. A particular compiler version can understand multiple editions, and crates can choose which edition of the language they're using.
The closest equivalent to editions in other languages are specification revisions. For example, with the C language, you have the C99 standard from 1999, the C11 standard from 2011, and so on. Each compiler will have a default setting for which standard to follow, but you can usually change it via command-line flag for each invocation (e.g. `-std=c99` in GCC). So you can have a file written in C99 next to a file written in C11.
Introducing a new edition enables some changes to the language that are otherwise not possible with Rust's strict backwards-compatibility rules. For example, Rust 2018 introduced the "async" and "await" keywords. In Rust 2015, you could have a variable called "async". That's not possible in Rust 2018 anymore, so that's a breaking change. But each crate specifies what edition it's using in its Cargo.toml, so you can mix an older crate written in Rust 2015 that uses that variable name somewhere in its code, with a newer crate written in Rust 2018 (or, soon, Rust 2021).
So the Rust team doesn't have to do a single release where they say "all code using async as a variable name is broken now", they can continue supporting old code while also enabling new code at the same time.
The module system was a big change, and the macro changes caused quite a bit of breakage. Both were important.
The changes here are nice to have, especially the partial struct borrowing. The prelude additions are convenient, but not terribly relevant anymore for me since rust-analyzer gained support for automatic trait imports. The new resolver is really helpful, but can also be changed in Cargo.toml. The new edition will just have the new resolver as the default.
This amount of changes would not lead to a breaking release in other languages. Which is a good thing!
Rust has been excellent about maintaining backwards compatability. The 2015 edition still works just fine on new compilers. Questionable changes are regularly tested against all crates on crates.io to prevent regressions. Developers also proactively submit fixes to crates for tiny breaking compiler/std fixes before they land.
The evolution of Rust has been very significant and impactful, while still remaining responsible and executed with a lot of competence, supported by good tooling.
I assume this edition is almost as much about maintaining institutional knowledge on how to do an edition as it is about the actual breaking features. It's quite easy to forget a lot of things over 6 years, so doing it regularly is important.