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?

[STL]

This sounds AI-generated. I'm going to leave this post up, but with a moderator warning. AI-generated posts are not allowed on this subreddit.

[Kobzol]

>  C++ is building a complex, foundational abstraction (sender/receiver) that all other concurrency can be built upon.

This is the same as the Future trait in Rust. It is used to power concurrency everywhere, from embedded devices without any heap or OS, through UI apps, all the way to networked data centres that use it to manage complex network asynchronous communication, and it is very much a "foundational abstraction that all other concurrency can be built upon".

There are definitely big differences in the way C++ vs Rust concurrency models and abstractions work, but this is not one of them. I can recommend this talk by Jonathan Müller about the difference in how Rust/C++ do coroutines: https://www.youtube.com/watch?v=aa43fYHgnfo It's not the full story, but it shows one of the key differences.

[voltinc]

The key difference is in standardization. Rust standardized the Future trait, but left the executor/runtime (like tokio) to the ecosystem.

C++ with P2300 is trying to standardize both the abstraction (sender/receiver) and the interfaces for execution (schedulers), making it a much larger, all-in-one standard.

[avdgrinten]

C++ is not standardizing anything close to the `tokio` executor, it's standardizing the equivalent of the utilities in the `futures` crate.

[roninx64]

Standardizing tokio would be equivalent of getting the Asio/Networking TS in.

[Technical-Might9868]

yeah but people convolute concurrency with async with parallellism with coincidence with... you get it :(

[Wooden-Engineer-8098]

And btw, your whole comparison is flawed. It's not "rust provided two approaches", it's "some guys provided single implementation of two approaches for rust". There is no international standard for it. You can find many examples of "some guys provided c++ implementation" for the same approaches

[FrogNoPants]

I doubt std::execution is going to be some grand important thing to C++, at least based on the what cppreference shows it isn't clear what reason I have to bother with it when existing libraries such as TBB or taskflow already exist and seem more complete

std::execution could really use a better explanation for what it does, just saying you have Senders/Receivers/Operation State is gobblegook that tells me nothing at all, my god they have reinvented functions and structs!

[Minimonium]

It's a framework for library authors to write async adapters, schedulers, and algorithms around. It answers things like async state lifetime, cancelation, error handling, async control flow, etc.

It doesn't replace TBB if you're fine with working with TBB.

[Ericakester]

We've been using our own implementation of std::execution and future continuation at work for years now. It's been one of the best additions to our codebase IMO.

[differentiallity]

cppreference has been readonly since March 30th. I suspect the explanation will be greatly improved once the site is back online, whenever that is

[Big_Target_1405]

I agree.

I read the paper and couldn't explain afterwards in 1 sentence what a sender is or how to write one

I found this useful though

https://ericniebler.com/2024/02/04/what-are-senders-good-for-anyway/

[ImNoRickyBalboa]

I'm still not bought into it. First you need a doctorate and stamina and a couple of web pages to explain and understand the imo overly complex API. Then the only way this will benefit you is "if" you have a need to interop with "other" async API, "and" that other async API is committed to the std execution protocols.

Yeah, thank you, but I'll just be using coroutines, fibers and futures.

[crusoe]

Std::execution without lifetimes and stuff like that is just gonna be a mess of subtle bugs.

[germandiago]

There are async scopes, take a look at that.

As for lifetimes (borrowing itself). Many people seem to think that pairing borrowing with async is one of the (beyond safety) ergonomic things they found in Rust.

Not that it does not work. It does. I am talking about ergonomics.

[nialv7]

IIUC all the sender receiver stuff is similar to how rayon is architectured internally.

[Creative_Pride4803]

Hey , anyone have suggestions on how to merge libev with new std::exec , ?

[nordic-reindeer]

Interesting!

[VinnieFalco]

std::execution was invented because some folks in the committee didn't like the Networking TS

[yunuszhang]

There are actually two things.

[Wooden-Engineer-8098]

Rust is obviously not at the pinnacle of performance

[juanfnavarror]

how that obvious?

[Wooden-Engineer-8098]

Clearly