Re: [boost] [Async] Naming land grab?

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