> Both C and C++ have zero built in knowledge about parallelism, so in a modern world where most things are parallel and asynchronous I don’t agree at all with that statement.

And ?

C (even Fortran) had threads and was used to create high performance program with high degree of parallelism before any "concurrent" modern language was even born.

You can not agree if you want. But fact are there, 98% of programs running on the biggest "parallel" machines nowadays (supercomputers) are C, C++ or Fortran.

You don't need to be "designed" concurrent to be efficient at it. The same way you do not need to be designed "Cloud-native (bullshit)" to run on a virtual machine.

I think that it sets a different mentality if it is part of tools you use, you solve problems differently. It is of course possible to write highly concurrent code in traditional sequential languages and your examples proves that, but supercomputers are a special case with budgets for that. I'm talking about the general case, and I think the post I replied to also assumed that.

We have to give programmers, with different backgrounds & training, tools to write high performant code in their everyday job. Many of the tools we use today are not designed for that. We are stuck in a mental model 50 years old that is no longer true.

Here are some interesting stackoverflow answers. You are of course free to dismiss these answers as anecdotal.

https://stackoverflow.com/a/14637833

https://stackoverflow.com/a/2799779

Both C and C++ have had a concurrent memory model and threads in the standard library for a decade now. And POSIX threads which are pretty much the same thing have been there for a quarter century on *NIX.

Sure, there are libraries for concurrency, but there are no language constructs like in other languages.

What do you mean by language constructs? As in, a `synchronized` keyword? Or are you thinking along the lines of `async` `await`?

If you mean the `synchronized` keyword, then correct, they don't have that. Most languages do not have that concept. C++ does have mutexes and has had them since C++11 (nearly a decade). C++ also has as part of the language spec the concept of threads, again, there since C++11.

If you meant co-routines, then C++ just added them with C++20.

Or do you mean something different like green threads (ala go)?

C++ certainly has concurrency constructs and has been expanding them since C++11.

Like Gos goroutines or Erlangs processes. And more of message passing. C++ has added many of these things later on in the standard library, bolted on afterwards.

If you think that using libraries to do things in C++ means they are "bolted on", then you don't understand C++.

The entire design of C++ is to enable efficient libraries for these kinds of things to be built. And it does, and has, and will continue to for decades more.

You forgot about OpenMP.