4 ms·

The trouble with C++ is that it maintains backward compatibility with C++.

HarHarVeryFunny 9mo ago
I suppose so, but I think it's relatively rare for languages to just drop support for older features and force developers to rewrite code using newer mechanisms. Python 2 to 3 is a good example of what can be expected to happen - very slow adoption of the new version since companies may just not have the resources or desire to rewrite existing code that is running without problems.
- tialaramex 9mo ago
  Late in the C++ 20 timeline P1881 Epochs were proposed. Similar to Rust's editions, which at that time had been tried in anger only once (2018 Edition) this proposed that there should be a way for C++ to evolve, forbidding obsolete syntax in newer projects rather than just growing forever like cancer. Epochs was given the usual WG21 treatment and that's the end of that. Rust shipped 2021 Edition, and 2024 Edition, and I see no reason to think 2027 Edition won't happen. The current iteration of Bjarne's "Profiles" idea is in a similar ballpark though it got there via a very different route. This time because it will aid safety to outlaw things that are now considered a bad idea. If this goes anywhere its nearest ship vehicle is C++ 29. Now, Python 2 to Python 3 did take a few years, maybe a decade. But just shipping the mechanism to reform C++ looks likely to take at least nine years. Not the reform, just the mechanism to enable it.
  - pjmlp 9mo ago
    Meanwhile editions still don't have an answer for semantics changes exposed on public APIs for crates, each compiled on its own edition. So what does the compiler chose, the edition of the caller, or the caller?
    - tialaramex 9mo ago
      I don't understand the question, maybe you have an example?
      - pjmlp 9mo ago
        In general, even though semantic changes haven't yet been a thing in editions so far. Crate A uses edition X. Crate B uses edition Y + N, which has broken Rust language semantics between those editions, or changed a standard library type that Crate A uses on its public API in a backwards incompatible way. Now an application on edition Y + M, with M >= N, would like to depend on Crate A and Crate B, and calling that incompatible API would be a requirement for the implementation goal. So far editions haven't bothered covering such cases, deemed as not worthwhile thinking about. Those in such scenarios get to hunt for another crate to replace Crate A, or have a local fork.
        tialaramex 9mo ago
        OK, so you don't have any examples, I recommend coming back once you have an example as otherwise there's nothing concrete to engage with here.
        pjmlp 9mo ago
        That was the example, now if you rather want to play defensive instead of engaging into a meaningful discussion about the Rust approach to language versioning and its constraints, well it is as it is.
        simonask 9mo ago
        I think it would be useful to give an example of the kind of semantics that would be desirable to change, and where people might think that it should be possible to change at an edition boundary. I’m not very sure, but maybe something like unforgettable types? Or linear types? Maybe negative trait bounds, or specialization?
- aw1621107 9mo ago
  > Python 2 to 3 is a good example of what can be expected to happen People keep bringing this up when discussing backwards compatibility breaks, but I think the conclusion should be a bit more nuanced than just "backwards compatibility break <=> years (decades?) of pain". IMHO, the problem was the backwards compatibility break coupled with the inability to use Python 2 code from 3 and vice versa. This meant that not only did you need to migrate your own code, but you also needed everything you depend on to also support Python 3. This applied in reverse as well - if you as a library developer naively upgraded to Python 3, that left your Python 2 consumers behind. Obviously the migration story got better over time with improvements to 2to3, six, etc., that allowed a single codebase to work under both Python 2 and 3, but I think the big takeaway here is that backwards compatibility breaks can be made much more friendly as long as upgrades can be performed independently of each other.
- patrick451 9mo ago
  Python3 drops support for older versions of python3 all the time. Every single release comes with a bunch of deprecated and removed features. There is a very strong chance that a python 3.7 codebase is totally broken on 3.14. Almost no language takes backwards compatibility as seriously as c++ does.
  - HarHarVeryFunny 9mo ago
    It's an interesting policy decision for a language - whether to guarantee (or at least practice) ongoing backwards compatibility or not. The benefit of NOT maintaining backwards compatibility is that hopefully you end up with a cleaner language without all the baggage of the past, and "impedence mismatches" of new features that don't play well with old ones, etc, etc. However, as a developer, I think I prefer the backwards compatible approach, knowing that: 1) Upgrading to latest version of the compiler hopefully isn't a big deal, and I can take advantage of any benefits that brings, including new language features, without having to sign up for rewriting existing tested code to remove deprecated features. In a large code base any such forced rewrites could be pretty onerous, and may involve a lot of retesting and potential for introducing bugs into code that was previously working. 2) It's nice to be able to take older projects, that you haven't worked on in a while (whether hobby projects, or legacy corporate code) and have the code still compile with the latest installed tool set, rather than to have developed "bit rot" due to using language features that have since been deprecated. Of course bit rot may also occur due to library changes, so language backwards compatibility is no guarantee of smooth sailing. Maybe going forwards, with AI coding tools, this will become less of an issue, if they become capable of this sort of codebase updates without introducing errors. In fact, going forwards it may well be that choice of programming languages itself becomes seen as more something the tooling takes care of. Nowadays we write in high level languages and don't really think or care about what the generated machine code looks like. Maybe in the future we can write in high level instructions to the AI, without even having to care what the implementation language is?

I suppose so, but I think it's relatively rare for languages to just drop support for older features and force developers to rewrite code using newer mechanisms. Python 2 to 3 is a good example of what can be expected to happen - very slow adoption of the new version since companies may just not have the resources or desire to rewrite existing code that is running without problems.

tialaramex 9mo ago
Late in the C++ 20 timeline P1881 Epochs were proposed. Similar to Rust's editions, which at that time had been tried in anger only once (2018 Edition) this proposed that there should be a way for C++ to evolve, forbidding obsolete syntax in newer projects rather than just growing forever like cancer. Epochs was given the usual WG21 treatment and that's the end of that. Rust shipped 2021 Edition, and 2024 Edition, and I see no reason to think 2027 Edition won't happen. The current iteration of Bjarne's "Profiles" idea is in a similar ballpark though it got there via a very different route. This time because it will aid safety to outlaw things that are now considered a bad idea. If this goes anywhere its nearest ship vehicle is C++ 29. Now, Python 2 to Python 3 did take a few years, maybe a decade. But just shipping the mechanism to reform C++ looks likely to take at least nine years. Not the reform, just the mechanism to enable it.
- pjmlp 9mo ago
  Meanwhile editions still don't have an answer for semantics changes exposed on public APIs for crates, each compiled on its own edition. So what does the compiler chose, the edition of the caller, or the caller?
  - tialaramex 9mo ago
    I don't understand the question, maybe you have an example?
    - pjmlp 9mo ago
      In general, even though semantic changes haven't yet been a thing in editions so far. Crate A uses edition X. Crate B uses edition Y + N, which has broken Rust language semantics between those editions, or changed a standard library type that Crate A uses on its public API in a backwards incompatible way. Now an application on edition Y + M, with M >= N, would like to depend on Crate A and Crate B, and calling that incompatible API would be a requirement for the implementation goal. So far editions haven't bothered covering such cases, deemed as not worthwhile thinking about. Those in such scenarios get to hunt for another crate to replace Crate A, or have a local fork.
      - tialaramex 9mo ago
        OK, so you don't have any examples, I recommend coming back once you have an example as otherwise there's nothing concrete to engage with here.
        pjmlp 9mo ago
        That was the example, now if you rather want to play defensive instead of engaging into a meaningful discussion about the Rust approach to language versioning and its constraints, well it is as it is.
      - simonask 9mo ago
        I think it would be useful to give an example of the kind of semantics that would be desirable to change, and where people might think that it should be possible to change at an edition boundary. I’m not very sure, but maybe something like unforgettable types? Or linear types? Maybe negative trait bounds, or specialization?
aw1621107 9mo ago
> Python 2 to 3 is a good example of what can be expected to happen People keep bringing this up when discussing backwards compatibility breaks, but I think the conclusion should be a bit more nuanced than just "backwards compatibility break <=> years (decades?) of pain". IMHO, the problem was the backwards compatibility break coupled with the inability to use Python 2 code from 3 and vice versa. This meant that not only did you need to migrate your own code, but you also needed everything you depend on to also support Python 3. This applied in reverse as well - if you as a library developer naively upgraded to Python 3, that left your Python 2 consumers behind. Obviously the migration story got better over time with improvements to 2to3, six, etc., that allowed a single codebase to work under both Python 2 and 3, but I think the big takeaway here is that backwards compatibility breaks can be made much more friendly as long as upgrades can be performed independently of each other.
patrick451 9mo ago
Python3 drops support for older versions of python3 all the time. Every single release comes with a bunch of deprecated and removed features. There is a very strong chance that a python 3.7 codebase is totally broken on 3.14. Almost no language takes backwards compatibility as seriously as c++ does.
- HarHarVeryFunny 9mo ago
  It's an interesting policy decision for a language - whether to guarantee (or at least practice) ongoing backwards compatibility or not. The benefit of NOT maintaining backwards compatibility is that hopefully you end up with a cleaner language without all the baggage of the past, and "impedence mismatches" of new features that don't play well with old ones, etc, etc. However, as a developer, I think I prefer the backwards compatible approach, knowing that: 1) Upgrading to latest version of the compiler hopefully isn't a big deal, and I can take advantage of any benefits that brings, including new language features, without having to sign up for rewriting existing tested code to remove deprecated features. In a large code base any such forced rewrites could be pretty onerous, and may involve a lot of retesting and potential for introducing bugs into code that was previously working. 2) It's nice to be able to take older projects, that you haven't worked on in a while (whether hobby projects, or legacy corporate code) and have the code still compile with the latest installed tool set, rather than to have developed "bit rot" due to using language features that have since been deprecated. Of course bit rot may also occur due to library changes, so language backwards compatibility is no guarantee of smooth sailing. Maybe going forwards, with AI coding tools, this will become less of an issue, if they become capable of this sort of codebase updates without introducing errors. In fact, going forwards it may well be that choice of programming languages itself becomes seen as more something the tooling takes care of. Nowadays we write in high level languages and don't really think or care about what the generated machine code looks like. Maybe in the future we can write in high level instructions to the AI, without even having to care what the implementation language is?