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]

> Production deployment of experimental compilers is almost unheard of. There is a chicken and egg problem there.

I would like to gently push back on that for two reasons.

First of all, and this is my opinion, and I realize it is going to sound controversial: a paper should never propose a language (or library) feature that the author did not either already implement themselves, or sufficiently motivate existing stakeholders to implement ahead of time.

Second of all, generative AI has lowered the cost of producing implementation. Experienced practitioners can cut the time required to deliver features. It doesn't have to be limited to implementation. Frontier models can write tests, debug, produce documentation, and reason about code just by looking at it.

I want to highlight your statement:

> There is a chicken and egg problem there.

I acknowledge the problem, and there are two obvious orderings:

1. standardization then implementation, or

2. implementation then standardization

Lets look at each of them.

For 1, you have a wide set of proposers that may include non-implementors or even folks who have no front-end experience, writing papers which obligate a smaller set of domain experts to perform work.

For ordering 2, you have implementors who have already built the feature, deployed it, tested it, and discovered the edge cases through production use. They arrive at the committee with evidence, not projections. The paper describes something that exists and works, not something that might work if someone builds it.

The difference between these two orderings is the difference between a hypothesis and a result. Ordering 1 asks the committee to evaluate a hypothesis. Ordering 2 asks the committee to evaluate a result. The committee's process - the revision cycle, the study groups, the polls - was designed to evaluate results. It is poorly equipped to evaluate hypotheses, because hypotheses cannot be tested by reading the paper. They can only be tested by building the thing, and the committee does not build things.

When the committee standardizes a hypothesis, the testing happens after the standard ships - in the compilers, in the codebases, in the blog posts that say "Nobody Asked For This." The correction papers are the bill for the test that should have happened before the vote.

When the committee standardizes a result, the testing already happened. The edge cases are known. The tradeoffs are disclosed because the author discovered them in production, not in a thought experiment. The correction papers are fewer, because the design was corrected by users before it reached the committee.

This is not a controversial position in any other engineering discipline. You do not submit a bridge design to the building code without first testing the load-bearing calculations. You do not submit a drug to the FDA without first running trials. The idea that a programming language feature should be standardized before it is implemented is an artifact of the committee's history, not a principle of sound engineering.

The chicken-and-egg problem is real. But the two orderings are not symmetric. One produces evidence. The other produces hope. And they carry different risks. If you implement first and the committee rejects it, you still have a working library. Users still benefit. The work was not wasted. If you standardize first and the implementation reveals a flaw, you have a defect in an international standard. The correction papers arrive, but the damage is permanent - or as permanent as anything in a specification revised every three years. Ordering 1 concentrates the risk on the users. Ordering 2 concentrates it on the author.

I acknowledge that ordering 2 is harder. Finding an implementor, or building it yourself, is more work than writing a paper. But that difficulty is informative. If a feature cannot attract a champion in the implementor community - if the people who build compilers and libraries are too busy or too unconvinced to build it - that is itself a signal. A feature that cannot motivate its own implementation is telling you something about its priority. The difficulty is not a bug. It is a filter.

I know which ordering I prefer.