Re: Technical Excellence?

From: Daniela Engert (dani_at_[hidden])
Date: 2024-03-27 17:07:47

Am 27.03.2024 um 14:47 schrieb Vinnie Falco via Boost:
> 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
>
That's a diverse collection of criteria that may or may not guide 
adoption of new libraries into Boost.

As a long-term user, contributor, and maintainer of our in-house flavour 
of Boost, I want to share *my* point of view to answer your question. In 
my opinion, Boost is lacking a vision (the original one doesn't seem to 
be alive anymore).

Is Boost
 Â - a framework? This means Boost.x uses facilities from Boost.y even 
when there is a viable alternative in the standard library (or a 
non-Boost library with the same API), but rather insists on the Boost.y 
dependency.
 Â - a polyfill? This means Boost.x strives to depend on standard library 
facilities as much as possible - at least as configuration option.
 Â - a loose collection of libraries that share a common moniker? This 
means that every library developer does what they see fit according to 
their assessment of the state of the ecosystem.
 Â - a showcase of avantgarde, high-quality C++ building blocks that 
every developer is proud to use, and can look at to learn about good C++ 
for their own advancement?

If it's the first, then be clear about that. And tell prospective users 
that they should expect huge Boost dependency chains. My teammates get 
*all* of Boost from our in-house distribution because that's where they 
end up anyway to some degree if they decide to take advantage of one the 
heavy-weight libraries.

If it's the second then the question about the minimum supported C++ 
standard or compiler toolset becomes moot. But then you have to think 
hard about the adoption of ne libraries because you most likely want to 
backport them. And each individual library needs to provide 
configuration options to let go other Boost libraries if the consumer 
decides so (like std::variant instead of boost::variant, std::shared_ptr 
instead of boost::shared_ptr, vanilla Asio instead of boost::asio). If 
the user rather accepts performance hits by using standard facilities 
over alledgedly superiour Boost alternatives, that's fine. Every 
additional dependency has a cost, most certainly in compile times.

If it's the third, then you may keep the status-quo. Everything goes. 
Consumers need to assess if a certain Boost library is worth the efforts 
to depend on over the projected course of their project.

If it's the last option, go for it! Don't accept "me too" libraries. 
Require recent toolsets. Require the current language standard. Show 
what you can do with contemporary C++. The bar for adoption needs to be 
high.

When I look at the projects in the company that I work, for I see a 
decline in the use of Boost. This is despite the fact that our build 
system makes Boost available *by default*, it's an implicit dependency 
nobody has to care about! There are projects that no longer use Boost 
because of the noticable increase in compile times. There are projects 
that replace Boost libraries with non-Boost libraries that have no or 
much shorter dependency chains. There are projects that spend serious 
efforts to create alternatives to existing Boost libraries. Because of 
all of that, I'll drop as much from the next distribution as I possibly 
can and divert my time elsewhere. I don't like that, but this is how 
things are in 2024.

Thanks,
 Â  Dani

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5