3 ms·

> The language already has too many features. That's actually the point. Many of these additions can be phrased as unifying existing features and allowing them

> The language already has too many features. That's actually the point. Many of these additions can be phrased as unifying existing features and allowing them to be used in previously unusable ways and contexts. There's basically no real increase in user-perceived complexity. The Rust editions system is a key enabler of this, and C++ has nothing comparable.

pjmlp 8mo ago
It has clang tidy, -std=lang-version, and preprocessor that is version aware. Rust editions don't cover all use cases that one can think of regarding language evolution, and requires full access to source code.
- SkiFire13 8mo ago
  > requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work
  - zozbot234 8mo ago
    You can write a binary library that exposes a C ABI using Rust (which is indistinguishable from an ordinary C/C++ library) and then provide source for a Rust wrapper crate that provides a "safe" interface to it, much like a C header file.
  - pjmlp 8mo ago
    Yes they do, when mixing crates from various editions and how changes interact together.
    - aw1621107 8mo ago
      > when mixing crates from various editions and how changes interact together. Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.
      - pjmlp 8mo ago
        Because in order to have standard library breaking changes across editions, if those types are exposed in the crate public types, or change their semantics across editions, the compiler has to be able to translate between them when generating code. See the Rust documentation on what editions are allowed to change, and the advanced migration guide on examples regarding manual code migration. Not so much what has happened thus far, rather the limitations imposed in what is possible to actually break across editions.
        Rusky 8mo ago
        Or put another way, a hypothetical feature that you made up in your head is the thing that requires source access. Editions do not let you change the semantics of types. To be fair, Rust tooling does tend toward build-from-source. But this is for completely different reasons than the edition system: if you had a way to build a crate and then feed the binary into builds by future compilers, it would require zero additional work to link it into a crate using a different edition.
        pjmlp 8mo ago
        Exactly, hence why people should stop talking about editions as if they sort out all Rust evolution problems, in your own words it doesn't allow changing type semantics
        ChrisSD 8mo ago
        I think you're too stuck on the current implementation. Work is going into investigating how to evolve the standard library over editions. The "easiest" win would be to have a way to do edition-dependent re-exports of types.
        pjmlp 8mo ago
        What I am stuck is Rust folks advocating editions as the solution for everything in language evolution, when it clearly isn't.
jstanley 8mo ago
https://xkcd.com/927/ https://xkcd.com/927/
- wtetzner 8mo ago
  Can you explain how this is relevant here?
  - jstanley 8mo ago
    Adding a new feature to unify existing features is perfectly isomorphic to defining a new standard to unify existing standards.
    - wtetzner 8mo ago
      It's not though, unless the new feature and existing features continue to exist as disjoint things. If the new feature subsumes the old ones, then you've reduced the number of features in the language.
      - jstanley 8mo ago
        The same is true of standards.
patrick451 8mo ago
This comparison is useless until rust commits to a stable ABI.
hrmtst93837 8mo ago
[flagged]
- aw1621107 8mo ago
  > and they force [] libraries to support multiple modes at once, I'm not entirely sure I agree? I don't think any library except for the standard library needs to "support multiple modes at once"; everything else just sets its own edition and can remain blissfully unaware of whatever edition its downstream consumer(s) are using. > which is a different kind of maintenance tax than evolving C++ compilers and feature test macros impose. I'm not sure I agree here either? Both Rust and C/C++ tooling and their standard libraries needs to support multiple "modes" due to codebases not all using the same "mode", so to me the maintenance burden should be (abstractly) the same for the two. > Require RFCs to include an interaction test matrix, compile time and code size measurements, and a pass from rust-analyzer and clippy IIRC rustc already tracks various compilation-related benchmarks at perf.rust-lang.org. rustc also has edition-related warnings [0] (see the rust-YYYY-compatibility groups), so you don't even need clippy/rust-analyzer. [0]: https://doc.rust-lang.org/rustc/lints/groups.html https://doc.rust-lang.org/rustc/lints/groups.html
  - hrmtst93837 8mo ago
    [flagged]
    - aw1621107 8mo ago
      > Even if a crate compiles under a single edition, exported APIs often avoid edition specific idioms that could cause friction for consumers compiled under older editions. Do you have some concrete examples of this outside the expected bump to the minimum required Rust version? I'm coming up blank, and this sounds like it goes against one of the primary goals of editions (i.e., seamless interop) as well. > So while technically each crate chooses its edition, ecosystem reality introduces cross-edition friction. And this is related to the above; I can't think of any actual sources of friction in a mixed-edition project beyond needing to support new-enough rustc versions. > Rust tools such as rustc, rust analyzer, rustfmt, and clippy must understand edition dependent grammar and semantics simultaneously. I'm not entirely convinced here? Editions are a crate-wide property and crates are Rust's translation units, so I don't think there should be anything more "simultaneous" going on compared to -std=c++xx/etc. flags. > Over time this creates a cumulative maintenance burden similar to maintaining compatibility with many historical language versions. Sure, but that's more or less what I was saying in the first place!

pjmlp 8mo ago

It has clang tidy, -std=lang-version, and preprocessor that is version aware. Rust editions don't cover all use cases that one can think of regarding language evolution, and requires full access to source code.

SkiFire13 8mo ago
> requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work
- zozbot234 8mo ago
  You can write a binary library that exposes a C ABI using Rust (which is indistinguishable from an ordinary C/C++ library) and then provide source for a Rust wrapper crate that provides a "safe" interface to it, much like a C header file.
- pjmlp 8mo ago
  Yes they do, when mixing crates from various editions and how changes interact together.
  - aw1621107 8mo ago
    > when mixing crates from various editions and how changes interact together. Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.
    - pjmlp 8mo ago
      Because in order to have standard library breaking changes across editions, if those types are exposed in the crate public types, or change their semantics across editions, the compiler has to be able to translate between them when generating code. See the Rust documentation on what editions are allowed to change, and the advanced migration guide on examples regarding manual code migration. Not so much what has happened thus far, rather the limitations imposed in what is possible to actually break across editions.
      - Rusky 8mo ago
        Or put another way, a hypothetical feature that you made up in your head is the thing that requires source access. Editions do not let you change the semantics of types. To be fair, Rust tooling does tend toward build-from-source. But this is for completely different reasons than the edition system: if you had a way to build a crate and then feed the binary into builds by future compilers, it would require zero additional work to link it into a crate using a different edition.
        pjmlp 8mo ago
        Exactly, hence why people should stop talking about editions as if they sort out all Rust evolution problems, in your own words it doesn't allow changing type semantics
        ChrisSD 8mo ago
        I think you're too stuck on the current implementation. Work is going into investigating how to evolve the standard library over editions. The "easiest" win would be to have a way to do edition-dependent re-exports of types.
        pjmlp 8mo ago
        What I am stuck is Rust folks advocating editions as the solution for everything in language evolution, when it clearly isn't.

jstanley 8mo ago

https://xkcd.com/927/ https://xkcd.com/927/

wtetzner 8mo ago
Can you explain how this is relevant here?
- jstanley 8mo ago
  Adding a new feature to unify existing features is perfectly isomorphic to defining a new standard to unify existing standards.
  - wtetzner 8mo ago
    It's not though, unless the new feature and existing features continue to exist as disjoint things. If the new feature subsumes the old ones, then you've reduced the number of features in the language.
    - jstanley 8mo ago
      The same is true of standards.

patrick451 8mo ago

This comparison is useless until rust commits to a stable ABI.

hrmtst93837 8mo ago

[flagged]

aw1621107 8mo ago
> and they force [] libraries to support multiple modes at once, I'm not entirely sure I agree? I don't think any library except for the standard library needs to "support multiple modes at once"; everything else just sets its own edition and can remain blissfully unaware of whatever edition its downstream consumer(s) are using. > which is a different kind of maintenance tax than evolving C++ compilers and feature test macros impose. I'm not sure I agree here either? Both Rust and C/C++ tooling and their standard libraries needs to support multiple "modes" due to codebases not all using the same "mode", so to me the maintenance burden should be (abstractly) the same for the two. > Require RFCs to include an interaction test matrix, compile time and code size measurements, and a pass from rust-analyzer and clippy IIRC rustc already tracks various compilation-related benchmarks at perf.rust-lang.org. rustc also has edition-related warnings [0] (see the rust-YYYY-compatibility groups), so you don't even need clippy/rust-analyzer. [0]: https://doc.rust-lang.org/rustc/lints/groups.html https://doc.rust-lang.org/rustc/lints/groups.html
- hrmtst93837 8mo ago
  [flagged]
  - aw1621107 8mo ago
    > Even if a crate compiles under a single edition, exported APIs often avoid edition specific idioms that could cause friction for consumers compiled under older editions. Do you have some concrete examples of this outside the expected bump to the minimum required Rust version? I'm coming up blank, and this sounds like it goes against one of the primary goals of editions (i.e., seamless interop) as well. > So while technically each crate chooses its edition, ecosystem reality introduces cross-edition friction. And this is related to the above; I can't think of any actual sources of friction in a mixed-edition project beyond needing to support new-enough rustc versions. > Rust tools such as rustc, rust analyzer, rustfmt, and clippy must understand edition dependent grammar and semantics simultaneously. I'm not entirely convinced here? Editions are a crate-wide property and crates are Rust's translation units, so I don't think there should be anything more "simultaneous" going on compared to -std=c++xx/etc. flags. > Over time this creates a cumulative maintenance burden similar to maintaining compatibility with many historical language versions. Sure, but that's more or less what I was saying in the first place!