4 ms·

I don't think Rust is even defined by a reference implementation, given that they release a new compiler every six weeks. For many practical purposes I think t

I don't think Rust is even defined by a reference implementation, given that they release a new compiler every six weeks. For many practical purposes I think the closest thing to a language definition is the set of testsuites visible to Crater. (That is: when the compiler people are considering a change, they don't say "we can't change this because we're past 1.0 and the change is technically backwards-incompatible", or "we can't change this because the Reference specifies the current behaviour"; they say "let's do a Crater run and see if anything breaks".)

steveklabnik 7y ago
This is not correct. We do use crater to help with questionable cases, but we often say “we can’t change this because we’re past 1.0 and the change is backwards incompatible.”
- umanwizard 7y ago
  Which is still not the same as having a spec or even a reference implementation. It’s a bit weird how laser-focused the Rust community is on backwards compatibility, not seeming to believe that forward compatibility is also important. e.g., if I write code targeting C++17, I can be reasonably sure it compiles with an older version of the compiler, as long as that version also claims to support C++17, modulo bugs. Not the case if I write code targeting Rust 2015 as they’re still adding features to that from time to time. Let alone Rust 2018 which changes every 6 weeks. Will there ever be a version of Rust that the community agrees “OK, this language definition is not changing unless we find some major soundness bug” ? This is a big blocker for mainstream adoption in Linux distributions since the maintainer wants to be able to land one specific version of rustc in the repositories, not rely on people downloading new versions with rustup continuously. But old versions of rustc are effectively useless due to the lack of forward compatibility guarantees.
  - sanxiyn 7y ago
    It's not that Rust community ignores forward compatibility, it's just that right now is not the right time. Things recently landing on Rust is not new stuffs. Most of them were designed in, like, 2017. It just took years to stabilize.
    - umanwizard 7y ago
      When is the right time, then? I would have thought the move to the 2018 Edition should have been the perfect time to declare the 2015 Edition as stable and unchanging, no? But it is still receiving major changes like non-lexical lifetimes.
      - kibwen 7y ago
        Editions are not designed to be unchanging snapshots of the Rust compiler at a specific moment in time. By design, all Rust editions share the same middle-end and backend, and only differ in the frontiest parts of the frontend. The idea is that people should be able to update their version of the compiler without being required to update code that compiled prior to the 2018 edition.
        umanwizard 7y ago
        Yes, I understand that. I'm saying I don't understand why the Rust community has made that choice, since it essentially makes old versions of the compiler useless and therefore makes it difficult for software written in Rust to be part of a typical Linux distribution. (And has a number of other disadvantages too, like constant cognitive load having to re-learn the language every 6 weeks). Also, editions could be a snapshot of the language definition at a point in time, without being a snapshot of the compiler. There are still new versions of Clang and GCC coming out with new bugfixes, better optimizations, improved error messages, support for different hardware, WIP support for future language editions, etc., without changing the C++17 standard.
        jcranmer 7y ago
        > (And has a number of other disadvantages too, like constant cognitive load having to re-learn the language every 6 weeks). While the cadence may be faster, the pace of language change in Rust is slower than other popular languages such as C++ or JS.
  - jcranmer 7y ago
    It's funny you cite C++, which has the best example of forward compatibility breakage in terms of impacting people. g++ 4.4 implemented several key parts of C++11, including notably rvalue references, and adapted libstdc++ to use rvalue references in C++11 mode. However, the committee had to make major revisions to rvalue references subsequent to this implementation, to the point that you can't use libstdc++ 4.4's header files (such as <vector>) with a compliant C++11 compiler. So when you try to use newer clang (which prefers to use system libstdc++ for ABI reasons) on systems with 4.4 installed (because conservative IT departments), the result is lots and lots of pain. Furthermore, it absolutely is the case that newer versions of compilers will interpret old language standards differently than older versions of the compiler. You don't notice it for the most part because the changes tend to revolve around pretty obscure language wordings involving combinations of features that most people won't hit. Compilers are going to try hard not to care about language versions past the frontend of the compiler--if the specification change lies entirely in the middle or backend, then that change is likely to be retroactively applied to past versions because otherwise the plumbing necessary is too difficult.
    - umanwizard 7y ago
      g++ 4.4 came out before the C++11 standard was released. So I’m not sure how it’s a counterexample. C++11 was a standard under active development and so obviously you can expect changes; its status at that time was comparable to rust nightly.
    - gpderetta 7y ago
      Yes,gcc doesn't guarantee ABI, or even API, stability for experimental features. News at 11.
  - fluffy87 7y ago
    I write standard compliant C++ code that only works with the latest compiler versions because older ones incorrectly claim support for C++ standard, but their implementation is too buggy.

steveklabnik 7y ago

This is not correct. We do use crater to help with questionable cases, but we often say “we can’t change this because we’re past 1.0 and the change is backwards incompatible.”

umanwizard 7y ago
Which is still not the same as having a spec or even a reference implementation. It’s a bit weird how laser-focused the Rust community is on backwards compatibility, not seeming to believe that forward compatibility is also important. e.g., if I write code targeting C++17, I can be reasonably sure it compiles with an older version of the compiler, as long as that version also claims to support C++17, modulo bugs. Not the case if I write code targeting Rust 2015 as they’re still adding features to that from time to time. Let alone Rust 2018 which changes every 6 weeks. Will there ever be a version of Rust that the community agrees “OK, this language definition is not changing unless we find some major soundness bug” ? This is a big blocker for mainstream adoption in Linux distributions since the maintainer wants to be able to land one specific version of rustc in the repositories, not rely on people downloading new versions with rustup continuously. But old versions of rustc are effectively useless due to the lack of forward compatibility guarantees.
- sanxiyn 7y ago
  It's not that Rust community ignores forward compatibility, it's just that right now is not the right time. Things recently landing on Rust is not new stuffs. Most of them were designed in, like, 2017. It just took years to stabilize.
  - umanwizard 7y ago
    When is the right time, then? I would have thought the move to the 2018 Edition should have been the perfect time to declare the 2015 Edition as stable and unchanging, no? But it is still receiving major changes like non-lexical lifetimes.
    - kibwen 7y ago
      Editions are not designed to be unchanging snapshots of the Rust compiler at a specific moment in time. By design, all Rust editions share the same middle-end and backend, and only differ in the frontiest parts of the frontend. The idea is that people should be able to update their version of the compiler without being required to update code that compiled prior to the 2018 edition.
      - umanwizard 7y ago
        Yes, I understand that. I'm saying I don't understand why the Rust community has made that choice, since it essentially makes old versions of the compiler useless and therefore makes it difficult for software written in Rust to be part of a typical Linux distribution. (And has a number of other disadvantages too, like constant cognitive load having to re-learn the language every 6 weeks). Also, editions could be a snapshot of the language definition at a point in time, without being a snapshot of the compiler. There are still new versions of Clang and GCC coming out with new bugfixes, better optimizations, improved error messages, support for different hardware, WIP support for future language editions, etc., without changing the C++17 standard.
        jcranmer 7y ago
        > (And has a number of other disadvantages too, like constant cognitive load having to re-learn the language every 6 weeks). While the cadence may be faster, the pace of language change in Rust is slower than other popular languages such as C++ or JS.
- jcranmer 7y ago
  It's funny you cite C++, which has the best example of forward compatibility breakage in terms of impacting people. g++ 4.4 implemented several key parts of C++11, including notably rvalue references, and adapted libstdc++ to use rvalue references in C++11 mode. However, the committee had to make major revisions to rvalue references subsequent to this implementation, to the point that you can't use libstdc++ 4.4's header files (such as <vector>) with a compliant C++11 compiler. So when you try to use newer clang (which prefers to use system libstdc++ for ABI reasons) on systems with 4.4 installed (because conservative IT departments), the result is lots and lots of pain. Furthermore, it absolutely is the case that newer versions of compilers will interpret old language standards differently than older versions of the compiler. You don't notice it for the most part because the changes tend to revolve around pretty obscure language wordings involving combinations of features that most people won't hit. Compilers are going to try hard not to care about language versions past the frontend of the compiler--if the specification change lies entirely in the middle or backend, then that change is likely to be retroactively applied to past versions because otherwise the plumbing necessary is too difficult.
  - umanwizard 7y ago
    g++ 4.4 came out before the C++11 standard was released. So I’m not sure how it’s a counterexample. C++11 was a standard under active development and so obviously you can expect changes; its status at that time was comparable to rust nightly.
  - gpderetta 7y ago
    Yes,gcc doesn't guarantee ABI, or even API, stability for experimental features. News at 11.
- fluffy87 7y ago
  I write standard compliant C++ code that only works with the latest compiler versions because older ones incorrectly claim support for C++ standard, but their implementation is too buggy.