Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!

Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
From: Jon Kalb (jonkalb_at_[hidden])
Date: 2019-03-17 01:56:56

I try to avoid saying that something must be in Boost before being accepted in std, because I don’t want it to sound like a gate keeper, but there simply is no close second to the Boost libraries for exposure and user base.

I don’t want to cast aspersions on these particular libraries (particularly since I consider some of these authors to be personal friends), nor to I want to  belittle this:

> On Sat, Mar 16, 2019 at 4:55 PM Niall Douglas via Boost-users <boost-users_at_[hidden] <mailto:boost-users_at_[hidden]>> wrote:
> > But it's not like they lack implementation and userbase experience,
> > either. Most of these are multi-year old codebases with real world users
> > using them in production, and giving ample feedback rounding off the
> > rough edges over time.

But as Emil said:

> There are many libraries that pass this rather low bar.

Of any individual C++ library author today, my guess is that Eric would have the best chance of attracting a large user base for his personal GitHub, but I would still consider that exposure as below the bar of what I’d like to see for a library that we are going to put into the standard (given that, once in, we’ll never be able to drop support or modify the ABI).

Even if a library is being used by a bajillion developers at MegaCorp, I’m not willing to waiver on this. All those developers are unlikely to be using the library with as diverse a set of applications and environments as will be done by Boost users.

I know that getting a library into Boost is no small task (Niall may know that better than anyone on the planet), but if it is worth putting in std then it is worth putting in Boost first. If it isn’t worth the effort to put it into Boost, then it isn’t ready to become part of the library that we have to live with forever. If there is no time to put it into Boost first, then it is definitely being rushed.

The feedback that authors receive during the review process and from being deployed to tens of thousands of users is simply unavailable any other way. The insight gained by maintaining a library over a few release cycles for use by thousands of users in thousands of diverse applications on every conceivable platform and configuration will effect the API for the better in ways that cannot be foreseen and are likely to be under-appreciated.

Put it Boost first. (Or any other library with over 100K users and on almost every platform in modern use.)

Jon