6 ms·

C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.

by fooker 1y ago

Philpax 1y ago
A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add, but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant` is, as far as I know, still limited, even in newer C++ code, because the ergonomics just aren't there.
- fooker 1y ago
  optional is heavily used in new codebases. variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. C++ does have quite a bit of rot, you're right. But that's the price of building technology people actually use. Carbon doesn't seem to have any fundamentally new ideas, we'll see how well it fares in the wild.
  - ghosty141 1y ago
    > variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. Thats the fantastic thing about c++, you can already write an easy to use match, but they just chose not to include that in the stdlib but rather want you write that yourself. Example: match(foo, [](Foo&) { }, [&](Bar& bar) { }, [&](const auto& mode) { // catch all }); Also optional and expected are ergonomic nightmares since there is no "try!" macro like rust has. In general it lacks the infrastructure that is needed to make these types nice to use. It also clashes with other concepts like RAII where you kinda have to use exceptions when it comes to ctors that may fail.
    - fooker 1y ago
      It would be pretty ugly to make this more introspective in C++. For example, if you had to match patterns to distinguish between these three possibilities when looking at a tree: (val), (val (tree left) (tree right)), (val (tree subtree)). Here, the possibilities are not really separate types, but rather different ways of constructing a type. This sort of pattern shows up in general purpose programming (even meat and potato imperative programming) pretty often. There was a proposal for this championed by Stroustrup over ten years ago, but it went nowhere IIRC. https://www.stroustrup.com/pattern-matching-November-2014.pdf https://www.stroustrup.com/pattern-matching-November-2014.pd...
    - tialaramex 1y ago
      The try! macro was deprecated in 2019 so, almost six years ago. And even before formal deprecation the word try is now a keyword and so you'd need to use r#try! to say you want the obsolete macro not the keyword.
- account42 1y ago
  Ergonomics of std::optional and std::variant have nothing to do with bad foundations and all to do with the C++ committee insisting on these being library features rather than language features. I'm sure we will get the syntactic sugar eventually like we did get range-based for loops after having had to deal with macro approximations of foreach forever.
  - fooker 1y ago
    You’re right. I have some hope that the upcoming compile time reflection will make it easier to implement said syntactic sugar.
ReflectedImage 1y ago
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.
flohofwoe 1y ago
...and unfortunately butchering those good features beyond recognition, see C++20 vs C99 designated init. Typical "design by committee" outcome though :/
- fooker 1y ago
  Agreed. Design by committee has been the thorn for a long time, hence efforts like Carbon, Circle, and cpp2. But as it stands, I expect that whatever innovations these languages produce will be picked up by C++ in ~5 years.

C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.

by fooker 1y ago

C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.

A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add, but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant` is, as far as I know, still limited, even in newer C++ code, because the ergonomics just aren't there.

fooker 1y ago
optional is heavily used in new codebases. variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. C++ does have quite a bit of rot, you're right. But that's the price of building technology people actually use. Carbon doesn't seem to have any fundamentally new ideas, we'll see how well it fares in the wild.
- ghosty141 1y ago
  > variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. Thats the fantastic thing about c++, you can already write an easy to use match, but they just chose not to include that in the stdlib but rather want you write that yourself. Example: match(foo, [](Foo&) { }, [&](Bar& bar) { }, [&](const auto& mode) { // catch all }); Also optional and expected are ergonomic nightmares since there is no "try!" macro like rust has. In general it lacks the infrastructure that is needed to make these types nice to use. It also clashes with other concepts like RAII where you kinda have to use exceptions when it comes to ctors that may fail.
  - fooker 1y ago
    It would be pretty ugly to make this more introspective in C++. For example, if you had to match patterns to distinguish between these three possibilities when looking at a tree: (val), (val (tree left) (tree right)), (val (tree subtree)). Here, the possibilities are not really separate types, but rather different ways of constructing a type. This sort of pattern shows up in general purpose programming (even meat and potato imperative programming) pretty often. There was a proposal for this championed by Stroustrup over ten years ago, but it went nowhere IIRC. https://www.stroustrup.com/pattern-matching-November-2014.pdf https://www.stroustrup.com/pattern-matching-November-2014.pd...
  - tialaramex 1y ago
    The try! macro was deprecated in 2019 so, almost six years ago. And even before formal deprecation the word try is now a keyword and so you'd need to use r#try! to say you want the obsolete macro not the keyword.
account42 1y ago
Ergonomics of std::optional and std::variant have nothing to do with bad foundations and all to do with the C++ committee insisting on these being library features rather than language features. I'm sure we will get the syntactic sugar eventually like we did get range-based for loops after having had to deal with macro approximations of foreach forever.
- fooker 1y ago
  You’re right. I have some hope that the upcoming compile time reflection will make it easier to implement said syntactic sugar.

ReflectedImage 1y ago

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.

flohofwoe 1y ago

...and unfortunately butchering those good features beyond recognition, see C++20 vs C99 designated init. Typical "design by committee" outcome though :/

fooker 1y ago
Agreed. Design by committee has been the thorn for a long time, hence efforts like Carbon, Circle, and cpp2. But as it stands, I expect that whatever innovations these languages produce will be picked up by C++ in ~5 years.