[pumpkinpal]

Its funny that you mentioned games as an example of parallel computation because I'd argue they're some of the hardest programs to parallelize effectively since they don't generally involve that much bulk-processing of read-only data.

Parellism in C++ is most often used for scientific applications and other forms of mass number crunching. It's really easy to just throw a "#pragma omp parallel for" on a loop and call it a day but of course that would also apply to C and Fortran and is somewhat limited. Parallelism libraries like Intel TBB which I'm most familiar with are very easy to use and performant. I think there's a large problem in the reluctance of educators to use libraries to teach parallelism and people always dive straight into locks, threads and atomics which are really not the way to approach parallel computing if you're looking to do parallel computing and not looking to implement parallel primitives yourself (i.e DIY tasking-system or lock-free queue)

Focusing on TBB, it facilitates efficient parallelism by providing high-level canned algorithms such as parallel_invoke, parallel_reduce, parallel_for and parallel_do which anybody who claims to know C++ should be able to use easily. It also provides a task-graph which is great for more complex processing pipelines (things like join/split, fan-in/out and queueing). If you need more low level control you operate at the task level and TBB provides customization points for that. There's other libraries out there which provide similar functionality and even the STL in C++17 provides basic parallel algorithms such as transform (equivalent of map in other langs), reduce and many others.

[jnxx]

> Parallelism in C++ is most often used for scientific applications and other forms of mass number crunching.

There are two aspects. I agree to the aspect that today, C++ is used often for such tasks.

Now, what are the reasons why C++ is used dominantly in this domain? I think more or less the only reason is performance. The good performance is what makes the authors of such libraries put up with the disadvantages of C++.

However, I think it is also true that Rust allows for a more concise and safe formulation of the computation (also Scala, for example, which serves somewhat different purposes). For scientific applications, correctness matters, and knowing that the code which compiles does not has hidden memory errors and data races is extremely valuable, because it can save a ton of time.

Also, if there are still differences between Rust and C++ performance, they are minor. In many cases, Rust is faster.

Now, if authors of scientific computing libraries were to come to the conclusion that there exist an alternative which produces at least as fast code, provides better and safer support for parallelization, and is with some learning easier to work with, why should these library authors continue to use C++?

Of course, nobody is going to ditch a large C++ project like Eigen over night and rewrite it in Rust. There is too much inertia for that. Also, GCC support is still lacking. However, one can expect that the number of new projects which use Rust is going to increase and the project which are successful there will blaze a new trail. For something like Python extension modules, users of these libraries do not need to know anything about Rust.

Also, some nitpick. C++ is used in important scientific libraries. However, many essential libraries such as Numpy are written either completely in C, or use C interfaces, because C++ does not has a stable ABI and Python uses the C ABI. This would make a switch to Rust pretty easy. In fact, I think the impulses in this domain will come first from researchers and analysts which start to write small Rust extension for Python which use the C ABI and integrate with Numpy, for example.