Re: Boost, not LEWG

From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2020-07-01 04:44:33

So I'm going to chime in here, in aggregate. I will try to focus on
answering the question of "What is Boost Good For?" from the
perspective of a user, and as a user having participated in reviews.
It's a large brain dump, so there's probably typos and other bad
things.

[[ Boost and the Ecosystem ]]
In my opinion, Boost is not dead (no great software library is), but
it has waned in usefulness substantially. You don't even have to take
my word for it, Boost authors already did some basic sleuthing about
it:

https://www.reddit.com/r/cpp/comments/gfr46l/why_you_trust_in_boost/
https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/

You'll note that the "don't use boost" had many more comments and
upvotes, whereas the "trust in boost" had many less comments and
upvotes. Reading both confirms some of my own biases, which is that
Boost, as an ecosystem, does not offer a lot of bang for its buck
because it exists in a space where it competes with the Standard
Library, and does not complement it.

This creates an interesting problem. I could use Boost.Container's
vector, but what benefit does it offer me over std::vector, except
that it has more predictable performance characteristics in
now-10-year-old STLs? (It's not better than the current STL; I
measured.) I could use Boost's type traits, or I could require C++11,
work around GCC4.8 being a nightmare, and no longer have that source
dependency. I could use things from Boost.Core, but I could also just
move to C++11/14 and obsolete many of its usages. And so on, and so
forth.

Opting into the boost ecosystem is expensive, insofar that it's a
really bad trade for interop. I can't talk to external libraries with
Boost's vector, or its unordered map, optional (even if the Standard's
is strictly worse in every way), variant, etc.. Interoperability
matters, which means boost usage in "middleware" libraries -- at least
on its edges and boundaries -- drops off a cliff. Boost is not "the
glue that holds a really shitty C++ universe together" (C++03 and
before), it becomes "the thing that costs me maintenance hours and I
have to spend extra time supporting in my abstractions" (C++11 and
above).

Another point: note that Meeting C++'s survey about regular expression
showed that an OBSCENE number of people used std::regex, despite it
being the literal worst part of every std:: implementation (aside from
wstring_convert), with the reason "because it is there". You need to
make an EXTREMELY compelling sell to get more people to pick up your
library, and if the majority of your libraries are "compete with the
standard", you will lose even if the performance of the Standard is
actual dog poo. Speaking of performance...

[[ Boost and Performance ]]

Further hurting Boost's proposition in the ecosystem is its
performance characteristics and its inability to capitalize on
decades-old ideas. My computer is still shot so I cannot yield the
benchmarks and everything, but finding out that I could read 2 Boost
Author's std papers on allocations and other tricks (Howard Hinnant,
Ion Gaztanaga) and find that neither of the tangible performance gains
they described were implemented in Boost's Allocators or Containers
means I had absolutely no compelling reason to pick Boost over the
Standard for the thing I was rolling (in this case, my own std::vector
or other containers).

Boost -- for its basic abstractions -- do not provide compelling
improvements over the status quo for fundamental things for me to care
enough about Boost alternatives to core things to begin with. (This
changes with things like Peter Dimov's boost::variant2, which offer
tradeoffs I as an application developer are deeply interested in for
many domains, and thus pays off).

This speaks to the ways Boost is used now: for very specific use cases
not covered by the standard, and very specific performance metrics the
standard never will meet.

[[ Boost and Tradeoffs ]]

Unless I pick a very specific library (StaticString, SML, variant2,
Log, String Algorithms, ASIO, Beast, etc.) that offers me a very
tangible gain in "yes, absolutely, this accelerates my development and
has acceptable performance characteristics", Boost's general core is
not worth it. It's monolithic nature makes it hard to opt into many of
its smaller libraries "just because". Distribution is often an extreme
pain in the ass. Build system gripes are ripe in the reddit threads,
and there's been at least 3 (!!) official,
they-recorded-this-for-1+-hours-and-practiced-this-for-many-more-hours
talks about getting Boost to different build systems and modularizing
boost. If that isn't enough of an indication that Boost's method of
distribution maybe needs to be looked at more closely, I honestly
don't know how to explain the need better!

Before, that monolith was great: the Standard was, quite frankly, hot
steaming garbage so Boost's core made all that go away and provided
stability amongst the insanity of many compilers. That is not the case
anymore, and accepting the costs of the monolith in exchange for only
a handful of libraries is often a far worse trade, especially if that
library does not come with distinct gains. This is why people keep
asking for "Boost, but based on a higher standard"; this is not just
because "unga bunga cruft bad", it's because they want to see /more/
useful libraries that pushed the boundaries of C++ farther out than
ever before, just like Boost did in the 2000's.

[[ Boost and The People's Needs ]]

As I stated before, people's needs have shifted. C++ is not The
Badlands anymore, and even MSVC is coming out to play nice. Boost is
having a problem addressing the needs people have, today, which are
sometimes extremely niche. This is why I am partly disappointed by the
result of the Text Review.

As I stated in my review, Text in C++ sucks. Boost does not do better
than the Standard, save for some string algorithms and some basic
Locale "improvements". This was a chance, even if not perfect, to
provide a library that really made Boost stand out as "has something
the Standard can only dream of". boost::text's "text" container -- as
the kids would say -- slapped. Grapheme cluster iterators, utf8
storage, insertion and removal based on what most people perceive as
characters handled transparently for me?? That's the wet dream of text
management. Coupled with a Stepanov reimagining of Standard Unicode
algorithms that were just a straight translation of the pointer-based,
weird ICU interfaces, absolutely. Yes, not having allocators was
terrible and not having the ability to choose underlying encoding
sucked, but it got *most* people a good chunk of the way. There was
room for going backwards and filling out the problems in v2.

Not having the library -- and encouraging the text layer not to come
back as part of the next resubmission of the library -- is a huge blow
to "this really addresses one of the serious contemporary C++
problems". Maybe Zach will resubmit that layer, but we missed out on
the sweet spot of addressing a need that neither Standard C++ nor most
shops handle nicely. I do hope the library comes back!

This also speaks to LEWG. In all frankness, if Boost's purpose is to
be invalidated by the Standard every 3 or 6 years, why waste the time
submitting to Boost when Boost is just "standard, but outside and
sometimes before the standard"? If your goal becomes "Lots of C++11
that fill the gaps", well then duh nobody's going to submit new stuff
to Boost because you've made it explicitly clear your job is being a
polyfill for old libraries, not providing new, cutting edge libraries
like 20-years-ago Boost was.

[[ In Conclusion ]]

Boost is successful. Not was: is. But its original space has been
consumed by the standard, and if we want to enjoy a "Boost
Renaissance", we need to address people's needs and meet them where
they are, rather than keep trying to pull them into a way of Boost
that is, quite frankly, no longer necessary in many ways. Higher
standards. Libraries that provide good tradeoffs. Libraries that
address the needs that are going out in front of people today, not the
needs 10 or 15 years ago.

Boost may need to actually reach out to people and very much handhold
them through the process of library submission, review, and
improvement to convince a few key cases that Boost is still extremely
relevant to modern needs. Maybe that will bring in even more folk;
encourage them to submit here, once they see that Boost libraries are
once more the place to go to solve real problems, with a tangible
feedback loop. Right now it's hard to gauge the effect of a Boost
library, since Boost is doing very little to distinguish itself from
the Standard (again, why go through Boost if you can do GitHub + LEWGI
+ LEWG + LWG instead?). Boost should be the cutting edge again. This
does not mean the quality has to go down: but there should be active
encouragement of exploration of new topics OR addressing people's
needs. Boost.Text, Boost.Unicode, maybe even Boost.Audio, and more...

[[ Mailing Lists and Tools In General ]]
Mailing lists are fine for power users. And yes, I really mean power users!

This could be my young buck inexperience showing, but there is a real
problem with having to manage a lot of these things yourself. While
people can configure amazing awesome mail clients capable of great
feats, most of us don't have anything like that. Some small examples:
- I had no idea what "top posting" was until someone informed me that
(by default) g-mail's reply feature was automatically top posting.
There is, of course, no way to change this in the options, but it is
still against Boost etiquette to do so. So now I need to manually
relocate the start of my post, and I have to do this every time I
start an e-mail.
- Tracking threads is hilarious in an e-mail client. This single post
has ended up in 3-4 different threads, sometimes because some people's
mailing client clears out response IDs and other times because it was
a deliberate fork. I have no idea, and now I have to track the 4
threads to this, often without any context of where this thing came
from even if I scroll up *this* thread in particular.
- Formatting. Boost's mailing list is nice enough to accept my HTML
e-mails, but I have no assurance my e-mails are <b>NOT</b> showing up
<i>strangely</i> for everyone now with weird things (so I have to
default to plain text and, essentially, make up some form of /markup/
in my head or use what I've observed about the mailing list).
Consistent formatting (e.g., "everyone uses markdown and that's what
renders") brokers a common ground between mailing list users for code
formatting, emphasis, and general text decorum / presentation.

Basically, mailing lists are wild-wild wests of formatting and
quality. A platform that got rid of that etiquette and just let me
conform to an established format (GitHub Issues, etc.) greatly lowers
the barrier to being able to speak up.

On Tue, Jun 30, 2020 at 12:41 PM Andrey Semashev via Boost
<boost_at_[hidden]> wrote:
>
> On 2020-06-30 19:32, Peter Barker via Boost wrote:
> > On Tue, 30 Jun 2020 at 17:12, Andrey Semashev via Boost <
> > boost_at_[hidden]> wrote:
> >
> >> On 2020-06-30 18:30, Peter Barker via Boost wrote:
> >>> On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost <
> >>> boost_at_[hidden]> wrote:
> >>>
> >>>> On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
> >>>>> On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <boost_at_[hidden]
> >>>
> >>>> wrote:
> >>>>>> Why are people equating forums with SO?
> >>>>>
> >>>>> That was my unfortunate mistake. I only used the comparison to
> >>>>> highlight how the immediacy of visiting a website is different from
> >>>>> having to register for a mailing list.
> >>>>
> >>>> You still have to register on StackOverflow.
> >>>>
> >>> Only to post, upvote and comment, etc. You don't have to register if you
> >>> want to visit and browse the questions and answers. If Boost moved to a
> >>> forum it'd be analogous.
> >>
> >> You can browse mail list archive without registration.
> >
> > I was just correcting your statement about needing to register on
> > StackOverflow.
>
> And I was pointing out that there is no difference between StackOverflow
> and mailing list in terms of immediacy of access.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost