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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-03-17 08:18:43

> There are many libraries that pass this rather low bar. You are not
> saying that all such libraries qualify for standardization, are you?
> What, ASIO is way too good, we can't expect this sort of excellence from
> any other library poised to become standardized?>
> How about this bar: for a library to qualify for standardization, it
> must have retained its dominant position for at least two years without
> any interface changes. To argue that this is unreasonable is equivalent
> to stating that there is nothing wrong with changing the interface after
> standardization.

I'm not unsympathetic to this viewpoint. I've often said that nobody
should be standardising libraries which the committee invents out of
thin air, yet the committee keeps doing exactly that.

But I also think that "dominant position" is very hard nowadays. Most of
the libraries which are dominant are designed around ancient C++. They
have zero chance of standardisation. There is also the hard reality that
even if your library has been stable for years, even decades, the
committee is going to force you to completely redesign it into something
totally innovative anyway. This is exactly what has happened to ASIO,
the Networking TS will be getting close to a brand new design, a whole
new API by the time its done. Or, better worded, it was redesigned by
committee through invention out of thin air.

That suggests to not go too far down the market share route first if
your end goal is standardisation. That's simply facts on the ground,
that's the playing field, and you have to play the game that is being
played.

> Nobody is arguing that they are not good. There is no reason to
> standardize every good library out there. We should only standardize the
> ones that have already become THE standard in their respective domain.

Equally, I think most would agree that iostreams needs an overhaul for
modern C++. There is a ton of inefficiency in there, and moreover
because the language lacks understanding of stuff like i/o, the
optimiser mostly gives up when faced with trivially obvious i/o
optimisation opportunities.

This is very low hanging fruit, and it is stuff WG14 are not against
also changing for C. POSIX is also keen. It just needs someone to do the
work, coordinate the various parties, and get a common proposal over the
line.

I agree that it would be far better if multinationals sponsored this
kind of deep in-out refactoring through prototype implementation. But
they see no commercial advantage. For example, Microsoft is very well
aware that Linux file i/o is up to 80x faster than Windows' now. It's
getting embarrassing the difference. But Microsoft management can't see
how closing the gap turns into extra dollars, so they won't authorise
the works needed. They take the view that the customer will adapt if
they need to. Meanwhile, all Windows users make do with awful git
performance, and much slower compile times.

That lack of corporate sponsorship of meaningful change leaves open only
the approach of change by committee invention out of thin air. Nobody
prefers this. But what else can be done? The fact WG14 and POSIX are
warm to doing committee invention in the area of i/o shows just how much
frustration with the status quo has built up.

Niall