11 ms·

It'll most likely be abandoned in droves. One of the main reasons to stick with C++ (and C) is that the investment you put in the code you're writing right now,

It'll most likely be abandoned in droves. One of the main reasons to stick with C++ (and C) is that the investment you put in the code you're writing right now, no matter how fugly it is, will be there and keep working in the future. Also: > I think it also makes sense for C++ developers whose projects are relatively short-lived, e.g. some games. There is a difference between games and engines - the games might be short lived, but most C++ engines are very long lived, going back decades (e.g. see how the recent Half-Life Alyx can trace its codebase back to Quake 1 or pretty much anything based on the Unreal Engine going back to the mid-90s - there are screenshots of UE1 running on what appears to be either Windows 3.1 or NT 3.51). Even when "engines" are being made "from scratch" this is often a marketing gimmick and the "from scratch" was just renaming the engine because it got a new rendering model and people can't tell the difference. EVEN when this isn't case, often new engines are based on existing code and/or libraries.

bruxis 7y ago
Agreed, I think looking at the Python 2 and 3 migration catastrophe gives a glimpse into what this could look like, but I imagine it would be much worse given the types of (large) projects that are backed by substantially "dated" C/C++ code.
- santamarias 7y ago
  I agree about the "rocky transition" from Python 2 to 3. Still if the Python migration story gives any inference towards the outcome of an eventual C++ transition, the new language would be an even more massive success; it seems that Python 3.x is doing alright right?
  - roenxi 7y ago
    That is somewhere in the logical region of saying 'Stephen Hawking was really smart, maybe amyotrophic lateral sclerosis is a good thing'. The transition to Python 3 was not pretty. Still isn't; Python 2 documentation features prominently when I'm trying to look up information. The to abandon backwards compatibility in C++ is to make a mockery even of the name of the language (see the "C" in there). If they want to create a new language they should call it something different. Willfully abandoning backwards compatibility and keeping the name is an abuse of one of the great brands in software.
    - santamarias 7y ago
      I was just trying to get a response to how the Python transition mentioned was so (edit:) "catastrophic". I don't understand the need to bring fiction writers, fatal diseases or laden words like "mockery" or "abuse" to the debate.
      - ComputerGuru 7y ago
        Stephen Hawking was not a fiction writer. Stephen King does not have a horrible disease.
        santamarias 7y ago
        sorry, my bad
    - bsder 7y ago
      > Python 2 documentation features prominently when I'm trying to look up information. I consider this more a case of the ossification of search. Neither search engines nor specific sites like Stack Overflow deal with the fact that information can switch from right to wrong with age.
  - tempay 7y ago
    Yeah, I think Python 2 has been successfully killed at this point. There are a decent number of projects which still need to migrate (and I recently became responsible for a couple) but it’s been a long time since I heard anyone claim they can keep Python 2 forever. The maintenance burden of keeping Python 2 is rapidly increasing as libraires drop support.
- phire 7y ago
  You could do so much better than the python 2 to 3 transition. If the python 3 interpreter could still run python 2 code. If you could mix and match python 2 and 3 code on a per-module, per-file or even per file basis, then the transition could have been so much smoother.
- BiteCode_dev 7y ago
  The reasons the transitions worked were that: - the languages were not that different, so no need to learn the new version - python core devs gave 10 years to make the transition. Then extended it. - it was possible to write code running on python 2 and 3 - python is very expressive, hence the code base have way less numbers of lines than in C++ - python cared only about one implementation, Cpython. The rest of the world needed to follow. Some didn't, like Jython and stackless, and the community didn't blink. Despite all that, the transition was very painful.
  - otabdeveloper2 7y ago
    > python is very expressive, hence the code base have way less numbers of lines than in C++ This doesn't match reality. In reality, many Python projects have way more lines of code than equivalent C++ projects. Probably because of the 'expressiveness' you cite; you can't really showcase your love of coding and job security though artificial complexity without 'expressive' bells and whistles. (This is the idea that lead to languages like Go, I'm pretty sure.) That said, C++ is plenty 'expressive' itself.
    - BiteCode_dev 7y ago
      > many Python projects have way more lines of code than equivalent C++ projects. That is mathematically impossible. Even if the syntaxes were exactly the same (which they are not, python syntax is on average shorter), the low level nature of C++ requires your code to do operations that Python does need to do, such as memory management. It's like stating the sky is red.
      - snovv_crash 7y ago
        Once you've written sufficient unit tests to prove your code works as well as a C++ equivalent does just by compiling, I don't think Python ends up being more dense though. I'd also argue that operator overloading etc lets C++ be just as expressive as Python, the libraries just need to be designed with that in mind.
- pletnes 7y ago
  Since python3 has many more users than python2 this is not a relevant comparison. It was not smooth, but now it’s done and it worked. There have been many C++ forks which have failed to replace it, e.g D, Rust, ...
  - MaxBarraclough 7y ago
    D and Rust are not forks of C++, they're entirely different languages.
amelius 7y ago
> One of the main reasons to stick with C++ (and C) is that the investment you put in the code you're writing right now, no matter how fugly it is, will be there and keep working in the future. Except slowly people will be writing parts of it in Rust, or they would be using libraries written in Rust (because availability), and then after a while people get annoyed of using more than one language and the whole project will be rewritten in Rust. Of course, at that point, a new language will be invented and Rust code will be looked at as rusty :)
- otabdeveloper2 7y ago
  > Except slowly people will be writing parts of it in Rust Wishful thinking.
  - pjmlp 7y ago
    Wishes sometime turn into reality. https://kennykerr.ca/2019/11/05/rust/ https://kennykerr.ca/2019/11/05/rust/ https://twitter.com/benwilliamson/status/1240113606374686721 https://twitter.com/benwilliamson/status/1240113606374686721
- kllrnohj 7y ago
  Rewriting parts in Rust would require Rust to have good C++ interop, which it doesn't. At all. Rust has good C interop, so if your code is already divided into C-abi shared libraries then you're golden. But if it's not then Rust migration really isn't an option. And realistically I'm not entirely sure how you can add C++ interop to Rust without also ruining Rust. It's a hard problem to say the least.
  - bsder 7y ago
    Does anything have good C++ interop?
    - pjmlp 7y ago
      D, .NET and COM/UWP.
fctorial 7y ago
> see how the recent Half-Life Alyx can trace its codebase back to Quake 1 Source?
- garblegarble 7y ago
  Half Life Alyx is built on Source 2, which was extended from Source 1, which is a heavily modified version of GoldSrc which was based on the Quake 1 engine. John Carmack said in 2004 that "there are still bits of early Quake code in Half-Life 2" - https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_day/johnc_plan_20041231.txt#L17 https://github.com/ESWAT/john-carmack-plan-archive/blob/mast... https://en.wikipedia.org/wiki/Source_2 https://en.wikipedia.org/wiki/Source_2
- badsectoracula 7y ago
  Yes :-P. In all seriousness, Half-Life Alyx is based on Source 2 which itself is based on Source 1 which is based on GoldSrc which is based on Quake 1.
kllrnohj 7y ago
> but most C++ engines are very long lived, going back decades While true the engines are also staffed and can absolutely keep up with changes. They regularly are tasked with new toolchains, platforms, OSes, and APIs to leverage already. This would just be more of the same, and if you look at the goals of the paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html#goals http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213... That lines up pretty damn well to what game engines want as well. > One of the main reasons to stick with C++ (and C) is that the investment you put in the code you're writing right now, no matter how fugly it is, will be there and keep working in the future. I think you should read the actual paper instead. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213... The things they talk about actually abandoning are things like byte sizes other than 8-bits or source code in file systems that don’t support file extensions or nested directories. Chances are any existing C++ codebase is already not compatible with such systems that they want to more formally deprecate/abandon in the first place.
- theamk 7y ago
  You are talking about section 1.8. I agree, it is not that scary. What is scary, however, are sections 2.1 and 2.2. They contain stuff like this: > Our experience is that providing broad ABI-level stability for high-level constructs is a significant and permanent burden on their design. It becomes an impediment to evolution, which is one of our stated goals. This does not name it, but doesn't this refers to all those discussions about changing internal representation of std::string, std::vector and so on? This does sound pretty scary. Once you have separate classes for "C++23 std::string" and "older std::string", you can no longer link together files built with different versions.. and this means you lose a lot past compatibility.
  - kllrnohj 7y ago
    > you can no longer link together files built with different versions True but this is already something that isn't really "supported" broadly. Some standard libraries work hard to keep that working, but others tend not to, and nobody knows if it's supposed to work reliably or not. And support for this binary compatibility also varies across platforms, like I don't think Microsoft bothers since you're supposed to always bundle a specific version of the runtime with your binary. Single-version prebuilt libraries become more of a problem, but are those that widespread vs. source-based libraries? But I think the broader point here that the paper is really pushing is for the committee to actually make a statement on things like this instead of their historically vague "it sort of works but we're not saying it will or indeed saying anything at all"

bruxis 7y ago

Agreed, I think looking at the Python 2 and 3 migration catastrophe gives a glimpse into what this could look like, but I imagine it would be much worse given the types of (large) projects that are backed by substantially "dated" C/C++ code.

santamarias 7y ago
I agree about the "rocky transition" from Python 2 to 3. Still if the Python migration story gives any inference towards the outcome of an eventual C++ transition, the new language would be an even more massive success; it seems that Python 3.x is doing alright right?
- roenxi 7y ago
  That is somewhere in the logical region of saying 'Stephen Hawking was really smart, maybe amyotrophic lateral sclerosis is a good thing'. The transition to Python 3 was not pretty. Still isn't; Python 2 documentation features prominently when I'm trying to look up information. The to abandon backwards compatibility in C++ is to make a mockery even of the name of the language (see the "C" in there). If they want to create a new language they should call it something different. Willfully abandoning backwards compatibility and keeping the name is an abuse of one of the great brands in software.
  - santamarias 7y ago
    I was just trying to get a response to how the Python transition mentioned was so (edit:) "catastrophic". I don't understand the need to bring fiction writers, fatal diseases or laden words like "mockery" or "abuse" to the debate.
    - ComputerGuru 7y ago
      Stephen Hawking was not a fiction writer. Stephen King does not have a horrible disease.
      - santamarias 7y ago
        sorry, my bad
  - bsder 7y ago
    > Python 2 documentation features prominently when I'm trying to look up information. I consider this more a case of the ossification of search. Neither search engines nor specific sites like Stack Overflow deal with the fact that information can switch from right to wrong with age.
- tempay 7y ago
  Yeah, I think Python 2 has been successfully killed at this point. There are a decent number of projects which still need to migrate (and I recently became responsible for a couple) but it’s been a long time since I heard anyone claim they can keep Python 2 forever. The maintenance burden of keeping Python 2 is rapidly increasing as libraires drop support.
phire 7y ago
You could do so much better than the python 2 to 3 transition. If the python 3 interpreter could still run python 2 code. If you could mix and match python 2 and 3 code on a per-module, per-file or even per file basis, then the transition could have been so much smoother.
BiteCode_dev 7y ago
The reasons the transitions worked were that: - the languages were not that different, so no need to learn the new version - python core devs gave 10 years to make the transition. Then extended it. - it was possible to write code running on python 2 and 3 - python is very expressive, hence the code base have way less numbers of lines than in C++ - python cared only about one implementation, Cpython. The rest of the world needed to follow. Some didn't, like Jython and stackless, and the community didn't blink. Despite all that, the transition was very painful.
- otabdeveloper2 7y ago
  > python is very expressive, hence the code base have way less numbers of lines than in C++ This doesn't match reality. In reality, many Python projects have way more lines of code than equivalent C++ projects. Probably because of the 'expressiveness' you cite; you can't really showcase your love of coding and job security though artificial complexity without 'expressive' bells and whistles. (This is the idea that lead to languages like Go, I'm pretty sure.) That said, C++ is plenty 'expressive' itself.
  - BiteCode_dev 7y ago
    > many Python projects have way more lines of code than equivalent C++ projects. That is mathematically impossible. Even if the syntaxes were exactly the same (which they are not, python syntax is on average shorter), the low level nature of C++ requires your code to do operations that Python does need to do, such as memory management. It's like stating the sky is red.
    - snovv_crash 7y ago
      Once you've written sufficient unit tests to prove your code works as well as a C++ equivalent does just by compiling, I don't think Python ends up being more dense though. I'd also argue that operator overloading etc lets C++ be just as expressive as Python, the libraries just need to be designed with that in mind.
pletnes 7y ago
Since python3 has many more users than python2 this is not a relevant comparison. It was not smooth, but now it’s done and it worked. There have been many C++ forks which have failed to replace it, e.g D, Rust, ...
- MaxBarraclough 7y ago
  D and Rust are not forks of C++, they're entirely different languages.

amelius 7y ago

> One of the main reasons to stick with C++ (and C) is that the investment you put in the code you're writing right now, no matter how fugly it is, will be there and keep working in the future. Except slowly people will be writing parts of it in Rust, or they would be using libraries written in Rust (because availability), and then after a while people get annoyed of using more than one language and the whole project will be rewritten in Rust. Of course, at that point, a new language will be invented and Rust code will be looked at as rusty :)

otabdeveloper2 7y ago
> Except slowly people will be writing parts of it in Rust Wishful thinking.
- pjmlp 7y ago
  Wishes sometime turn into reality. https://kennykerr.ca/2019/11/05/rust/ https://kennykerr.ca/2019/11/05/rust/ https://twitter.com/benwilliamson/status/1240113606374686721 https://twitter.com/benwilliamson/status/1240113606374686721
kllrnohj 7y ago
Rewriting parts in Rust would require Rust to have good C++ interop, which it doesn't. At all. Rust has good C interop, so if your code is already divided into C-abi shared libraries then you're golden. But if it's not then Rust migration really isn't an option. And realistically I'm not entirely sure how you can add C++ interop to Rust without also ruining Rust. It's a hard problem to say the least.
- bsder 7y ago
  Does anything have good C++ interop?
  - pjmlp 7y ago
    D, .NET and COM/UWP.

fctorial 7y ago

> see how the recent Half-Life Alyx can trace its codebase back to Quake 1 Source?

garblegarble 7y ago
Half Life Alyx is built on Source 2, which was extended from Source 1, which is a heavily modified version of GoldSrc which was based on the Quake 1 engine. John Carmack said in 2004 that "there are still bits of early Quake code in Half-Life 2" - https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_day/johnc_plan_20041231.txt#L17 https://github.com/ESWAT/john-carmack-plan-archive/blob/mast... https://en.wikipedia.org/wiki/Source_2 https://en.wikipedia.org/wiki/Source_2
badsectoracula 7y ago
Yes :-P. In all seriousness, Half-Life Alyx is based on Source 2 which itself is based on Source 1 which is based on GoldSrc which is based on Quake 1.

kllrnohj 7y ago

> but most C++ engines are very long lived, going back decades While true the engines are also staffed and can absolutely keep up with changes. They regularly are tasked with new toolchains, platforms, OSes, and APIs to leverage already. This would just be more of the same, and if you look at the goals of the paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html#goals http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213... That lines up pretty damn well to what game engines want as well. > One of the main reasons to stick with C++ (and C) is that the investment you put in the code you're writing right now, no matter how fugly it is, will be there and keep working in the future. I think you should read the actual paper instead. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213... The things they talk about actually abandoning are things like byte sizes other than 8-bits or source code in file systems that don’t support file extensions or nested directories. Chances are any existing C++ codebase is already not compatible with such systems that they want to more formally deprecate/abandon in the first place.

theamk 7y ago
You are talking about section 1.8. I agree, it is not that scary. What is scary, however, are sections 2.1 and 2.2. They contain stuff like this: > Our experience is that providing broad ABI-level stability for high-level constructs is a significant and permanent burden on their design. It becomes an impediment to evolution, which is one of our stated goals. This does not name it, but doesn't this refers to all those discussions about changing internal representation of std::string, std::vector and so on? This does sound pretty scary. Once you have separate classes for "C++23 std::string" and "older std::string", you can no longer link together files built with different versions.. and this means you lose a lot past compatibility.
- kllrnohj 7y ago
  > you can no longer link together files built with different versions True but this is already something that isn't really "supported" broadly. Some standard libraries work hard to keep that working, but others tend not to, and nobody knows if it's supposed to work reliably or not. And support for this binary compatibility also varies across platforms, like I don't think Microsoft bothers since you're supposed to always bundle a specific version of the runtime with your binary. Single-version prebuilt libraries become more of a problem, but are those that widespread vs. source-based libraries? But I think the broader point here that the paper is really pushing is for the committee to actually make a statement on things like this instead of their historically vague "it sort of works but we're not saying it will or indeed saying anything at all"