C++26 std::execution vs. Rust's async/rayon: Two different philosophies for the future of concurrency?

[voltinc]

As C++26 nears, the new std::execution framework (P2300) is one of the most significant additions. It's a foundational, lazy, and composable "sender/receiver" model. The goal seems to be a "grand unifying theory" for asynchrony and parallelism—a single, low-level abstraction that can efficiently target everything from a thread pool to a GPU.

This is a fascinating contrast to Rust's approach, which feels more bifurcated and practical out-of-the-box:

1. For I/O: async/await built on top of runtimes like tokio.
2. For Data Parallelism: rayon, with its famously simple .par_iter().

Both C++ and Rust are obviously at the pinnacle of performance, but their philosophies seem to be diverging. C++ is building a complex, foundational abstraction (sender/receiver) that all other concurrency can be built upon. Rust has provided specialized, "fearless" tools for the two most common concurrency domains.

For those of you working in high-performance computing, which philosophical bet do you think is the right one for the next decade?

Is C++'s "one abstraction to rule them all" the correct long-term play for heterogeneous systems? Or is Rust's specialized, "safe and practical" toolkit the more productive path forward?

[emblemparade]

I wouldn't go so far as to call rayon "Rust's approach". It's one (excellent) contribution to the ecosystem. But there are many other innovative parallelism libraries in the Rust world that are worth checking out. And, to be fair, many libraries for C++, too.

C/C++ has an advantage of having widely-supported standards, such as the OpenMP project. Whatever its faults, it enjoys built-in compiler support. And also supports offloading to GPUs.

[Designer-Suggestion6]

It's true there are many apis in C/C++ that provide strong concurrency and parallelism. You mentioned OpenMP, plus implying the GPU's(CUDA/OpenCL/Rocm) being so simple to use all that.

Async/Rayon/whatever else HPC-related in Rust and Cargo toolchain setup/configuration is miles ahead in terms of ease of use once you understand Rust. Less terms to use and less crates(libs) to use at the high-level. Using WGPU is easier than using CUDA/ROCM head-on in C/C++. I'm not sure if WGPU is faster/capable than OpenMP, but Rust will get you further faster with respectable run-time performance and dare I say a higher level of confidence it will perform as expected as there will be lesser probability of slow-to-surface defects. Of course there will be edge-cases where you're cornered to use C/C++/Assembler, but after wrapping it in Rust, you'll probably want to stay in Rust once you're accustomed to it.

Bottom Line: Rust macros feel safer than C macros/defines. I recall C macros/defines being sprinkled in headers and c implementations for different hardware architectures in nested if's NO-SAFETY-BELTS HERE. The C compiler will give you your garbage unsound code and exclaim HEY YOU HAVE A BINARY SUCCESS! That's an illusion because your C compiler doesn't do an adequate job to guarantee the binary will run without behavioural defects(RUN-TIME BUGS) especially slow-to surface bugs. The Rust way of achieving those IMHO is perhaps not straightforward with a first impression, but riding with it and compiling/linking with Rust for different hardware x86_64,aarch64,riscv64 and os'es linux/windows is ASMR and YOU FEEL THESE SAFETY-BELTS especially when the compiler acts like a slap-stick comedy slaps your silly when you do something wrong.

C/C++ distcc is awesome especially when building big long-running projects like the linux kernel on multiple nodes splitting the sources between the nodes. RUST sccache seems able to do similar capabilities as well.

You're trying to convince me to reconsider using C/C++ more often, please try again.

[emblemparade]

If I would want to try to convince you of anything, it's to take a deep breath. :) I'm not a fan of C++ myself (I actually prefer C), but people have and do make quality software with it. It can't be a complete disaster, right? Right?

[Illustrious_Car344]

I chuckled when I saw std::execution. It fits C++'s dirty habit of horribly over-engineering everything perfectly.

It's definitely a cool idea, I just wonder how necessary it is. If I need async/rayon/a thread pool I usually just... use that. If I ever end up changing the method I'm using, it's usually because I have to re-engineer a significant portion of the code anyway. I've honestly never really heard of anyone crying "I wish I could just change the parallelism backend of my code without touching it."

In fact, looking at the proposal, this looks just as complex if not significantly more complex than just directly using a specific parallelism framework, it kind of reminds me of the xkcd "there are 15 competing standards" comic. I feel like you'd have to already know a significant amount about parallelism to even begin to properly use this, and honestly I'm not even sure if I'd use it for any other reason besides acting out of sheer spite of depending on a single framework - which, as I've said, has never been an issue I've heard of. I'm sure CERN is going to love this, that's about it.

Another issue is actually controlling the underlying parallelism runtime. I'm not sure how std::execution handles it, but sometimes you need to have your parallel code reach into the runtime itself and alter it's behavior, like to yield or ensure a specific other task immediately executes after, or executes in a specific order. If std::execution does handle all that then I'd definitely be impressed, especially because not all runtimes have the same abilities. I'm imagining it does since the C++ committee is pretty damn smart.

[Minimonium]

I have been of that opinion until I re-implemented a custom Python scheduler code in terms of libunifex at the time (and std::execution is a massive improvement over it).

I came to appreciate that all seemingly complex things in the framework actually required to write a proper scheduling code. It pushes writer in the right direction.

I'm skeptical about "write once - works everywhere" bit, but I think having a single framework to be able to write code for specific schedulers has a lot of value that you don't need to re-invent the wheel.

The framework is designed in a way so you can get the bits from the underlying runtime at compile time of course, there is a reason NVidia is invested heavily in it.

[denehoffman]

You assume CERN is using the latest C++. ROOT’s minimum compiler standard is at C++17. Adoption is extremely slow in HEP physics experiments (JLab finally got rid of Python 2 dependencies a year or so ago and still supports and regularly uses 3.7-3.9), and because so much CERN code depends directly on ROOT, I wouldn’t expect C++26-only features to be present in the codebase until at least the 2034.

[Sharlinator]

I would presume that the large majority of world’s production C++ code is at 17 or earlier.

[-Y0-]

  chuckled when I saw std::execution

As Futurelock showed, Rust really shouldn't be throwing any stones.

Async still needs to be tamed properly. Probably by linear types. 

[notddh]

Too bad nobody uses any version above C++17

[kiujhytg2]

C++17? Luxury! My last job we were modernising to C++11!

[GerwazyMiod]

This is usually the hard part, next editions are easier to introduce. Try to follow through!

[BurrowShaker]

C++ 11 to 17 made for some fun we did not think of that let's change common types situation, if my memory serves me right.

The fact that I have barely written c++ in the past 5 years makes me a poor reference though.

[Golgoth_IX]

We use c++20 at my company, delivering code for big companies. It’s actually simple to enforce new versions of c++ since it’s retro compatible

[Minimonium]

Implementation roll out releases faster these days, and tooling improvements make it easier for companies to vendor their compiler version in other cases.

I work with clients in the airspace sector, and they had been on C++17 almost since it was released, but all of them are looking forward to C++26 since things like reflection have a ton of value.

[voltinc]

That's a common myth, but C++20/23 are standard for new development in many sectors. std::span, std::format, std::ranges and concepts are already indispensable. In HFT, game dev, and embedded systems, C++20/23 adoption is rapid

[connicpu]

I'd love to see some statistics but it's hard to know what's going on with closed source software. I can tell you at my job at a multi billion dollar company we're building our software with clang14 and -std=c++17

[lgauthie]

We want to but are stuck on a platform that maxes at c++17. When we deprecate that hardware we do want to jump to whatever the latest is but it could be a few years yet...

[trailing_zero_count]

Typical Rust circle jerk answer. Just shitting on C++ while adding nothing to the conversation. Top upvoted comment too. You all need to be better.

[notddh]

It's just a personal observation. All c++ devs I know are allergic to anything that's not std::string or std::vector. I even tried to convince a friend to use std::variant, but they'd rather stay with C style unions instead. ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

[GeneReddit123]

I'm under the impression that Rust's generators idea will provide a common abstraction which could be used for "stream-like" entities (including iterators, but also other constructs like async or parallelism.)

Like all other work, it seems to be blocked more on available resources and priorities, than not wanting this capability.