4 ms·

I was kind of disappointed with Rust 2018. While it technically maintains the guarantee of backwards compatibility I don't feel that it meets it in spirit. The

by huntie 8y ago

I was kind of disappointed with Rust 2018. While it technically maintains the guarantee of backwards compatibility I don't feel that it meets it in spirit. The prime example is that code for working with modules that works fine on 2015 throws an error in 2018. This means that I now have to know two languages that are basically the same but have important differences. This is a real issue because I'm sure that some crates will jump to 2018 while others want to continue compiling on old compilers.

Twisol 8y ago
My understanding is that, since the edition is a per-crate property, crates that don't jump to 2018 aren't any worse off, and will continue to compile on both old and new compilers. I'd also be interested to know whether `cargo fix` covers the module changes for you. (EDIT: I now realize you're talking about crates that will continue development on Rust 2015 specifically because they want to target older compilers, which is a different concern from what I was addressing. But now I'm not sure what the concern actually is. Even if you stay on Rust 2015, what reason is there to not upgrade your compiler? Both editions remain supported in 1.31 and will be for...ever, as far as I know.)
- huntie 8y ago
  `cargo fix` probably covers it, but `cargo new` defaults to Rust 2018, which was kind of annoying when I was getting errors on code from another project that worked fine there. There isn't a reason not to upgrade the compiler. My concern is that if I stay with Rust 2015 nothing changes for me, but if I need to fix a bug in someone's library there is a good chance they'll be on Rust 2018 (or vice versa). My concern is with the mental aspect of needing to remember the differences, not the technical differences. It's possible that there isn't much to remember. Admittedly, I haven't yet looked at what the module changes are; but it still bothers me that such basic code no longer works.
  - Twisol 8y ago
    That's a great point! Helping devs get up to speed on the changes is definitely a significant concern for editions, which is, I'm sure, why they put so much effort into creating a dedicated edition guide: https://doc.rust-lang.org/edition-guide/ https://doc.rust-lang.org/edition-guide/
    - huntie 8y ago
      Sure, the rust team is really good about documentation. I think that I worded things poorly though. One of the reasons that I started using rust is that the rust team said that once they hit 1.0 they would not make breaking changes (unless there was a soundness bug). While Rust 2018 technically keeps this promise since Rust 2015 will continue to compile and interoperate, I do not feel that it keeps the spirit of this promise; which is frustrating to me.
      - tikue_ 8y ago
        Backwards-compatibly changing existing features feels qualitatively the same to me as adding new features. In either case you can ignore them until you need to work on a codebase that uses them.
nicoburns 8y ago
There doesn't tend to be that much support for older compilers in the Rust community (upgrading is so easy...). So I'd expect pretty much every crate to upgrade over the next year or so.
- huntie 8y ago
  I agree that most crates will upgrade, but there are some very prominent crates which maintain compatibility with old rust versions. An example is the regex crate which works on rust 1.20+.
  - steveklabnik 8y ago
    To be clear, rust 2015 code compiles just fine on new compilers, and will indefinitely. That’s a key part of it! Nothing should change with regards to these crates; they already weren’t using new features anyway, in order to maintain that compatibility.
    - huntie 8y ago
      Sure, I understand that. But if I've only ever used Rust 2018 and I go to submit a PR to the regex crate, I now need to be aware of any differences between the two versions. It might not be a big deal, but a few weeks ago I started a new project that was going to reuse code from an existing project. The new project defaulted to 2018 (nightly compiler) and I got a bunch of errors with my module imports. It was just frustrating because it felt like it was a breaking change and one of the reasons I started using Rust is the promise of no breaking changes.
      - steveklabnik 8y ago
        That’s fair! These kinds of changes are generally on par with other “never break” languages like Java and C++. Java 1.4 feels very different than Java 10. It’s tough!
      - therockhead 8y ago
        Is this not the situation when any new feature is added to a language?
Rusky 8y ago
For what it's worth you can write 2018-style modules code in 2015 crates (perhaps modulo a few edge cases?). So if you're willing to switch to that you can have one style across both editions.
- steveklabnik 8y ago
  You can use a 2018 crate from a 2015 crate (and vice versa) but you can’t “expose rust 2015” or something. There’s raw identifiers for anything that would be incompatible. That would require a new rustc, of course.
  - Rusky 8y ago
    I'm... not sure you replied to the right comment here? What I'm talking about is writing 2018-style paths (starting with `crate::`, etc) in a 2015-edition crate, so you don't have to switch between two path styles when you switch between crates.
    - steveklabnik 8y ago
      Ah. I just misunderstood what you meant. Sorry!

by huntie 8y ago

Twisol 8y ago

My understanding is that, since the edition is a per-crate property, crates that don't jump to 2018 aren't any worse off, and will continue to compile on both old and new compilers. I'd also be interested to know whether `cargo fix` covers the module changes for you. (EDIT: I now realize you're talking about crates that will continue development on Rust 2015 specifically because they want to target older compilers, which is a different concern from what I was addressing. But now I'm not sure what the concern actually is. Even if you stay on Rust 2015, what reason is there to not upgrade your compiler? Both editions remain supported in 1.31 and will be for...ever, as far as I know.)

huntie 8y ago
`cargo fix` probably covers it, but `cargo new` defaults to Rust 2018, which was kind of annoying when I was getting errors on code from another project that worked fine there. There isn't a reason not to upgrade the compiler. My concern is that if I stay with Rust 2015 nothing changes for me, but if I need to fix a bug in someone's library there is a good chance they'll be on Rust 2018 (or vice versa). My concern is with the mental aspect of needing to remember the differences, not the technical differences. It's possible that there isn't much to remember. Admittedly, I haven't yet looked at what the module changes are; but it still bothers me that such basic code no longer works.
- Twisol 8y ago
  That's a great point! Helping devs get up to speed on the changes is definitely a significant concern for editions, which is, I'm sure, why they put so much effort into creating a dedicated edition guide: https://doc.rust-lang.org/edition-guide/ https://doc.rust-lang.org/edition-guide/
  - huntie 8y ago
    Sure, the rust team is really good about documentation. I think that I worded things poorly though. One of the reasons that I started using rust is that the rust team said that once they hit 1.0 they would not make breaking changes (unless there was a soundness bug). While Rust 2018 technically keeps this promise since Rust 2015 will continue to compile and interoperate, I do not feel that it keeps the spirit of this promise; which is frustrating to me.
    - tikue_ 8y ago
      Backwards-compatibly changing existing features feels qualitatively the same to me as adding new features. In either case you can ignore them until you need to work on a codebase that uses them.

nicoburns 8y ago

There doesn't tend to be that much support for older compilers in the Rust community (upgrading is so easy...). So I'd expect pretty much every crate to upgrade over the next year or so.

huntie 8y ago
I agree that most crates will upgrade, but there are some very prominent crates which maintain compatibility with old rust versions. An example is the regex crate which works on rust 1.20+.
- steveklabnik 8y ago
  To be clear, rust 2015 code compiles just fine on new compilers, and will indefinitely. That’s a key part of it! Nothing should change with regards to these crates; they already weren’t using new features anyway, in order to maintain that compatibility.
  - huntie 8y ago
    Sure, I understand that. But if I've only ever used Rust 2018 and I go to submit a PR to the regex crate, I now need to be aware of any differences between the two versions. It might not be a big deal, but a few weeks ago I started a new project that was going to reuse code from an existing project. The new project defaulted to 2018 (nightly compiler) and I got a bunch of errors with my module imports. It was just frustrating because it felt like it was a breaking change and one of the reasons I started using Rust is the promise of no breaking changes.
    - steveklabnik 8y ago
      That’s fair! These kinds of changes are generally on par with other “never break” languages like Java and C++. Java 1.4 feels very different than Java 10. It’s tough!
    - therockhead 8y ago
      Is this not the situation when any new feature is added to a language?

Rusky 8y ago

For what it's worth you can write 2018-style modules code in 2015 crates (perhaps modulo a few edge cases?). So if you're willing to switch to that you can have one style across both editions.

steveklabnik 8y ago
You can use a 2018 crate from a 2015 crate (and vice versa) but you can’t “expose rust 2015” or something. There’s raw identifiers for anything that would be incompatible. That would require a new rustc, of course.
- Rusky 8y ago
  I'm... not sure you replied to the right comment here? What I'm talking about is writing 2018-style paths (starting with `crate::`, etc) in a 2015-edition crate, so you don't have to switch between two path styles when you switch between crates.
  - steveklabnik 8y ago
    Ah. I just misunderstood what you meant. Sorry!