3 ms·

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. M

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.
      - pjmlp 7y ago
        How come, given that currently C++ has three years to release a new standard and then about the same until the latest release gets spread around all major compilers? https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support Right now with C++20 around the corner, C++14 is still the safest bet for portable code, whereas in Rust we still see relevant crates that depend on nightly.
        jcranmer 7y ago
        Here is the list of all the major features added to Rust since 1.0: * The new lifetime model (non-lexical lifetimes) * Async fn * Procedural macros * ? operator * Import name resolution changes * impl Trait * C-style unions Here's the list of features added in C++17 and C++20: * constexpr if * Modules * Structured binding * Type deduction helpers * Coroutines * <=> operator * Concepts * Expanded the set of expressions and statements that qualify as constexpr to the point that it's a very different feature from what it was in C++11. In the same amount of time, C++ has added roughly the same number of features, but I would qualitatively say that C++'s feature additions are more impactful than Rust's feature additions, especially in terms of making newer code unrecognizable to programmers used only to the old version. That's what I meant by pace versus cadence--overall, C++ has changed more, but it tends to change in triennial bursts instead of every six weeks.
        pjmlp 7y ago
        The difference being that C++ developers have around 6 years time to get acquainted with each version. The 3 years for each ISO revision, plus around three until the standard is actually usable in a portable way. My old dusty non-maintained MFC applications still compile on latest Visual Studio.

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.
    - pjmlp 7y ago
      How come, given that currently C++ has three years to release a new standard and then about the same until the latest release gets spread around all major compilers? https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support Right now with C++20 around the corner, C++14 is still the safest bet for portable code, whereas in Rust we still see relevant crates that depend on nightly.
      - jcranmer 7y ago
        Here is the list of all the major features added to Rust since 1.0: * The new lifetime model (non-lexical lifetimes) * Async fn * Procedural macros * ? operator * Import name resolution changes * impl Trait * C-style unions Here's the list of features added in C++17 and C++20: * constexpr if * Modules * Structured binding * Type deduction helpers * Coroutines * <=> operator * Concepts * Expanded the set of expressions and statements that qualify as constexpr to the point that it's a very different feature from what it was in C++11. In the same amount of time, C++ has added roughly the same number of features, but I would qualitatively say that C++'s feature additions are more impactful than Rust's feature additions, especially in terms of making newer code unrecognizable to programmers used only to the old version. That's what I meant by pace versus cadence--overall, C++ has changed more, but it tends to change in triennial bursts instead of every six weeks.
        pjmlp 7y ago
        The difference being that C++ developers have around 6 years time to get acquainted with each version. The 3 years for each ISO revision, plus around three until the standard is actually usable in a portable way. My old dusty non-maintained MFC applications still compile on latest Visual Studio.