Episode 150: Is C++ Dying?

[codereport]

Episode Link: https://adspthepodcast.com/2023/10/06/Episode-150.html

Feel free to write comments or ask questions 🙂

[pascal754]

Thanks for this episode.

As a hobbyist C++ programmer, it is sad that C++ is being criticized by many and should be avoided in new projects by US government agencies and other organizations.

Here's my observations from social media:

The recent memory safety issue was a wake-up call. Some people still ignore it saying nothing new.

Most C++ developers complain about C++ but they have no choice but to use it.

The ISO three year train model is outdated.

Some people say that C++ will be replaced by some languages and fossilized.

In the current situation, it seems to be a matter of time: younger generations become senior engineers and managers, and C++ would be in a legacy mode.

If Rust were designed to interoperate with C++ from the beginning, its adoption would be widespread. There are too many C++ libraries out there.

How can people switch to new languages every time better ones emerge?

The Circle language showed that C++ can be improved and fixed but it remains to be solved how to deal with the Committee and fellow programmers.

Personally, it is frustrating that the following code compiles.

The address sanitizer can catch it though.

#include <vector>

int main()
{
  std::vector<int> vi{1, 2, 3};
  for (auto& x : vi)
  {
    vi.push_back(++x);
  }
}

[sivasnp]

After listening to one of the cppcon keynote, may be it is best to switch to a new shiny language

[gyrovorbis]

My dudes, I'm a weird C++20/23 language nerd who also writes a bunch of C17 (and now some C23), and am a contributor the Sega Dreamcast indie SDK (which is shipping commercial games). Our scene has become hugely involved in supporting all of the modern C++ stdlib stuff and concurrency and all that, we are also now supporting the D programming language, and we are some of the earliest testers and users of the GCC-RS upcoming Rust front end for the GCC compiler... Sounds like I'm a dinosaur, but I have a weird passion for marrying the old with the new, so it's not like I'm some C89 guy. lmao.

But I do think a lot of the criticism against C++ is unfounded. I have nothing against Rust, and some of the Rust guys are great friends of mine whose work I very much support, but I have some pretty hot takes and maintain a whole list of things I keep discovering that are literally not possible in the Rust language but are in C++... and I think that's important and nobody talks about it. Nobody is talking about the advanced features in C++ that Rust has no equivalent for like variadic templates, emplacement on containers, generic specializations, placement new/delete, inner structs/classes/types, generic closures, (dare I say) inheritance, etc...

If you guys ever wanna shoot the shit and talk about supporting the latest features on retro hardware with a dude who has a bit of a C++ bias but is still familiar with the other languages, hit me up! This is fantastic content.

EDIT: LOL. Also of the opinion Sean Baxter and Circle represent the future. lmao.

PS: I was at Nvidia too doing tools for the Nintendo Switch Console. Small world! lol.

[cfuego]

At 42:45 or so, Bryce talks about the next generation of leadership having diversity and inclusion in common, and Connor asks if [bleep] is in that boat (yes; surprise).

Leaving aside American politics, which I definitely don't want to wade into, I don't understand what you mean in this discussion. What exactly does the next gen have in common? A set of ideas or practices? Do Connor and Bryce view this as a good thing or a bad thing for the improvement of the committee? How does it materially or practically affect the future of C++? If the major problem is sclerosis and inefficiency, what part does whatever they're talking about play in resolving (or worsening??) that? What would be different if "Baxter for Dictator" or one of Bryce's other reforms were to stick, or if the reigns were just handed over to this new gen?

[pfeatherstone]

I'm not convinced the language stagnating is necessarily an issue. We can still get some awesome libraries in the meantime. I think standardising a package manager and build-system is more important. Take a look at python. You can have a library with 50 dependencies specified in a requirements file. No problem, everything works and no sweats. C++ project with QT and boost and things get complicated.

[pfeatherstone]

I don't think having 15 competing package managers solves anything. I want to write a portable library. Which do I use? Answer: none of them. Just make it header-only. Zig have made the right choice of baking it into the compiler.

[JohelEGP]

Not everything can be header-only.

[pfeatherstone]

Oh yeah I agree. I was trying to say that's the best way to write portable libraries nowadays. In my opinion.

[abeham]

In my view, the compiler should still be doing a lot more for the programmer. I don't think msvc is very good - haven't used the others much. But it's all there is and so one may think it's great. But it's really quite bad. The error messages alone are a complete disgrace and often utterly useless. Saying the problem is inside the STL in construct_at ... oh boy.

If C++ compilers were great would we have Carbon or even Rust, etc.?

Now the Circle compiler is nice in theory. But it's a one man closed-source show, but more like a local theater. Unless Baxter creates a business out of it, but does he want that? He doesn't open source either, so it's not clear what he wants (other than to have fun programming of course). But even as a proprietary compiler, would it sell? Maybe partnering with JetBrains is an option for him.

Also circle is not cross platform. Which is a pretty big disappointment and likely he can't solve it by himself.

Still Circle looks attractive. Because it's not a new language. But what is it? It's vendor-specific extensions to the standard. New exciting features, user-friendly metaprogramming, customer focused, delivered rather quickly. You don't need to learn a new language, but the extensions still make it feel like it's a new language. So you can gradually switch to this. Bjarne speaks about making the language bigger, more and better abstractions and never taking away something. So there you have it. Sean shows it's possible. But the standardization committee is a much more conservative and slow moving organization. The perceived attitude is "should we" rather than "how do we". So maybe we arrive at circle-like features in about 15 to 20 years 🤷

But anyway, on the other side isn't vendor-specific extension a thing of the past? Aren't we glad that there is a standard and not compiler-silos? (especially since circle isn't even cross platform). Only the circle compiler can parse circle extensions. So if you have to include a library that is written in circle in an ordinary C++ environment, how do you do it? Binary is not an option, because of header files, because of platforms. So without going either open source or going business circle isn't really a serious thing.

The ISO C++ process, as painful as it may be, is the only thing going forward with C++. Circle may evolve into its own thing.

[pfeatherstone]

I don't think it's the language the problem but a lack of really great modern and relevant libraries. For example, you can't do machine learning research in c++. You do it in python then infer in c++. But now the performance gap between python and c++ ML inference is so small it's barely worth doing it in c++. Same thing for data science. We need more cool libraries in c++, and not hipster esoteric ones

[pfeatherstone]

Basically the list of problems where c++ is "the right tool for the job" is getting incredibly small.

[abeham]

C++ is a general purpose programming language like others. I don't see how its use cases are shrinking.

That there aren't specific libraries... ML ... Is that true? Pytorch C++ at least shows up in Google search. And in which language are those number crunching algorithms written that provide the base of Python-ML? I suppose it's something fast and close to the hardware (CUDA).

Python is just friendly to toy around with, nice for quickly going from reading data to producing a visual while C++ is a pain to just set up. Ipython notebook is a few clicks away, Google colab etc, a VS Code+CMake setup though? Took me a few hours to get right as beginner. Hence compiler explorer, but I guess there's not much serious stuff you do on godbolt.org, it's a sandbox.

[pfeatherstone]

C++ is a general purpose programming language like others. I don't see how its use cases are shrinking

What i'm saying is that there are better ways of doing old things, which would have traditionally been done in C++ in the past, but now done with modern languages.

Pytorch C++ at least shows up in Google search

You are right, but the percentage of people who use the C++ frontend vs the Python one is probably less than 1%. The Pytorch architecture is split across multiple languages, which has motivated people to rewrite everything in either pure Python (tinygrad) or a brand new language (Mojo), or using compilers (Triton, XLA, etc). So to say C++ is suitable for ML is not really true anymore. Library writers use it for CPU kernels only now pretty much. And if you're only using C++ for writing small mathematical kernels on CPU, why not just use C? (That's what tinygrad does for C export)

Python is just friendly to toy around with, nice for quickly going from reading data to producing a visual

I think it's used for far more than that now.

When it comes to general software architecture, it looks like industry is preferring Rust nowadays. So I think C++ is soon only going to be used for small, very bespoke number crunching stuff. And in that case, may as well just use C.

But I dunno, the more i toy with other languages, the more i realise how much easier it is to do pretty much anything in other languages.