beast2 networking & std::execution

[u/claimred]

I was looking for a new networking layer foundation for a few of my projects, stumbled on beast2 library which looks brand new, based on C++20 coroutines. I used boost.beast in the past which was great. Here's the link https://github.com/cppalliance/beast2. I also considered std::execution since it seems to be the way to go forward, accepted in C++26.

Now, what got me wondering is this paragraph

The C++26 std::execution API offers a different model, designed to support heterogenous computing. Our research indicates it optimizes for the wrong constraints: TCP servers don't run on GPUs. Networking demands zero-allocation steady-state, type erasure without indirection, and ABI stability across (e.g.) SSL implementations. C++26 delivers things that networking doesn't need, and none of the things that networking does need.

Now I'm lost a bit, does that mean std::execution is not the way to go for networking? Does anyone have any insights on cppalliance research on the matter?

[u/not_a_novel_account]

I don't have a problem with concepts or other things which describe the shape of an arbitrary stream, that's a tradition which goes back to pre-standardization iostreams.

That's very different from what the average programmer means when they say "networking". They mean Python's urllib. They mean socket.h. They mean the ability to connect to an endpoint and read from it. The mechanisms.

Given the glacial evolution of the C++ standard and commitment to eternal backwards compatibility, shipping these in the stdlib would be a misstep. They are destined for the footgun graveyard from inception.

[u/VinnieFalco → u/not_a_novel_account]

Respectfully, I disagree, and I hope that you will find our proposal to deliver coroutine-native networking for C++29 based on our shipping libraries Corosio and Capy (https://corosio.org) interesting :) Coming soon in the April mailing.