Episode 151: Is C++ Dying (Response)

[codereport]

Episode Link: https://adspthepodcast.com/2023/10/13/Episode-151.html

Feel free to write comments or ask questions 🙂

[GregThain]

In the intro, Bryce said "C++ has one of the largest bodies of existing, written code out there".

I hear this a lot, but is there any documentation or objective measurements of this? Whenever I hear quotes like this, I fear we are committing the sin of counting both pure C and bona fide C++ as the same thing for this metric. Consider the Linux machine I'm typing this on -- zero million lines of the kernel are written in C++ and zero million lines of device drivers are written in C++.

If my one-off scripting is right, of the 1686 binaries in /usr/bin on my machine, only 238 link with c++ libraries.

Thanks, and keep up the podcasting.

[JohelEGP]

I recall some of Bjarne Stroustrup's talks including such measurements.
It's mostly number of developers.
But I think there was at least one which included lines of code.

[codereport]

It's an interesting question. How much C vs C++ code is out there.

[JohelEGP]

There's also a problem of classification.
I think it was Bjarne who said in his recent Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023
that much of C++ or C/C++ out there
is like C with Classes, typical C code with a few allowed C++ features (this set differing between code bases).

[pascal754]

I was curious about that, too when Bjarne said, "There are billions of lines of C++ code out there".

How did he count?

There are some numbers from the heavy users.

• Libraries: A First Step Toward Standard C++ Dependency Management - Bret Brown & Bill Hoffman (CppCon 2023)
  (https://youtu.be/IwuBZpLUq8Q?list=PLHTh1InhhwT7gQEuYznhhvAYTel0qzl72&t=858) 14:18
  Bloomberg's C++
  +30k C++ projects
  +500M LOC

• How Microsoft Uses C++ to Deliver Office - Huge Size, Small Components - Zachary Henkel (CppCon 2022)
  (https://youtu.be/0QtX-nMlz0Q?list=PLHTh1InhhwT6c2JNtUiJkaH8YRqzhU7Ag&t=513) 8:33
  Office Monorepo
  350M LOC
  100M lines of native code

GitHub statistics
(https://madnight.github.io/githut/#/pull_requests/2023/2)

Linus Torvalds has a strong opinion about C++(this is famous) and uses only C in the Linux kernel (Rust was newly adopted).

[pascal754]

Thanks.

Is it possible to hire full time committee members to evolve the language?

The Committee members are passionate volunteers while working for their companies,

and the majority of programmers are busy and have no time or money to write papers and go to face-to-face meetings.

So everyone hopes that somebody is working for their needs.

Some features are easy to implement but nobody writes a paper,

and some features cannot be introduced due to ABI break(it is a hot potato now).

Reflection and pattern matching are long awaited features but

it would be hard to pick one proposal because others come up with better ideas.

In this case the full time committee members can carry on these issues without interruption.

Did I repeat well known facts?

BTW, in three years or so we might see the output of new language projects and how they are embraced.

The Circle compiler seems to have an early working borrow checker.

I hope C++ also responds to these challenging environments.

P.S. Cmake 3.28 will support C++20 named modules for MSVC, Clang 16.0, and GCC 14.
(https://cmake.org/cmake/help/v3.28/release/3.28.html)

[JohelEGP]

BTW, in three years or so we might see the output of new language projects and how they are embraced.

I assume you mean the "successor languages".
It's 10 years, according to Herb Sutter, if you don't opt into 100% backwards compatibility from the start (watch https://www.youtube.com/watch?v=8U3hl8XMm8c),
Rust is on its eight.
Maybe Carbon has a chance, as its compatibility story seems to be building up well.

[paulfloyd]

How do you manage to have a podcast called ADSP and know almost nothing about the languages that Wirth worked on? Roughly speaking they are

1. Pascal, similar to C.
2. Modula-2, Pascal with classes (modules).
3. Oberon, Modula with type extension (single inheritance).

I'd say that they are all systems languages. Modula-2 was developed to write the OS and software for the Lilith workstation. Oberon was also developed as a full system (workstation, operating system and compiler) all developed at ETH Zurich.

[perghosh]

C++ can't die, There are many areas where C++ is the only option to get something done
Society would collapse if C++ disappeared.

I think the main problem is that there are different type of developers and C/C++ differs in how you think compared to other languages. C++ is assembler without coding assembler. Coding C++ not knowing assembler is problematic.
Almost all other languages tries to remove the need to know how the hardware works. There are many disadvantages with not understanding hardware. Other languages can't hide this barrier and and get same results as C++.

If you don't know why C++ is not the right language, then select C++

[hypdeb]

C++ can't die, There are many areas where C++ is the only option to get something done
Society would collapse if C++ disappeared.

So, this is a hostage situation? 🤣

[Trozzel]

Ok, this episode was just off the chain. I personally LOVED it. The fact that it invoked this response from Jason Turner made it infinitely better: https://www.youtube.com/watch?v=hxjSpasg3gk&t=103s
Some people are so married to C++, and they fail to give credence the MANY legitimate complaints that very capable men and women issue against C++.
Don't get me wrong. C++ is still my favorite programming language, but I get so tired of rooting for compilers to keep up with new standards, rigidness on ABI standards, and continual constexpr expansion, to name but a few.

To the naysayers that say that people have been saying this for a long time, I believe this time is different.
If you are interested, and I believe it is worth the listen, check out with podcast with the CEO of Lynx on conforming to new govt standards on safety and security. He is transitioning to Rust. That says a ton (starting at 19:09)!
https://podcasts.apple.com/us/podcast/the-mchale-report-podcast/id1466306189?i=1000622456574

[ryobg]

I watched few recent panels about C++ and in on of these, there was a survey done on the Committee members (2022?) that Safety is the top priority. There is a big pressure and word of mouth saying C++ is not suitable, so I do hope this belief change.

[jrheisey]

Borland produced Turbo Pascal prior to Delphi. Delphi was Borland’s OO version of Pascal. Microsoft also had a Pascal compiler. Both were used extensively to write many major DOS applications during the 70s and 80s. Also DBase and its derivatives were popular choices for DOS database applications.

The adoption of C on PCs I think was fueled by the timing of Windows applications. Initially Pascal did not support Windows as far as I remember. I did do maintenance work on a sizable commercial DOS application which had mostly Pascal and some C modules. I think primarily because a developer wanted to learn C.

This was the time of the beginning of my career as a software developer. Yep I’m one of those xxx.

[AndreasSchaetti]

I was just listening to this episode again, where Bryce says:

If C++ becomes a sunset language, over time that code is gonna get harder and harder to maintain and eventually, inevitably, large amounts of that code will have to be rewritten entirely in a different language. And there is just no world in which that migration doesn't come with a great cost. And I don't wanna pay that cost. I would like the world to be able to continue using C++ code for the next 50, 60 years and have it be a healthy part of the ecosystem. [...] I don't want the existing body of code to have to be rewritten and replaced. If we have to do that solely because the C++ language has become stagnant, that would be a huge waste.

This is a very interesting take and I agree with a lot of what Bryce is saying here and continues to say after this quote.
But I'd like an explanation of why "the code is going to get harder to maintain and eventually has to be replaced".
Would if really be such a problem if C++ was sunset right now or if it would from now on adopt the approach of C standardization?
C++23 provides a large set of language and library features that are certainly powerful enough to maintain current code, which is mostly written in older versions of C++. Future library features like graphics or networking or language features like reflection, contracts and pattern matching are not required for maintenance and even for evolving current code bases.

Just before the above quote, Bryce also says:

C++ has one of the largest bodies of existing written code out there.

Likely a substantial fraction of this code is written in C++98/03 and mostly in the style of C with classes, especially in embedded devices. Even though this code could be refactored to modern C++, it would still be a huge effort. So we are already at a place where there are large amounts of legacy code that are in practice working in a language version from 20 years ago. I'm certain that there are much worse problems with maintaining such a code base than an old C++ standard, such as bad readability, testability, modularity, low automatic test coverage and so on, which are all problems unrelated to the actual language the code is written in.

I generally would like the C++ community to focus more on teaching, learning and improving architecture and design of the software and less on the minutiae of the C++ standard and the newest additions to the language.

What do you think?

[AndreasSchaetti]

One problem certainly is getting people up to speed with new standards of the language. There are actually two separate problems:

• Teaching devs that are experienced with an older standard. Conferences can be a great tool for this.
• Teaching new devs essentially from zero. The best approach IMHO would be to directly teach the modern stuff. However, most materials are not there yet, I guess especially at universities, so you go through the learn/unlearn-cycle you mentioned.

I think most features have their place, so I would not rail against runtime polymorphism and pre-concept templates but explain in which cases they are actually valuable.

This is an interesting albeit tangential discussion. What I primarily would like to discuss here is "why the code is going to get harder to maintain and eventually has to be replaced" if evolution of C++ stops.

[JohelEGP]

I can give a case.

Bryce has investment in the executors proposal.
That proposal would greatly benefit from language support for CPOs.
If the evolution of C++ stops,
the proposal would have to stay as an independent library
that is necessarily constrained to the existing language.

What that would mean for the library and its users
would be the same as previous users of Boost's lambda and variadics support.
Now, we all have access to lambda expressions and variadic templates.
Before, that was a Boost library feature.
That limited the user base of the feature
and how well it integrates with the language.

[pascal754]

Sorry for the tangent. What I tried to convey in the code example was not to introduce new features but to emphasize the teachability, cohesiveness, and simplicity of the language in the evolution process.

As the speaker said, const behaves correctly according to the language rules but semantically incorrectly, giving different results from the user's intentions.

[AndreasSchaetti]

@JohelEGP Thanks for the example. I agree that it would be nice to have executors in the language. Of course it would be nice for codebases that are currently using a library solution to migrate to the language-supported executors . It would also be a great selling point for C++ when teams decide on the language of a new project or when they are thinking about migrating away from C++ to e.g. Rust. However, I don't see yet how this affects the maintainability and viability of existing codebases.

[JohelEGP]

However, I don't see yet how this affects the maintainability and viability of existing codebases.

If executors are successful, it affects how those codebases are perceived.
They start becoming legacy.
The other side of the coin is that if C++ evolution stops, the framework of those codebases can't be improved.
For example, by migrating to executors (which they can't, because C++ evolution stopped).

[sasq64]

I wonder why you include Hylo in the set of successor languages? As you mentioned, C++ is very hard to interface against (as opposed to C) and so any language that doesn't solve that would not really qualify as a viable successor language would it?

That means that any real contender needs to be able to fully parse C++ or the AST:s generated by the compiler to qualify.

Which would mean the set only includes Carbon and Cppfront (and probably Circle).

Although one could argue that D should also be included, since it has a decent C++ interface (https://dlang.org/spec/cpp_interface.html).

[sasq64]

...which leads me to this thought; if we could get a standardized module format, would that open up the possibility for a lot of languages to interface C++ directly?