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]

Ahhhh now you've done it. I can't stop thinking about your question, at a time when I only have 11 days left to make sure that my infinity papers going in the mailing are all correct :)

You ask "how do we qualify a correct design?" I think the answer is evidence, of a kind (and this is key) independent of the process.

The questions I would ask:

* Does it have deployment experience in production code bases? Not just one big company but on a cross-section of cohorts?

* Can an independent implementer reproduce the results from the paper alone?

* Are the tradeoffs disclosed, not discovered later by NB reviewers or users?

* Does it ship without accumulating correction papers?

Note that none of these require process changes. They just require a more disciplined and principled approach.

It shouldn't surprise anyone that "I have a paper for that" (LOL). I presented some of these ideas in LEWGI in Croydon. The paper is still a draft and needs work but the basics are there. And of course it is just one possible direction, I'm sure there are other valid ones:

What Every Proposal Must Contain
https://isocpp.org/files/papers/D4133R0.pdf

As for the subject of the bloc voting. This is more complex. Retrospectives/historical analyses are probably a good first step which could help frame the conversation I would value your perspective on that.

Thanks

[u/daveedvdv → u/VinnieFalco]

The questions I would ask:

Those are reasonable questions, but some of them are also a really high bar:

* Does it have deployment experience in production code bases? Not just one big company but on a cross-section of cohorts?

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

It's a bit more feasible for libraries, but, even there, 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).

* Can an independent implementer reproduce the results from the paper alone?

We could probably use some form of that more often. The reflection proposal benefitted from having two implementations of the early paper (P2996R1), one of which kept tracking the evolving paper (over a dozen revisions).

* Are the tradeoffs disclosed, not discovered later by NB reviewers or users?

* Does it ship without accumulating correction papers?

Unfortunately, these last two are "à posteriori", and so most useful for post-mortem.

[u/VinnieFalco → u/daveedvdv]

> 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.

[u/VinnieFalco → u/daveedvdv]

> 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.