4 ms·

That, and then there's the fact that due to editions, modern Rust compilers can still compile older Rust code, which isn't always the case for other languages.

That, and then there's the fact that due to editions, modern Rust compilers can still compile older Rust code, which isn't always the case for other languages. There's Python 3.10 code out there that won't run under 3.13, especially so if it relies on components written in C that use Python's C API. If you didn't have LTS releases for Python, you'd have a choice between constantly having to port your code to run under the latest Python version or using an older, insecure one. Rust doesn't have this problem, old Rust code should compile just fine under newer versions of the compiler and stdlib.

pjmlp 2y ago
Editions sales pitch never mention the fact that only applies to small grammar changes, your code will break if there are library or semantic changes across editions.
- tialaramex 2y ago
  Yes and no. Yes obviously this just works for "small" grammar changes such as introducing new keywords without fear (which is why Rust's async is called async, not "co_async") and doesn't need awkward keyword reuse like "requires requires" and "class enum". But it enables far more. Lets take an existing edition first, in Rust 2021 Edition (what you get today out of the box when you just start writing Rust) the array types impl IntoIterator. Which makes sense, why shouldn't I iterate over this array with a for loop ? But, Rust 1.0 could not possibly have provided this, how would it work? It didn't in Rust 1.0 you can't make an array into an Iterator. Now, if this was some obscure rarely used feature maybe you'd just say "Who cares" but this is IntoIterator which is used to make for loops work, so that's high profile. So in fact what happens is that a modern Rust compiler (in which there even is a 2021 edition) knows that in earlier Editions it should pretend that arrays did not impl IntoIterator. You can loop over them just fine, but mysteriously they don't impl IntoIterator, so that code which used to mean one thing (because they didn't implement this) still means what it used to. So that's an example of seamlessly making Rust 2021 edition have better semantics and yet all the old software still works. In 2024 edition the semantics of certain RPITs (Return Position Impl Trait, an existential type) with respect to lifetimes are expected to change. In most cases either what you wrote already is technically wrong but will now be correct, or, what you wrote was wrong but you got away with it and now you'll get told you got it wrong if you move editions. Editions is not a panacea but it's vastly better than the previous status quo, look at how miserable the situation is in Java, in C++, in Python. Vastly different approaches, worse results on all dimensions.
  - pjmlp 2y ago
    I still don't see it being much different from using language switches, especially when language semantics, ABI across versions, and standard library are part of the whole upgrade story. Additionally I have my doubts how long this will scale when Rust has like 40 years of history behind it.
    - estebank 2y ago
      > I have my doubts how long this will scale when Rust has like 40 years of history behind it. We've been doing this for 10 years already, so if the cost is linear, it shouldn't be a problematic burden over another 30 years. It helps that editions don't need to be big. Just checked the codebase and there are exactly 70 gates for "at least edition X" (2018 21, 2021 19 and 2024 30) and 16 for "is edition 2015" (2 in the parser, most of the rest in name resolution).

pjmlp 2y ago

Editions sales pitch never mention the fact that only applies to small grammar changes, your code will break if there are library or semantic changes across editions.

tialaramex 2y ago
Yes and no. Yes obviously this just works for "small" grammar changes such as introducing new keywords without fear (which is why Rust's async is called async, not "co_async") and doesn't need awkward keyword reuse like "requires requires" and "class enum". But it enables far more. Lets take an existing edition first, in Rust 2021 Edition (what you get today out of the box when you just start writing Rust) the array types impl IntoIterator. Which makes sense, why shouldn't I iterate over this array with a for loop ? But, Rust 1.0 could not possibly have provided this, how would it work? It didn't in Rust 1.0 you can't make an array into an Iterator. Now, if this was some obscure rarely used feature maybe you'd just say "Who cares" but this is IntoIterator which is used to make for loops work, so that's high profile. So in fact what happens is that a modern Rust compiler (in which there even is a 2021 edition) knows that in earlier Editions it should pretend that arrays did not impl IntoIterator. You can loop over them just fine, but mysteriously they don't impl IntoIterator, so that code which used to mean one thing (because they didn't implement this) still means what it used to. So that's an example of seamlessly making Rust 2021 edition have better semantics and yet all the old software still works. In 2024 edition the semantics of certain RPITs (Return Position Impl Trait, an existential type) with respect to lifetimes are expected to change. In most cases either what you wrote already is technically wrong but will now be correct, or, what you wrote was wrong but you got away with it and now you'll get told you got it wrong if you move editions. Editions is not a panacea but it's vastly better than the previous status quo, look at how miserable the situation is in Java, in C++, in Python. Vastly different approaches, worse results on all dimensions.
- pjmlp 2y ago
  I still don't see it being much different from using language switches, especially when language semantics, ABI across versions, and standard library are part of the whole upgrade story. Additionally I have my doubts how long this will scale when Rust has like 40 years of history behind it.
  - estebank 2y ago
    > I have my doubts how long this will scale when Rust has like 40 years of history behind it. We've been doing this for 10 years already, so if the cost is linear, it shouldn't be a problematic burden over another 30 years. It helps that editions don't need to be big. Just checked the codebase and there are exactly 70 gates for "at least edition X" (2018 21, 2021 19 and 2024 30) and 16 for "is edition 2015" (2 in the parser, most of the rest in name resolution).