Re: [Async] Naming land grab?

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2023-10-09 16:56:51

On 09/10/2023 16:01, John Maddock via Boost wrote:
> On 09/10/2023 10:12, Hans Dembinski via Boost wrote:
>>> On 9. Oct 2023, at 09:27, oliver.kowalke--- via Boost 
>>> <boost_at_[hidden]> wrote:
>>>
>>>> This is an alpha
>>>> library and should come back when its >place in the ecosystem has 
>>>> solidified.
>>> I disagree because this restriction was not required in the past. It 
>>> seems to me unfair to make it mandatory now.
>> I am using Oliver's comment to add my own.
>>
>> Klemens obviously has a good amount of stars and forks, which signals 
>> interest from the community, so he does not need me to defend his 
>> proposal. But I also want to give my option on "should libraries 
>> proposed for adoption have many users already?".
>>
>> Whether or not a library has a lot of users before submission is 
>> fairly irrelevant. It can be a point in favour, but does not have to 
>> be. It may address the question "is this library useful"? but does not 
>> tell whether the library is well designed. Some people need a lot of 
>> user feedback to refine the design, others are good internal critics 
>> and can improve without external feedback. Both are valid approaches 
>> to design and suit different people. Obviously, everyone needs some 
>> external feedback, but it is quality and not quantity that matters.
>>
>> Also, we all know from politics and examples in tech, that popularity 
>> is not always a good measure of quality.
>>
>> Usefulness, design, quality, etc are judged by the reviewers. I have 
>> high confidence in the Boost reviewers to make this assessment. Users 
>> do not get to vote on acceptance, Boost members do. Boost is a 
>> meritocracy, not a democracy.
> 
> +1.  Also just to add to that, existing libraries with wide user bases 
> come with a legacy that may may it harder for them to make radical 
> improvements to the user interface should that be required.  On the 
> other hand brilliant interface design with no user experience also 
> carries it's risks.  This is what reviews are for, to balance all this 
> up, and it's good to see some discussion being generated again.
> 
> It's also worth pointing out that Boost when founded was a place for 
> radical bleeding edge design and experimentation, I see no reason for it 
> not still be so as long as such libraries are well documented as such.
> 
> With apologies, I'll now go back to lurking again, as I have no 
> knowledge of the problem domain...

Ah nothing like lots of post-review discussion to make the writing of 
the review report easier!

(Apologies for replying to your reply John, yours was just the latest in 
the chain which is why I chose it)

Firstly, I hope to complete writing the review conditions and report 
this Wednesday. I won't promise it, I set aside last Wednesday morning 
and then stuff came up and it didn't end up happening. But I'll keep 
retrying until I get it done. I apologise for the delay, I am doing my best.

Secondly, please do not challenge the review until I've actually 
published the review conditions and report. This particular review 
currently has three major conditions in my draft report, and it may gain 
more before I'm done. If after its publishing then people feel it was a 
bad review, rock on with lodging challenges.

Thirdly, I have no idea why Boost has become so conservative about new 
libraries recently. There is a long and proud tradition of Boost 
publishing crazy new libraries that so pushed the state of the art they 
didn't even compile on ANY compiler bar one compiled from trunk. They 
certainly by definition had ZERO users. We also used to - once upon a 
time - be comfortable with publishing a library, finding out after users 
complained it was badly flawed, so then we made a v2 of that library 
with all those problems fixed and quietly deprecated/discouraged the 
further use of the v1 library. And whilst not ideal, that's exactly how 
states of the art get pushed. Sure, it would be even better if a library 
had lots of users first, but there can be a chicken and egg problem for 
particularly radical libraries - until somebody solves a problem, nobody 
realises that that problem should be solved that way.

Right now C++ coroutines have a bad rep in the C++ userbase, and they 
are currently quite unpopular as we saw from the Reddit reaction to the 
announcement of the review of this library. However that won't last, 
eventually the userbase will warm to using them where they solve well 
what they're good at solving well, and more importantly, not using them 
to solve what coroutines solve elsewhere, because C++ coroutines != 
coroutines elsewhere.

I don't know if when people warm up to C++ coroutines they'll reach for 
proposed Boost.Async. If they do not, an equally beneficial outcome for 
Boost and/or the C++ ecosystem is if they make a new C++ coroutine 
library which incorporates the ideas from proposed Boost.Async but 
iterates on them. And if that happens, Boost will have enabled that, 
which is exactly what Boost is supposed to do.

In this I'm seeing lots of upsides across the board. I also disagree 
that Boost gets hurt by experimental libraries which don't work out. 
Nobody using Boost will ever be forced to use proposed Boost.Async. If 
it doesn't work out, it will have literally zero negative effect on 
Boost users apart from a slightly longer download time.

In my opinion, a much more likely outcome is that accepting new 
experimental libraries make watching Boost a must to see what comes. 
Most of the lurkers on here are here precisely because Boost can be a 
weather vane onto the future of C++. More experimental libraries makes 
Boost more relevant in my opinion, even if some will fail to gain 
traction. Without taking a risk, we would never know.

Speaking personally, C++ coroutine programming is tedious and annoying 
with the current C++ coroutine library frameworks. Proposed Boost.Async 
restores much of the fun and joy in writing C++, albeit with tradeoffs, 
but nothing comes for free.

At my last job we had a set of custom completion tokens for ASIO which 
implemented a very similar solution to proposed Boost.ASIO. At my 
current job I just finished up last week C++ coroutine support which - 
surprise surprise - looks awfully like proposed Boost.Async again 
(except these are based on io_uring and use Niall's "much improved" 
Sender-Receiver design which WG21 rejected).

I think there are only a very few of us with sufficient domain expertise 
in this area to be able to judge whether proposed Boost.Async is a solid 
generalised solution to this problem domain. I don't claim to be one of 
them, but having implemented something similar twice now, and having 
been "in the room" throughout WG21's labours on Sender-Receiver and 
ASIO, even though WG21 rejected almost everything I said or proposed I 
would like to think I am less misguided than they are :)

Even if I am very misguided, I think accepting this library is worth the 
punt. It'll be an accept with conditions, and the report will be long as 
there will be a short list of binding conditions and a long list of 
non-binding conditions. I'll get it to you all when I can.

Niall