Technical Excellence?

27 Mar 2024

      I guess I'm confused. My understanding is that libraries are considered
good candidates for the Boost collection based on meeting some or all of
certain criteria:

* They offer useful, novel functionality not found elsewhere
* The API is superior to other libraries that do similar things
* The implementation is exceptionally performant
* Solving a familiar problem in a particularly elegant fashion
* The library is already popular and has field experience
* The library offers C++ standard functionality for older compilers

But some of the chatter on the mailing list suggests that the bar for a
Boost library candidate is lower. That a library just needs to basically
work, even if it duplicates functionality found elsewhere, or even if it
does not have anything that one might hold up as an example of exceptional
engineering.

Boost libraries used to be cutting edge, to such an extent that they were
adopted into the C++ Standard. And now the progress is in reverse. The
Standard introduces a new component, and the Boost library follows
(Boost.Charconv for example). In other cases I see libraries with few to no
users limping into reviews, or absent discussions which question whether or
not the bar for excellence is exceeded. When I used to participate in wg21
I complained about the "direct to standard" pipeline, where people would
just write papers for the sake of it with no example code or real-world
user experience. I have to wonder if we are not cultivating a "direct to
Boost" pipeline by having relaxed or poorly-defined acceptance criteria.

There are thousands of open-source libraries for doing things in a fashion
that is "good enough." If libraries are not held to technical excellence
and high standards during the review process then what is the value
proposition of the collection? If libraries of average design and
implementation are seen as passable for acceptance then how would this
inspire any authors to strive for excellence?

When I write a library there are always two factors in my mind: 1. that the
use-case is compelling, and 2. that I can bring something to the table
which demonstrates technical excellence. These are the libraries that I
have contributed thus far and my process for designing them:

1. Boost.Beast

This offers something never seen before which is a generic approach to HTTP
and Websocket, based on Asio, which offers models and algorithms that are
designed well (of course, it still has its flaws). The library already had
many users ahead of the review, and was being used to transact economic
value in a live product. I will note that my initial motivation for Beast
was because the websocketpp library API was just terrible, and the
alternatives even worse.

2. Boost.JSON

When I needed JSON I looked at the alternatives and while RapidJSON was
clearly the best in terms of performance I felt that it made several major
design flaws in its API. Boost.JSON pretty much copies all of the good
ideas from RapidJSON especially the performant implementation, and offers a
redesigned API that follows C++ best practices with respect to copy and
move, exceptions, and error codes. Furthermore I added the streaming parser
and I introduced a novel means of managing memory resources which I believe
corrects a design flaw in the standard. This library already had commercial
users and lots of feedback before going into review.

3. Boost.URL

Beast users regularly asked for URL parsing. There are some regex patterns
floating around and some Spirit based parsers, and also some URL libraries
that do the "five std::string data members" thing. I wanted something
excellent, but the first two iterations of an API turned out to be crap and
I gave up, as I do not like publishing mediocre libraries. Some time passed
and with renewed energy I tried again and then I got it right. The URL is
stored in its serialized form (just one string), allowing the possibility
for having a url_view type in addition to the mutable container. I copied
much of the API from a popular JS URL lib because, well hey why duplicate
the effort if someone has already gone through the trouble :) Boost.URL
offers particularly clean and robust interfaces for reading and modifying
the values of each part of the URL both with and without the URL-encoding
applied. The mechanism for lazily iterating the path and query sequences is
novel. And it offers a strong invariant: the container will always contain
a valid URL. The library further innovates by making public its parsing
framework which is optimized for the type of grammars found in the Internet
RFCs such as HTTP and the fields used in Websocket handshakes. Boost.URL
had a bunch of users before the review was conducted.

4. Boost.StaticString

This one is just a straightforward string container whose storage is fixed
in capacity as a data member. Container libraries are often unexciting but
they are necessary. StaticString follows all best practices for modern C++
containers.

When I look at a proposed library I try to figure out what is great about
it, how well it performs for its users (or even, does it have any users?),
what part of the API is exceptionally well designed and ergonomic, but most
importantly I want to ask: what makes this library stand out to the extent
that it should be part of the library collection? What aspects of the
library, if viewed by someone learning C++ or interested in improving their
design skills, are inspirational?

Is this overly demanding or exclusionary? Am I overthinking things? Should
we be asking more of these types of questions and requiring better answers?

What is the criteria for determining if a library is good enough to become
part of the collection?

Thanks

Vinnie Falco

Marcelo Zimbres Silva

Robert Ramey

Vinnie Falco

Andrey Semashev

Robert Ramey

Vinnie Falco

René Ferdinand Rivera Morell

Andrey Semashev

Robert Ramey

Glen Fernandes

Vinnie Falco

Rainer Deyke

Vinnie Falco

Andrey Semashev

Daniele Lupo

Brook Milligan

Alain O' Miniussi

Robert Ramey

Marc Viala

Jeff Garland

Marc Viala

Klemens Morgenstern

Rainer Deyke

Klemens Morgenstern

John Maddock

Andrey Semashev

Daniele Lupo

John Maddock

Artyom Beilis

Daniele Lupo

Andrey Semashev

Daniele Lupo

Andrey Semashev

Artyom Beilis

Boris Kolpackov

Daniele Lupo

Peter Dimov

Andrey Semashev

Peter Dimov

Rainer Deyke

Nigel Stewart

Jakob Lövhall

Christian Mazakas

Peter Dimov

Ivan Matek

Vinnie Falco

Daniela Engert

Peter Dimov

Daniele Lupo

Ivan Matek

Peter Dimov

Ivan Matek

Peter Dimov

Andrey Semashev

Arno Schoedl

Peter Dimov

Ivan Matek

Peter Dimov

John Maddock

Peter Dimov

Vinnie Falco

John Maddock

Daniela Engert

Niall Douglas

Vinnie Falco

Peter Dimov

Artyom Beilis

Vinnie Falco

Dominique Devienne

Vinnie Falco

Matt Borland

Artyom Beilis

Matt Borland

Artyom Beilis

Vinnie Falco

Jeff Garland

Vinnie Falco

Jeff Garland