4 ms·

There is also the possibility that a Rust 2.0 could fragment the community much like with Python2.7 <-> Python3.x, which would be "undesirable" at best.

• steveklabnik 10y ago
  Yes, a split like this would be undesirable to say the least. Not to mention that systems people are used to near-total backwards compatibility; any sort of near-term timeframe for such a thing would destroy a lot of our credibility, in my personal opinion. I'm on team "never 2.0". We still have some desire to indicate "epochs" of Rust development, as undoubtedly, things like idioms will change over time, new libraries will replace older ones, etc. But I'd prefer something like "modern C++", which could signify this kind of change, without giving up on backwards compatibility.
  • Manishearth 10y ago
    I sort of want to make an RfC for 2.0 preparation. I am mostly on team "never 2.0", but I recognize that I am sadly not overlord of all things Rust (if I were we'd have stable emoji identifiers already) and it's quite possible that 2.0 will happen some day. The idea is to come up with a set of processes for 2.0. If the community decides to do a breaking 2.0 for some reason, we should: - Document exactly what has changed. - Write extensive docs on upgrading - Write good tools that do the upgrade for you when possible, and point out areas where they can't help with links to docs. - Make it so that the cases where stuff isn't machine-upgradeable are minimal - Be wary of actually removing deprecated APIs. - Be wary of unnecessary extra breakage. Python 3 took the attitude of "Okay, we're going to be breaking some things anyway, so let's break more!". I think that they had good reasons for doing that; and it makes sense in a way. But we may not want to follow the same philosophy.
    • CryZe 10y ago
      I feel like you could just add a version number to the Cargo.toml (cargo new would automatically set the latest one). The crate would then be built with the semantics of that version and all crates you use still use the version they were designed for (as long as the semantics can be properly translated between the individual versions).
      • Manishearth 10y ago
        That wouldn't work in practice. Breaking changes need not be syntactic, and probably wouldn't be syntactic -- Rust isn't going to break the language for that. There's a good chance it would be semantic breakage that can't allow interoperation between crates.
        • comex 10y ago
          What sort of semantic breakage do you have in mind? My impression is that there are few changes of that sort that couldn't be worked around somehow.
          • Manishearth 10y ago
            Changes to the orphan rules, for one. Changing the behavior and representation of stdlib APIs. You would end up with e.g. two incompatible representations of String being used across the crate boundary.
  • oblio 10y ago
    Maybe compiler profiles? So that a project can say -rust2018 and disallow bad practices from pre-2018?
    • xorxornop 10y ago
      Yeah. Basically linting profiles. Reminds me of some proposals I've read about reducing the complexity of C++ without creating an actual subset or superset.
• hsivonen 10y ago
  I wish the notion of Rust 2.0 was definitively buried to remove the fear of Rust doing its own Python 3.
  • kibwen 10y ago
    Trust me, if there's ever a Rust 2.0, it will contain minimal breaking changes (ideally no breaking changes that can't be automatically and infallibly fixed by a migration tool), and will be preceded by years and years of deprecation warnings. Python 3 broke Python because it completely changed how strings work. Nothing of that magnitude will ever come to Rust.