4 ms·

40 years is a long time, so the experience will almost certainly degrade a fair bit. The notion of editions in rust makes allowances for breaking changes while

by pdpi 5y ago

40 years is a long time, so the experience will almost certainly degrade a fair bit. The notion of editions in rust makes allowances for breaking changes while still keeping backwards compatibility, I'm very curious to see whether the problems that solves outweigh the complexity in the compiler.

pjmlp 5y ago
I am not convinced that editions are much better than language version switches. They only work in the ideal case that whole dependencies are available as source code, the same compiler is used for the whole compilation process and for light syntactic changes. In fact for IntoIterator, a small fix to the editions was made, https://blog.rust-lang.org/2021/05/11/edition-2021.html https://blog.rust-lang.org/2021/05/11/edition-2021.html With 40 years of history, several Rust compilers in production, corporations shipping binary crates, expect the editions to be as effective as ISO/ECMA language editions.
- steveklabnik 5y ago
  Two out of three of those things have nothing to do with editions. The final one is basically saying “you can’t make huge changes,” and I’m not sure how that’s a criticism of the possibility of “in 40 years there will be too many changes.”
  - pjmlp 5y ago
    > Therefore, the answer to the question of, say, “what is a valid C++14 program?” changes over time, up until the publication of C++17, and so forth. In practice, the situation is a bit more complicated when compiler vendors offer conformance modes for specific language revisions (e.g. -std=c++11, -std=c++17). Vendors may consider defect resolutions to apply to any historic revision that contains the defect (whereas ISO considers only the most recent publication as the Standard). http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213... Feel free to think I am only doing FUD, and coming from C++ side I am clueless about how editions will fare in the future.
steveklabnik 5y ago
The design of editions is such to specifically reduce implementation complexity in the compiler, for this reason. The majority of the compiler is edition-agnostic. It’s not the only reason, but it’s a big one.
- pdpi 5y ago
  Could you expand upon this? My specific concern there is that, while the compiler frontend for any one given edition becomes individually simpler, the whole compiler becomes a bit more complicated, and things like IntoIterator, which pjmlp mentioned elsewhere, imply changes across several editions. This is not a major problem when editions means {2015, 2018, 2021}, but in a world where we also have 2024, 2027, ... editions, this becomes increasingly tricky.
  - steveklabnik 5y ago
    The Rust compiler is roughly “parse -> AST -> HIR -> MIR -> LLVM IR -> binary.” I forget exactly where editions are erased (and I’m on my phone so it’s hard to check), but for sure it’s gone by the time MIR exists, which is where things like the borrow checker operates. Edition based changes only affect the very front end of the compiler, basically. This is a necessary requirement of how editions work. For example, it is part of the interoperability story; because the main representation is edition agnostic, interop between crates in different editions is not an issue. … I don’t know how to say this truly politely, but let’s just say I’ve had a few conversations with pjmlp about editions, and I would take the things he says on this topic with a large grain of salt.
    - deleted 5y ago
      [deleted]
    - pjmlp 5y ago
      When Rust editions reach about 5 in the wild, feel free to prove me wrong by mixing binary crates compiled with two Rust compilers, mixing three editions into the same executable. You can also unpolitelly tell me how it will be any different from /std=language for any practical purposes.

by pdpi 5y ago

pjmlp 5y ago

I am not convinced that editions are much better than language version switches. They only work in the ideal case that whole dependencies are available as source code, the same compiler is used for the whole compilation process and for light syntactic changes. In fact for IntoIterator, a small fix to the editions was made, https://blog.rust-lang.org/2021/05/11/edition-2021.html https://blog.rust-lang.org/2021/05/11/edition-2021.html With 40 years of history, several Rust compilers in production, corporations shipping binary crates, expect the editions to be as effective as ISO/ECMA language editions.

steveklabnik 5y ago
Two out of three of those things have nothing to do with editions. The final one is basically saying “you can’t make huge changes,” and I’m not sure how that’s a criticism of the possibility of “in 40 years there will be too many changes.”
- pjmlp 5y ago
  > Therefore, the answer to the question of, say, “what is a valid C++14 program?” changes over time, up until the publication of C++17, and so forth. In practice, the situation is a bit more complicated when compiler vendors offer conformance modes for specific language revisions (e.g. -std=c++11, -std=c++17). Vendors may consider defect resolutions to apply to any historic revision that contains the defect (whereas ISO considers only the most recent publication as the Standard). http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213... Feel free to think I am only doing FUD, and coming from C++ side I am clueless about how editions will fare in the future.

steveklabnik 5y ago

The design of editions is such to specifically reduce implementation complexity in the compiler, for this reason. The majority of the compiler is edition-agnostic. It’s not the only reason, but it’s a big one.

pdpi 5y ago
Could you expand upon this? My specific concern there is that, while the compiler frontend for any one given edition becomes individually simpler, the whole compiler becomes a bit more complicated, and things like IntoIterator, which pjmlp mentioned elsewhere, imply changes across several editions. This is not a major problem when editions means {2015, 2018, 2021}, but in a world where we also have 2024, 2027, ... editions, this becomes increasingly tricky.
- steveklabnik 5y ago
  The Rust compiler is roughly “parse -> AST -> HIR -> MIR -> LLVM IR -> binary.” I forget exactly where editions are erased (and I’m on my phone so it’s hard to check), but for sure it’s gone by the time MIR exists, which is where things like the borrow checker operates. Edition based changes only affect the very front end of the compiler, basically. This is a necessary requirement of how editions work. For example, it is part of the interoperability story; because the main representation is edition agnostic, interop between crates in different editions is not an issue. … I don’t know how to say this truly politely, but let’s just say I’ve had a few conversations with pjmlp about editions, and I would take the things he says on this topic with a large grain of salt.
  - deleted 5y ago
    [deleted]
  - pjmlp 5y ago
    When Rust editions reach about 5 in the wild, feel free to prove me wrong by mixing binary crates compiled with two Rust compilers, mixing three editions into the same executable. You can also unpolitelly tell me how it will be any different from /std=language for any practical purposes.