9 ms·

Rust is basically the wanted fixes to C++ that C++ itself could never adopt for legacy reasons. So I'm afraid no by definition C++ can't adopt Rust's ideas bec

Rust is basically the wanted fixes to C++ that C++ itself could never adopt for legacy reasons. So I'm afraid no by definition C++ can't adopt Rust's ideas because Rust's ideas were originally impossible C++ ideas.

fooker 1y ago
> C++ itself could never adopt for legacy reasons. I agree with your point except for the 'never' qualifier. It was certainly true when Rust was born. C++ has proven the 'never' part wrong multiple times. I think, by 2030, the only thing that C++ would lack that Rust has right now is the unified toolchain/packaging ecosystem because people are not going to settle that debate. Everything else is well on its way to be implemented, in one of three forms - core language features (eg: concepts), language features that primarily enable writing more powerful libraries so that you do not have to come up with language features for everything (eg: reflection), and finally tooling support from the compiler as a test bed of what the language could guarantee (lifetime checks and annotations in clang). Of course Rust is innovating pretty well too, I am very interested in seeing what async/coroutines are going to look like in a few years.
- ninkendo 1y ago
  C++ can never change the way move vs copy semantics work, which is precisely the opposite of Rust’s. It’s the basis for rust’s ownership model, and it’s no small difference. Without this I don’t see how C++ can ever get a workable ownership model like Rust’s.
  - fooker 1y ago
    C++ just gives you the option to have it both ways. You are free to design your library in a way that your users only see one of these.
    - tialaramex 1y ago
      What developers actually wanted, even years back when C++ didn't have anything named "move" was the destructive move semantic. It's an elegant, easy to understand feature for a language. I like it very much in Rust which has it. C++ didn't get that. The proposal paper at the time says it's impossible (for C++). But what they did propose was the feature you've seen in C++ today, which they call "move", but it has slightly odd (though convenient to implement, Worse Is Better after all) behaviour. Now you can make this C++ "move" behaviour out of destructive move, that behaviour is roughly what Rust calls std::mem::take and it's sometimes useful, which is why that function is provided. But, often it's not really what you wanted, and if you actually wanted destructive move but only have this C++ imposter then you need to perform the entire take, then throw away the newly created object. You will find lots of C++ code doing exactly that. So, no, you can't "design your library" to deliver the desirable property in C++. It's just another of the dozens of nagging pains because of design mistakes C++ won't fix.
      - fooker 1y ago
        I am still confused about what you are claiming to be not possible in C++ when you are designing your library. Yes, I understand that there’s a lot of bad code out there and C++ happily enables that. But that was not my point.
        tialaramex 1y ago
        Maybe it will be clearer if you read and understand my favourite function from Rust's standard library (its full name is core::mem::drop) pub fn drop<T>(_x: T) {}
        fooker 1y ago
        Great. template <typename T> void drop(std::unique_ptr<T> &&) {} Also, you don’t really need this because of RAII. You can make it simpler, and here’s how you’d do this in C++26. template <std::movable T> void drop(T &&) {} It can get even simpler! void drop(std::movable auto){} Do you see my point about C++ incorporating the good ideas at a glacial pace?
- tialaramex 1y ago
  Concepts is a particularly hilarious example because what you got in C++ 20 is Bjarne's "Concepts Lite". Bjarne worked quite hard to get rid of the ideas and people behind the much more powerful C++ 0x Concepts, which resembles Rust's trait feature, and then it took a decade to land his worse alternative. That actually is a microcosmic survey of the problem with the language.
  - fooker 1y ago
    So what you’re saying is that it takes time, but works out? I agree.
    - aw1621107 1y ago
      > So what you’re saying is that it takes time, but works out? Probably depends on what you mean by "works out". I don't think GP would agree that delivering a less capable alternative qualifies. For example, one major feature C++0x concepts was supposed to have but got removed was definition-time checking - i.e., checking that your template only used capabilities promised by the concepts it uses, so if you defined a template with concepts you could be assured that if the definition compiled it'd work with all types that satisfied the concept. That feature did not make it to C++20 concepts and as far as I know there are no plans on the horizon to add that feature.
      - fooker 1y ago
        C++0x was ~5 years ago. C++26 concepts has more or less everything you mention, and you can try it out with all the major compilers right now.
        tialaramex 1y ago
        First lets clear up a thing I've seen a few times on HN probably from people who are new enough to simply not have run into this before. C++ 0x is what people called the proposed new C++ language standard from about 2005 through 2009 or so under the belief that maybe it would ship in 2008 or 2009. Because you're here, now, you know this didn't end up happening and actually the next standard would be C++ 11. For a little while they even jokingly talked about C++ 0A where A is of course hexadecimal for ten, but by the time it was clear it wouldn't even make 2010 that wasn't funny. So C++ 0x isn't five years ago, it's about 15-20 years ago and in this context it's about the draft revision of C++ in which for some time the Concepts feature existed, but Bjarne insisted that this feature (which remember is roughly Rust's traits) was not implementable in reasonable time, and frankly was not as much needed as people had believed. This argument swayed enough committee members that Concepts was ripped back out of the draft document, and so C++ 11 does not have Concepts of any sort. Because this particular history is from the relatively recent past you can go read the proposal documents, there might even be Youtube videos about it. OK, so, now you at least know what these terms mean when other people use them, that can't hurt. As to your next claim er, no, not even close. Barry Revzin wrote a really nice paper connecting the dots on this, which probably passed into legend specifically for saying hey C++ 0x Concepts are the same thing as Rust traits. C++ proposal paper P2279 is what you're looking for if that interests you. That'll be less confusing for you now because you know what "C++ 0x" even means. Now, Barry wrote that paper in the C++ 23 cycle, and we're now at / just past the end of the C++ 26 cycle, but I assure you that nothing relevant has changed. You can't magically have model checking in C++ that's not there. You can't provide concept maps, it's not in the language and so on.
flohofwoe 1y ago
Rust has been copying plenty of bad features from C++ too though.
- fooker 1y ago
  I think this is the trap that turned away many people from D.

fooker 1y ago

> C++ itself could never adopt for legacy reasons. I agree with your point except for the 'never' qualifier. It was certainly true when Rust was born. C++ has proven the 'never' part wrong multiple times. I think, by 2030, the only thing that C++ would lack that Rust has right now is the unified toolchain/packaging ecosystem because people are not going to settle that debate. Everything else is well on its way to be implemented, in one of three forms - core language features (eg: concepts), language features that primarily enable writing more powerful libraries so that you do not have to come up with language features for everything (eg: reflection), and finally tooling support from the compiler as a test bed of what the language could guarantee (lifetime checks and annotations in clang). Of course Rust is innovating pretty well too, I am very interested in seeing what async/coroutines are going to look like in a few years.

ninkendo 1y ago
C++ can never change the way move vs copy semantics work, which is precisely the opposite of Rust’s. It’s the basis for rust’s ownership model, and it’s no small difference. Without this I don’t see how C++ can ever get a workable ownership model like Rust’s.
- fooker 1y ago
  C++ just gives you the option to have it both ways. You are free to design your library in a way that your users only see one of these.
  - tialaramex 1y ago
    What developers actually wanted, even years back when C++ didn't have anything named "move" was the destructive move semantic. It's an elegant, easy to understand feature for a language. I like it very much in Rust which has it. C++ didn't get that. The proposal paper at the time says it's impossible (for C++). But what they did propose was the feature you've seen in C++ today, which they call "move", but it has slightly odd (though convenient to implement, Worse Is Better after all) behaviour. Now you can make this C++ "move" behaviour out of destructive move, that behaviour is roughly what Rust calls std::mem::take and it's sometimes useful, which is why that function is provided. But, often it's not really what you wanted, and if you actually wanted destructive move but only have this C++ imposter then you need to perform the entire take, then throw away the newly created object. You will find lots of C++ code doing exactly that. So, no, you can't "design your library" to deliver the desirable property in C++. It's just another of the dozens of nagging pains because of design mistakes C++ won't fix.
    - fooker 1y ago
      I am still confused about what you are claiming to be not possible in C++ when you are designing your library. Yes, I understand that there’s a lot of bad code out there and C++ happily enables that. But that was not my point.
      - tialaramex 1y ago
        Maybe it will be clearer if you read and understand my favourite function from Rust's standard library (its full name is core::mem::drop) pub fn drop<T>(_x: T) {}
        fooker 1y ago
        Great. template <typename T> void drop(std::unique_ptr<T> &&) {} Also, you don’t really need this because of RAII. You can make it simpler, and here’s how you’d do this in C++26. template <std::movable T> void drop(T &&) {} It can get even simpler! void drop(std::movable auto){} Do you see my point about C++ incorporating the good ideas at a glacial pace?
tialaramex 1y ago
Concepts is a particularly hilarious example because what you got in C++ 20 is Bjarne's "Concepts Lite". Bjarne worked quite hard to get rid of the ideas and people behind the much more powerful C++ 0x Concepts, which resembles Rust's trait feature, and then it took a decade to land his worse alternative. That actually is a microcosmic survey of the problem with the language.
- fooker 1y ago
  So what you’re saying is that it takes time, but works out? I agree.
  - aw1621107 1y ago
    > So what you’re saying is that it takes time, but works out? Probably depends on what you mean by "works out". I don't think GP would agree that delivering a less capable alternative qualifies. For example, one major feature C++0x concepts was supposed to have but got removed was definition-time checking - i.e., checking that your template only used capabilities promised by the concepts it uses, so if you defined a template with concepts you could be assured that if the definition compiled it'd work with all types that satisfied the concept. That feature did not make it to C++20 concepts and as far as I know there are no plans on the horizon to add that feature.
    - fooker 1y ago
      C++0x was ~5 years ago. C++26 concepts has more or less everything you mention, and you can try it out with all the major compilers right now.
      - tialaramex 1y ago
        First lets clear up a thing I've seen a few times on HN probably from people who are new enough to simply not have run into this before. C++ 0x is what people called the proposed new C++ language standard from about 2005 through 2009 or so under the belief that maybe it would ship in 2008 or 2009. Because you're here, now, you know this didn't end up happening and actually the next standard would be C++ 11. For a little while they even jokingly talked about C++ 0A where A is of course hexadecimal for ten, but by the time it was clear it wouldn't even make 2010 that wasn't funny. So C++ 0x isn't five years ago, it's about 15-20 years ago and in this context it's about the draft revision of C++ in which for some time the Concepts feature existed, but Bjarne insisted that this feature (which remember is roughly Rust's traits) was not implementable in reasonable time, and frankly was not as much needed as people had believed. This argument swayed enough committee members that Concepts was ripped back out of the draft document, and so C++ 11 does not have Concepts of any sort. Because this particular history is from the relatively recent past you can go read the proposal documents, there might even be Youtube videos about it. OK, so, now you at least know what these terms mean when other people use them, that can't hurt. As to your next claim er, no, not even close. Barry Revzin wrote a really nice paper connecting the dots on this, which probably passed into legend specifically for saying hey C++ 0x Concepts are the same thing as Rust traits. C++ proposal paper P2279 is what you're looking for if that interests you. That'll be less confusing for you now because you know what "C++ 0x" even means. Now, Barry wrote that paper in the C++ 23 cycle, and we're now at / just past the end of the C++ 26 cycle, but I assure you that nothing relevant has changed. You can't magically have model checking in C++ that's not there. You can't provide concept maps, it's not in the language and so on.

flohofwoe 1y ago

Rust has been copying plenty of bad features from C++ too though.

fooker 1y ago
I think this is the trap that turned away many people from D.