6 ms·

rust is _almost_ as complex as C++. Introducing these new "edition" would grow the complexity exponentially. I hope they would think twice about the effects o

rust is _almost_ as complex as C++. Introducing these new "edition" would grow the complexity exponentially. I hope they would think twice about the effects on new learners before even experimenting

weinzierl 3y ago
"rust is _almost_ as complex as C++." I don't agree, but even if it were true, C++ has so much accidental complexity (because of its legacy) that you cannot meaningfully compare it with Rust, which by and large is very well thought out. In general, if something is complex in Rust that is because it's in the nature of the problem and not because of some quirkiness in the solution. Borrowing is the prime example. People find it complex, but just because the C++ compiler doesn't check the rules for you, doesn't mean you have follow them in C++ as well (which is tedious and error-prone) or know exactly why you don't have to follow them (which is even harder). I admit though, that the Leakpocalypse (which the article talks about, even if it doesn't call it like that) is an area where accidental complexity lurks.
- vlovich123 3y ago
  Pin is another one. I still can’t wrap my head around it. I’m sure it’s simple and the docs are great, but having read them multiple times I’m not really more clear. I probably need to see a bunch of hands on examples. I wish they’d gone the Move route instead of rushing to 1.0 and then retrofitting in Pin. But I agree, in general things in rust are a lot more thought out and experiments are relegated to unstable which is fine with breaking changes. I do wish though that they had a better versioning story in the language for making backward incompatible changes more a matter of course. It’s great already for “user space” code via editions, but as the author notes making certain kinds of changes brings up risk and uncertainty because there’s not a well trodden path to support changing core semantics in the language and having it work gracefully without needing a migration en masse.
  - majewsky 3y ago
    > I wish they’d gone the Move route instead of rushing to 1.0 and then retrofitting in Pin. That is easy to say, and I don't disagree with the sentiment, but there are valid reasons for setting a 1.0 release date and cutting corners to get there. If they had not done that, there probably was a real risk of running an infinite loop of "let's wait for Move to be implemented", "great, now let's wait for Leak to be implemented", "great, now let's wait for..." and a 1.0 never gets put out. Rust may not be perfect, but at least it's stable and people are actually using it.
  - cmrdporcupine 3y ago
    Pin used to confuse me, but now it's clearer. It's right in the name: Pin this thing to where it is in memory, never try to move it. Rust can and does move things around as it feels the need. So you need something like Pin if what you've built can't move. It's confusing if you're coming from a C++ background because in C++ something only "moves" if you explicitly std::move it. In Rust its effectively the reverse. A crude way of thinking about Rust's call pattern is that it's basically the opposite: as if every call was a std::move operation. So Pin is basically just saying: you can't move this, don't try. The memory can't be moved. And it's mostly used in corner cases where some kind of explicit memory management is involved. Most Rust users should not have to worry about it. It's one of those things that becomes more of a concern if you're writing library code for low level datastructures, or interfacing with C/C++ libraries.
    - laurencerowe 3y ago
      > Most Rust users should not have to worry about it. It's one of those things that becomes more of a concern if you're writing library code for low level datastructures, or interfacing with C/C++ libraries. Don’t all Rust users writing async code have to worry about Pin?
      - brigadier132 3y ago
        Not really, the async libraries hide the implementation details from you. It's an issue for library developers.
- cwzwarich 3y ago
  One advantage C++ has over Rust is that there are multiple fairly compliant C++ implementations, and the process of making them created some shared understanding of how the language actually works from an implementation perspective. There are several aspects of the current Rust language that were effectively defined by arbitrary decisions made by the implementors, which aren't really spelled out anywhere besides the code.
  - tialaramex 3y ago
    Do you have examples? I think in many ways Rust is doing a better job of tying down the tricky details than C++ has. There is no effort to explain how pointer provenance works in C++ at all. The state of the art is if you write a provenance bug, someone from a compiler vendor will gesture at DR/260 which says provenance exists but WG14 (so C, not even C++) declines to explain how it works, and that's all you get. In contrast Aria's "Experiment" (https://doc.rust-lang.org/std/ptr/index.html#strict-provenance https://doc.rust-lang.org/std/ptr/index.html#strict-provenan...) has gone rather well. The vast majority of people who want to do acrobatics with pointers can do what Aria says you have to do to get coherent behaviour, and by following her rules they can make code which works in Rust.
    - uecker 3y ago
      WG14 produced a document clarifying provenance in C (which Aria knew): https://open-std.org/JTC1/SC22/WG14/www/docs/n3005.pdf https://open-std.org/JTC1/SC22/WG14/www/docs/n3005.pdf
      - tialaramex 3y ago
        Given your username, I assume I'm addressing Martin Uecker and I want to commend you for putting the work in on this problem over a long period. While a draft TS is closer to actually resolving a 20+ year old problem it's not there yet and this draft is, if you pardon me, in my opinion more than three months work from publishable. In contrast, Aria went from "We should see whether strict rules are workable" to the current set of Rust nightly features relatively quickly. If I want to attempt pointer stunts in C, N3005 is probably worth reading first, but it isn't actionable from what I can tell. Contrast Aria's changes, I can go try that (in nightly Rust) and see it works or why I can't / mustn't do what I wanted under Strict Provenance and who I ought to talk to about that. I wish you luck for C 29 (?) but that's a distant future, and we're contrasting C++ here, so as with #embed you might take this obvious must-have for C29 and find that somehow WG21 are still so far behind they can't do the same for C++ 29.
rapsey 3y ago
C++ versions are practically a new language. Last two Rust editions required no changes on any of my code. Why are people constantly harping on this obviously untrue idea. New Rust versions and editions make the language _simpler_.
- kaashif 3y ago
  > C++ versions are practically a new language. Last two Rust editions required no changes on any of my code. This juxtaposition kind of makes it seem like that new C++ versions did require changes to your code, did they? My understanding is that C++ maintains backwards compatibility.
  - rapsey 3y ago
    Rust editions are allowed to break backwards compatibility. If you have 2015 edition code and change your Cargo.toml and set it to 2021 edition, the code may no longer compile. My code went from 2015 to 2018 and 2021 by simply changing Cargo.toml. No code changes were necessary and it was still completely idiomatic code. Nothing was deprecated or even outdated. An idiomatic C++11 solution is not likely to be the idiomatic C++17 solution however. Every version of C++ makes deep changes to the actual language and adds a ton of features. Whereas Rust versions and editions tend to make the language simpler as they generally remove limitations.
    - Conscat 3y ago
      Every release of C++ since 11 has relaxed limitations on `constexpr`, and several relaxed limitations on `template`. Many other features have had various rules relaxed in certain releases, including `for` loops, lambdas, labels, moves, and atomics. It's true that there are usually new features which arguably make older code no longer idiomatic, but modernizing code is always optional, so what's really the issue there?
      - rapsey 3y ago
        The issue is the language gets more complex over time. The origin of the discussion was the statement Rust is just as complex as c++, which is completely wrong. Rust changes in small increments and even when they decide on a new edition that can break compatibility, it still barely changes.
duped 3y ago
Rust already has editions. There have been three releases since 1.0.

rust is _almost_ as complex as C++. Introducing these new "edition" would grow the complexity exponentially. I hope they would think twice about the effects on new learners before even experimenting

weinzierl 3y ago

"rust is _almost_ as complex as C++." I don't agree, but even if it were true, C++ has so much accidental complexity (because of its legacy) that you cannot meaningfully compare it with Rust, which by and large is very well thought out. In general, if something is complex in Rust that is because it's in the nature of the problem and not because of some quirkiness in the solution. Borrowing is the prime example. People find it complex, but just because the C++ compiler doesn't check the rules for you, doesn't mean you have follow them in C++ as well (which is tedious and error-prone) or know exactly why you don't have to follow them (which is even harder). I admit though, that the Leakpocalypse (which the article talks about, even if it doesn't call it like that) is an area where accidental complexity lurks.

vlovich123 3y ago
Pin is another one. I still can’t wrap my head around it. I’m sure it’s simple and the docs are great, but having read them multiple times I’m not really more clear. I probably need to see a bunch of hands on examples. I wish they’d gone the Move route instead of rushing to 1.0 and then retrofitting in Pin. But I agree, in general things in rust are a lot more thought out and experiments are relegated to unstable which is fine with breaking changes. I do wish though that they had a better versioning story in the language for making backward incompatible changes more a matter of course. It’s great already for “user space” code via editions, but as the author notes making certain kinds of changes brings up risk and uncertainty because there’s not a well trodden path to support changing core semantics in the language and having it work gracefully without needing a migration en masse.
- majewsky 3y ago
  > I wish they’d gone the Move route instead of rushing to 1.0 and then retrofitting in Pin. That is easy to say, and I don't disagree with the sentiment, but there are valid reasons for setting a 1.0 release date and cutting corners to get there. If they had not done that, there probably was a real risk of running an infinite loop of "let's wait for Move to be implemented", "great, now let's wait for Leak to be implemented", "great, now let's wait for..." and a 1.0 never gets put out. Rust may not be perfect, but at least it's stable and people are actually using it.
- cmrdporcupine 3y ago
  Pin used to confuse me, but now it's clearer. It's right in the name: Pin this thing to where it is in memory, never try to move it. Rust can and does move things around as it feels the need. So you need something like Pin if what you've built can't move. It's confusing if you're coming from a C++ background because in C++ something only "moves" if you explicitly std::move it. In Rust its effectively the reverse. A crude way of thinking about Rust's call pattern is that it's basically the opposite: as if every call was a std::move operation. So Pin is basically just saying: you can't move this, don't try. The memory can't be moved. And it's mostly used in corner cases where some kind of explicit memory management is involved. Most Rust users should not have to worry about it. It's one of those things that becomes more of a concern if you're writing library code for low level datastructures, or interfacing with C/C++ libraries.
  - laurencerowe 3y ago
    > Most Rust users should not have to worry about it. It's one of those things that becomes more of a concern if you're writing library code for low level datastructures, or interfacing with C/C++ libraries. Don’t all Rust users writing async code have to worry about Pin?
    - brigadier132 3y ago
      Not really, the async libraries hide the implementation details from you. It's an issue for library developers.
cwzwarich 3y ago
One advantage C++ has over Rust is that there are multiple fairly compliant C++ implementations, and the process of making them created some shared understanding of how the language actually works from an implementation perspective. There are several aspects of the current Rust language that were effectively defined by arbitrary decisions made by the implementors, which aren't really spelled out anywhere besides the code.
- tialaramex 3y ago
  Do you have examples? I think in many ways Rust is doing a better job of tying down the tricky details than C++ has. There is no effort to explain how pointer provenance works in C++ at all. The state of the art is if you write a provenance bug, someone from a compiler vendor will gesture at DR/260 which says provenance exists but WG14 (so C, not even C++) declines to explain how it works, and that's all you get. In contrast Aria's "Experiment" (https://doc.rust-lang.org/std/ptr/index.html#strict-provenance https://doc.rust-lang.org/std/ptr/index.html#strict-provenan...) has gone rather well. The vast majority of people who want to do acrobatics with pointers can do what Aria says you have to do to get coherent behaviour, and by following her rules they can make code which works in Rust.
  - uecker 3y ago
    WG14 produced a document clarifying provenance in C (which Aria knew): https://open-std.org/JTC1/SC22/WG14/www/docs/n3005.pdf https://open-std.org/JTC1/SC22/WG14/www/docs/n3005.pdf
    - tialaramex 3y ago
      Given your username, I assume I'm addressing Martin Uecker and I want to commend you for putting the work in on this problem over a long period. While a draft TS is closer to actually resolving a 20+ year old problem it's not there yet and this draft is, if you pardon me, in my opinion more than three months work from publishable. In contrast, Aria went from "We should see whether strict rules are workable" to the current set of Rust nightly features relatively quickly. If I want to attempt pointer stunts in C, N3005 is probably worth reading first, but it isn't actionable from what I can tell. Contrast Aria's changes, I can go try that (in nightly Rust) and see it works or why I can't / mustn't do what I wanted under Strict Provenance and who I ought to talk to about that. I wish you luck for C 29 (?) but that's a distant future, and we're contrasting C++ here, so as with #embed you might take this obvious must-have for C29 and find that somehow WG21 are still so far behind they can't do the same for C++ 29.

rapsey 3y ago

C++ versions are practically a new language. Last two Rust editions required no changes on any of my code. Why are people constantly harping on this obviously untrue idea. New Rust versions and editions make the language _simpler_.

kaashif 3y ago
> C++ versions are practically a new language. Last two Rust editions required no changes on any of my code. This juxtaposition kind of makes it seem like that new C++ versions did require changes to your code, did they? My understanding is that C++ maintains backwards compatibility.
- rapsey 3y ago
  Rust editions are allowed to break backwards compatibility. If you have 2015 edition code and change your Cargo.toml and set it to 2021 edition, the code may no longer compile. My code went from 2015 to 2018 and 2021 by simply changing Cargo.toml. No code changes were necessary and it was still completely idiomatic code. Nothing was deprecated or even outdated. An idiomatic C++11 solution is not likely to be the idiomatic C++17 solution however. Every version of C++ makes deep changes to the actual language and adds a ton of features. Whereas Rust versions and editions tend to make the language simpler as they generally remove limitations.
  - Conscat 3y ago
    Every release of C++ since 11 has relaxed limitations on `constexpr`, and several relaxed limitations on `template`. Many other features have had various rules relaxed in certain releases, including `for` loops, lambdas, labels, moves, and atomics. It's true that there are usually new features which arguably make older code no longer idiomatic, but modernizing code is always optional, so what's really the issue there?
    - rapsey 3y ago
      The issue is the language gets more complex over time. The origin of the discussion was the statement Rust is just as complex as c++, which is completely wrong. Rust changes in small increments and even when they decide on a new edition that can break compatibility, it still barely changes.

duped 3y ago

Rust already has editions. There have been three releases since 1.0.