Re: [Asset Stewardship] About the Beman Project

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-09-10 22:42:26

On Tue, Sep 10, 2024 at 2:34 PM David Sankel via Boost
<boost_at_[hidden]> wrote:
> ...Boost is not part of the incubation process for most libraries going into the standard.
> As to why this is the case, I don't think anyone knows for sure.

I have a theory. There are two approaches to building standard library
components:

Approach A:
1. Think of a useful library and write it
2. Maintain and improve the library
3. Propose it for the standard

Approach B:
1. Think of something for the standard
2. Write a paper and/or reference implementation
3. Propose it for the standard

Both of these approaches have the same end result: a new library added
to the standard. And yet there are big differences between them:

What kind of person goes for each approach?
A: Someone who loves having users
B: Someone who loves getting something into the standard

Who does the author have in mind when writing the library?
A: The general C++ community
B: The people voting in WG21

What does the competition look like?
A: Anyone can write a competing library on equal footing
B: Standardized library components have a built-in competitive advantage

What is the influence of politics?
A: Politics can't make people use your library if it sucks
B: In the WG21 bureaucracy, playing politics is essential (cue Gor's
quote that "90% of the work of landing coroutines was non-technical")

There are statements made which refer to "Boost's original purpose"
and such, but this entirely misses the point. Boost used "Approach A"
to get libraries into the standard. Authors wrote useful things such
as boost::shared_ptr. They were adopted by the community, and then
they made their way into the standard. The committee moved slowly
then, so libraries had time to bake. The problem with WG21 is not that
people aren't writing the libraries first before submitting the paper,
it is that they are writing the library with standardization in mind
first and foremost, rather than satisfying the larger community of C++
users.

It helps to look at some examples:

fmtlib::fmt (now std::format)

This library came out in 2015. It was immediately useful and found its
way into many projects. It had to compete with std and other
libraries, and it won. Many users, many improvements. The paper was
not presented until two years later, and it went through a couple of
years of revisions. This used Approach A. std::format is a great
standard library facility, and became so because it was forged in the
fires of competition.

Asio

This library joined Boost in 2005. It underwent many revisions and was
adopted in quite a few code bases. No other library offers the
portability and adherence to C++ idioms that Asio offers. It gained
many users, and many other libraries were written on top of it (second
order effects). This used Approach A. The Networking TS was proposed,
but certain factions in WG21 had Other Ideas and it was scuttled. The
consequence is that C++ still cannot connect to the Internet. And
there is no relief in sight.

std::ranges

This is basically version 3 of Boost.Range. The author decided it
would be better to write it as direct-to-standard as that would be
easier than going through Boost. And the Standard C++ Foundation paid
the author to do the work, with a directive to emphasize the use of
concepts to drive adoption of the newer C++ language versions (I
think). This used Approach B. std::ranges was effectively impossible
to implement without the new language features, so users did not
really have the opportunity to try it. That is, std::ranges was never
exposed to the competitive marketplace of users. Compare this with
Boost.Range, which never went into the standard and was developed with
Approach A. It is still used today, because it is useful (not overly
complex). Companies are now realizing the shortcomings of std::ranges
and investigating alternatives. Example:

Rappel: Compose Algorithms, Not Iterators
Google's Alternative to Ranges
https://www.youtube.com/watch?v=itnyR9j8y6E

std::execution

This started out as a series of papers which gained the informal term
"Senders/Receivers." Its alternative model of asynchrony competed with
the Networking TS, so the Asio-based paper became politically
disfavored and abandoned in favor of the new thing which is now called
std::execution. This is an example of Approach B. std::execution never
gained any meaningful users, and was never exposed to the competitive
marketplace of users. Most users who do not follow WG21 comment on the
complexity and foreign look of example code related to std::execution.
Like std::ranges, companies are already anticipating that the std
story for asynchrony is going to be dysfunctional on arrival and
investigating alternatives. Example:

https://www.youtube.com/watch?v=nQpXOx0D7I8

I believe that making standardization the primary goal is a mistake.
The goal must always be to satisfy users by delivering something
useful. The standardization follows, and does not lead. This is why
Boost is now more important than ever: WG21 is incapable of competing
in the library marketplace.

Thanks