4 ms·

At this point, why not write Rust instead? I know, C++ is a dirty snowball rolling downhill, gobbling up every feature it can put its tendrils on, and always h

At this point, why not write Rust instead? I know, C++ is a dirty snowball rolling downhill, gobbling up every feature it can put its tendrils on, and always has been, but it is getting silly.

adev_ 7y ago
> I know, C++ is a dirty snowball rolling downhill, gobbling up every feature it can put it's tendrils on, and always has been, but it is getting silly. That's named evolving and improving. And that's how a language stay alive.
- Dylan16807 7y ago
  If you never remove features, but keep adding more steadily, 'evolving and improving' is the wrong way to describe it.
  - yarrel 7y ago
    C++ treats backwards compatibility as important. New code doesn't have to use old features.
    - Dylan16807 7y ago
      > New code doesn't have to use old features. Yeah but it's hard to manage in multiple ways. Is there good tooling to help? And it means a lot of references you could normally check are using features you can't use. Plus none of your libraries are going to agree on what parts to use.
  - Analemma_ 7y ago
    Removing features from a programming language is almost impossible; it breaks backwards compatibility and so is a hard barrier to upgrading from the old version. Note the 12-year-and-counting struggle to adopt Python 3, or the fact that Perl 6 developers gave up completely trying to get people to upgrade from Perl 5 and just rebranded it as a new language instead. C++ has opted to avoid those struggles by never removing features; you can disagree with that decision but it was done for good reasons.
    - shortoncash 7y ago
      I'm speaking strictly technical here, but there have been features that have been removed. Trigraphs (I think), and the register keyword. Moreover, there are objects that are very clearly marked deprecated, like auto_ptr. (Oh, and there is even talk of removing 'volatile' as a keyword.) The register keyword issue crops up because legacy code included and linked to modern C++ will occasionally have the word "register" affixed to a loop variable. Generally speaking, once you change standards, there is room to drop the old stuff. It's just gradual. Static analyzers do a lot to modernize code now too, so the situation is not as painful as it used to be.
      - favorited 7y ago
        The `volatile` deprecation is more about providing new library features to do the things people (incorrectly) use `volatile` for today. `volatile` will still have legitimate use-cases.
    - nicoburns 7y ago
      On the other hand, JavaScript very successfully added strict mode that removed features like `eval`. The trick seems to be to ensure that "old code" and "new code" can live side-by-side during a transition period.
      - favorited 7y ago
        Vittorio Romeo has been proposing[0] an "epochs" feature for C++ which would enable modes like "strict." This would let them define things like const-by-default, requiring nulltpr instead of 0, etc. He's facing some resistance by other WG21 members. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p188...
    - lizmat 7y ago
      > the fact that Perl 6 developers gave up completely trying to get people to upgrade from Perl 5 and just rebranded it as a new language instead This statement does not do justice to the process that led to the renaming of "Perl 6" to "The Raku Programming Language". If you are interested in the process, https://github.com/Raku/problem-solving/issues/81 https://github.com/Raku/problem-solving/issues/81 will give you some of the discussion that happened online.
  - pjmlp 7y ago
    C++ did remove features already a couple of times. gets(), exception specifications, semantic corrections for a couple of cases like decltype vs auto, auto original meaning, std::bind(), and several others However they don't play a Python 3, and rather take the effort to minimize the impact of those changes.
dgellow 7y ago
Even if you don't care about the language itself, there is a giant amount of C++ in the wild that won't be reimplemented. Anything that can make that code safer is a huge win.
- thrower123 7y ago
  How much of that existing code, really, is ever going to be updated to the standard of even C++11?
  - UncleMeat 7y ago
    A lot of it won’t. But the interop story between modern cpp and older cpp is much better than the interop story between rust and older cpp.
  - seren 7y ago
    I am working on a device, where the initial code was written in 1995-1997 on a pre cpp98 compiler, the code has recently been updated to cpp11, I am sure we will move to cpp14/17 soon. So this is slowly but steadily moving, even if very conservatively. On the other hand, Hell would freeze over before you could convince the business to throw the cpp codebase and replace it by anything else, without necessarily a lot of things to show to the customer. And as much as we like to criticize business decisions, here it is probably the right call. However, if you are startup starting today, it would probably be a good idea to consider other options, that could be used as an advantage against incumbents.
  - grandinj 7y ago
    There are 10 million lines of libreoffice code that has been updated to use these features
  - pjmlp 7y ago
    Plenty, AUTOSAR now requires C++14 compliance for example. Lots of code might not be updated, thing is, with C++20 I still get to compile my pre-C++98 code. Even taking into account the breaking changes between language revisions, they are quite minor versus writing into another language. Plus there are still lots of stuff missing, like a proper GUI library that can even compete with MFC, OWL, let alone something like UWP or Qt.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
pjmlp 7y ago
Because as much as I like Rust, it doesn't provide the IDE tooling for mixing language development with Java and .NET stacks, the seamless tooling that for creating COM/UWP components, something like Unreal or Unity for weekend coding hobbies, still builds slower than C++ because cargo doesn't support yet binary dependencies. For writing memory safe code I already have .NET and JVM set of programming languages, so when I need to go outside of these platforms, I rather pick the tool that provides zero attrition with the existing tooling. These are all issues that will be fixed, but they aren't yet there.

At this point, why not write Rust instead? I know, C++ is a dirty snowball rolling downhill, gobbling up every feature it can put its tendrils on, and always has been, but it is getting silly.

adev_ 7y ago

> I know, C++ is a dirty snowball rolling downhill, gobbling up every feature it can put it's tendrils on, and always has been, but it is getting silly. That's named evolving and improving. And that's how a language stay alive.

Dylan16807 7y ago
If you never remove features, but keep adding more steadily, 'evolving and improving' is the wrong way to describe it.
- yarrel 7y ago
  C++ treats backwards compatibility as important. New code doesn't have to use old features.
  - Dylan16807 7y ago
    > New code doesn't have to use old features. Yeah but it's hard to manage in multiple ways. Is there good tooling to help? And it means a lot of references you could normally check are using features you can't use. Plus none of your libraries are going to agree on what parts to use.
- Analemma_ 7y ago
  Removing features from a programming language is almost impossible; it breaks backwards compatibility and so is a hard barrier to upgrading from the old version. Note the 12-year-and-counting struggle to adopt Python 3, or the fact that Perl 6 developers gave up completely trying to get people to upgrade from Perl 5 and just rebranded it as a new language instead. C++ has opted to avoid those struggles by never removing features; you can disagree with that decision but it was done for good reasons.
  - shortoncash 7y ago
    I'm speaking strictly technical here, but there have been features that have been removed. Trigraphs (I think), and the register keyword. Moreover, there are objects that are very clearly marked deprecated, like auto_ptr. (Oh, and there is even talk of removing 'volatile' as a keyword.) The register keyword issue crops up because legacy code included and linked to modern C++ will occasionally have the word "register" affixed to a loop variable. Generally speaking, once you change standards, there is room to drop the old stuff. It's just gradual. Static analyzers do a lot to modernize code now too, so the situation is not as painful as it used to be.
    - favorited 7y ago
      The `volatile` deprecation is more about providing new library features to do the things people (incorrectly) use `volatile` for today. `volatile` will still have legitimate use-cases.
  - nicoburns 7y ago
    On the other hand, JavaScript very successfully added strict mode that removed features like `eval`. The trick seems to be to ensure that "old code" and "new code" can live side-by-side during a transition period.
    - favorited 7y ago
      Vittorio Romeo has been proposing[0] an "epochs" feature for C++ which would enable modes like "strict." This would let them define things like const-by-default, requiring nulltpr instead of 0, etc. He's facing some resistance by other WG21 members. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p188...
  - lizmat 7y ago
    > the fact that Perl 6 developers gave up completely trying to get people to upgrade from Perl 5 and just rebranded it as a new language instead This statement does not do justice to the process that led to the renaming of "Perl 6" to "The Raku Programming Language". If you are interested in the process, https://github.com/Raku/problem-solving/issues/81 https://github.com/Raku/problem-solving/issues/81 will give you some of the discussion that happened online.
- pjmlp 7y ago
  C++ did remove features already a couple of times. gets(), exception specifications, semantic corrections for a couple of cases like decltype vs auto, auto original meaning, std::bind(), and several others However they don't play a Python 3, and rather take the effort to minimize the impact of those changes.

dgellow 7y ago

Even if you don't care about the language itself, there is a giant amount of C++ in the wild that won't be reimplemented. Anything that can make that code safer is a huge win.

thrower123 7y ago
How much of that existing code, really, is ever going to be updated to the standard of even C++11?
- UncleMeat 7y ago
  A lot of it won’t. But the interop story between modern cpp and older cpp is much better than the interop story between rust and older cpp.
- seren 7y ago
  I am working on a device, where the initial code was written in 1995-1997 on a pre cpp98 compiler, the code has recently been updated to cpp11, I am sure we will move to cpp14/17 soon. So this is slowly but steadily moving, even if very conservatively. On the other hand, Hell would freeze over before you could convince the business to throw the cpp codebase and replace it by anything else, without necessarily a lot of things to show to the customer. And as much as we like to criticize business decisions, here it is probably the right call. However, if you are startup starting today, it would probably be a good idea to consider other options, that could be used as an advantage against incumbents.
- grandinj 7y ago
  There are 10 million lines of libreoffice code that has been updated to use these features
- pjmlp 7y ago
  Plenty, AUTOSAR now requires C++14 compliance for example. Lots of code might not be updated, thing is, with C++20 I still get to compile my pre-C++98 code. Even taking into account the breaking changes between language revisions, they are quite minor versus writing into another language. Plus there are still lots of stuff missing, like a proper GUI library that can even compete with MFC, OWL, let alone something like UWP or Qt.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

pjmlp 7y ago

Because as much as I like Rust, it doesn't provide the IDE tooling for mixing language development with Java and .NET stacks, the seamless tooling that for creating COM/UWP components, something like Unreal or Unity for weekend coding hobbies, still builds slower than C++ because cargo doesn't support yet binary dependencies. For writing memory safe code I already have .NET and JVM set of programming languages, so when I need to go outside of these platforms, I rather pick the tool that provides zero attrition with the existing tooling. These are all issues that will be fixed, but they aren't yet there.