4 ms·

Its a bit disappointing that the C++ community and stakeholders haven't found a way to address perceived shortcomings and (why not) reinvigorate and generate ex

Its a bit disappointing that the C++ community and stakeholders haven't found a way to address perceived shortcomings and (why not) reinvigorate and generate excitement about the ecosystem. The fact that people choose to embark on enormous investments to build alternatives from scratch (e.g Rust) might suggest that the cost calculus between maintaining compatibility with legacy code and future-proofing the language has now shifted decidedly against the former. C++ does not feel like the kind of beast that is destined to become the new COBOL. Its continuing popularity in game development is just one of the areas that could see enormous growth and evolution.

int_19h 4y ago
I very much doubt that existing large C++ codebases - which are plenty - are going to fully or largely migrate to Rust (or whatever) within the next two decades. Given that C++ originates in mid-80s, that would make it as old as COBOL was in 2000.
- nindalf 4y ago
  This is similar to saying that no one would migrate to TypeScript because there are so many existing JavaScript codebases. The success of TypeScript and Kotlin suggest that one of the languages that hope to interoperate with C++ like Carbon could become more popular over time.
  - gpderetta 4y ago
    I suspect that the average liftime of a typical c++ and js codebase differ by one or two orders of magnitude.
    - nindalf 4y ago
      You’re assuming the codebase would need to be rewritten. It’s always possible that there might be a gradual transition within the same codebase. New features could be implemented in the new language while keeping everything else the same.
      - int_19h 4y ago
        I have experience with that kind of thing (https://news.ycombinator.com/item?id=34216117 https://news.ycombinator.com/item?id=34216117). For a sufficiently large codebase, you won't get there gradually even in two decades.
  - int_19h 4y ago
    TypeScript is a strict superset of JavaScript, so that one was more of a C/C++ situation (which was a big reason for C++ success to begin with). OTOH Kotlin, while popular, is still tiny compared to Java. Except for Android, which is a bit of a special case because mobile platforms generally have smaller codebases and shorter app lifecycle due to forced API breakage by the platform.
still_grokking 4y ago
> C++ does not feel like the kind of beast that is destined to become the new COBOL. Strange conclusion. For me it looks like C++ has chosen to become exactly this. The only reason it's still relevant is all the legacy code. Almost no new projects get started in C++. So it looks like they double down on that. > Its continuing popularity in game development is just one of the areas that could see enormous growth and evolution. I don't see this. Game dev is also moving. The most popular engines may be written in C++, because there was no choice as this projects started. But the games made on those engines are mostly not written in C++. Most code in games is "script like". And it's even often written in scripting languages. When not, it's something like C#, or some other more modern high level language.
- college_physics 4y ago
  > Strange conclusion I don't have a crystal ball but there are important differentiating factors: C++ is much more capable and it is relevant in more diverse domains whereas COBOL was very confined. > Game dev is also moving There are several new ECS projects implemented in C++ that have enthousiastic following. My hunch is that it is still up to the C++ world to lose it entrenched position by not doing the right changes but maybe that won't be the case in a few years from now.
  - still_grokking 4y ago
    > There are several new ECS projects implemented in C++ that have enthousiastic following. Would you mind to share? I'm currently looking into game dev. Would be nice to have a better picture of the landscape.
    - college_physics 4y ago
      there are several, following slightly different designs [0]. entt and flecs (mix C/C++) are currently the most visible [1]. older and more established engines are getting into the game as well [2]. its just a data point that C++ has constituencies that have not given up on it yet. [0] https://github.com/topics/ecs?l=c%2B%2B&o=desc&s=forks https://github.com/topics/ecs?l=c%2B%2B&o=desc&s=forks [1] https://github.com/SanderMertens/flecs https://github.com/SanderMertens/flecs [2] https://github.com/GodotECS https://github.com/GodotECS

int_19h 4y ago

I very much doubt that existing large C++ codebases - which are plenty - are going to fully or largely migrate to Rust (or whatever) within the next two decades. Given that C++ originates in mid-80s, that would make it as old as COBOL was in 2000.

nindalf 4y ago
This is similar to saying that no one would migrate to TypeScript because there are so many existing JavaScript codebases. The success of TypeScript and Kotlin suggest that one of the languages that hope to interoperate with C++ like Carbon could become more popular over time.
- gpderetta 4y ago
  I suspect that the average liftime of a typical c++ and js codebase differ by one or two orders of magnitude.
  - nindalf 4y ago
    You’re assuming the codebase would need to be rewritten. It’s always possible that there might be a gradual transition within the same codebase. New features could be implemented in the new language while keeping everything else the same.
    - int_19h 4y ago
      I have experience with that kind of thing (https://news.ycombinator.com/item?id=34216117 https://news.ycombinator.com/item?id=34216117). For a sufficiently large codebase, you won't get there gradually even in two decades.
- int_19h 4y ago
  TypeScript is a strict superset of JavaScript, so that one was more of a C/C++ situation (which was a big reason for C++ success to begin with). OTOH Kotlin, while popular, is still tiny compared to Java. Except for Android, which is a bit of a special case because mobile platforms generally have smaller codebases and shorter app lifecycle due to forced API breakage by the platform.

still_grokking 4y ago

> C++ does not feel like the kind of beast that is destined to become the new COBOL. Strange conclusion. For me it looks like C++ has chosen to become exactly this. The only reason it's still relevant is all the legacy code. Almost no new projects get started in C++. So it looks like they double down on that. > Its continuing popularity in game development is just one of the areas that could see enormous growth and evolution. I don't see this. Game dev is also moving. The most popular engines may be written in C++, because there was no choice as this projects started. But the games made on those engines are mostly not written in C++. Most code in games is "script like". And it's even often written in scripting languages. When not, it's something like C#, or some other more modern high level language.

college_physics 4y ago
> Strange conclusion I don't have a crystal ball but there are important differentiating factors: C++ is much more capable and it is relevant in more diverse domains whereas COBOL was very confined. > Game dev is also moving There are several new ECS projects implemented in C++ that have enthousiastic following. My hunch is that it is still up to the C++ world to lose it entrenched position by not doing the right changes but maybe that won't be the case in a few years from now.
- still_grokking 4y ago
  > There are several new ECS projects implemented in C++ that have enthousiastic following. Would you mind to share? I'm currently looking into game dev. Would be nice to have a better picture of the landscape.
  - college_physics 4y ago
    there are several, following slightly different designs [0]. entt and flecs (mix C/C++) are currently the most visible [1]. older and more established engines are getting into the game as well [2]. its just a data point that C++ has constituencies that have not given up on it yet. [0] https://github.com/topics/ecs?l=c%2B%2B&o=desc&s=forks https://github.com/topics/ecs?l=c%2B%2B&o=desc&s=forks [1] https://github.com/SanderMertens/flecs https://github.com/SanderMertens/flecs [2] https://github.com/GodotECS https://github.com/GodotECS