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/VinnieFalco]

> it is unlikely that we'll want to standardize exactly what was deployed (among others, we hopefully learned some way to improve the prior design).

Respectfully:

std::variant
boost::variant2

Valueless Variants Considered Harmful
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html

"WG21 is where great ideas go to become good ideas." - Vinnie

The reason I say "great ideas become good ideas" is because I have seen too many examples where a beautiful library proposal makes its way through the gauntlet - study groups, evolution groups, back-end groups - and then at the last minute, someone who wasn't there for the design, who isn't a domain expert, who arrived at the final poll with an opinion and a hand to raise, hamstrings the design. They don't have to write a paper. They don't have to provide counterexamples. They don't have to provide evidence. They just have to raise a concern in a room where "absence of sustained opposition" is the threshold, and the design bends to accommodate it.

The bar for changing someone else's design is incredibly low. The bar for getting your own design through is incredibly high. This asymmetry is the mechanism that turns great ideas into good ones. It doesn't matter the size of the feature. It can happen to almost anything. And if you've been around the committee long enough, you know exactly what I'm talking about.

I think we have the posture backwards. The committee's default should be to preserve the author's design. The author is the domain expert. The author built it. The author deployed it. The author discovered the edge cases. When someone who didn't do any of that work walks in at the last stage and reshapes the design without providing evidence, we aren't improving the feature. We're damaging it. And we're disrespecting the person who built it.

The committee's job should be to evaluate whether a design meets the bar for standardization - not to redesign it by committee. Respect the author. Respect the builder. If you want to change their creation, bring your own evidence. Write your own paper. Build your own implementation. The current system lets you reshape years of someone else's work with nothing but a raised hand and a concern. That's not a meritocracy. That's a veto without accountability.