Introduction: phrasing of advantages of Boost

[anarthal]

Which documentation does this apply to? User's Guide

Some Boost libraries can be referenced from Python.

What does this mean? Is it referring to Boost.Python? Are there Python bindings for other Boost libraries that I'm not aware of?

Boost libraries are peer reviewed, well designed, and extensively tested.

I think this should be the first bullet point.

Of lower priority is readability and compile times.

I'd be scared as a user to read this.

[alandefreitas]

Some Boost libraries can be referenced from Python.

This is also weird in that the person getting started and the person writing python bindings are hardly the same person. The statement is also trivial because you can create python bindings for almost any C++ library.

[vinniefalco]

Shouldn't we put the links to the two reddit threads in this issue? We can extract useful data from that. @joaquintides

"Advantages of boost" could have a question and answer section which comes from actual users (e.g. reddti)

[alandefreitas]

A few relevant threads are:

• Why you don't use Boost
• Is learning Boost still essential with C++20?
• Why boost doesn’t boost my productivity
• How C++17 Benefits from the Boost Libraries
• What are you most used Boost libraries?
• After 17 years of active developement, does the Boost C++ library meet its original vision?
• If Boost libraries aspire to standardization, why do they tend to depend on Boost libraries?
• Why You Should Use the Boost Software License · Peter Dimov
• Getting started with Boost in 2022
• Boost.Redis is ACCEPTED*
• Why you trust in Boost

Some pros can come from these threads. Some cons can be easily handled by improving the getting started guide. Some other threads are useful for @PeterTurcan to get used to the common complaints we have to deal with.

I think it would be good to categorize and keep track of common complaints. Even the ones we think are invalid, because they mean we can improve the documentation. Many complaints could be addressed by improving the site documentation by simply presenting the libraries differently.

For instance, one thing I keep track of in my boostdep_graph is what libraries partially overlap with alternatives in the STL and the C++ standard the libraries require by themselves or transitively. For example, consider boost.thread, which pushes any library depending on it to level 14. It's kind of easy to identify the dependency bottlenecks that make some people hate boost monolith, like the viral boost.move no one needs and everyone depends on. All C++14 libraries depend on it.

One other thing I'm trying to do to improve things is alternative releases in the new super-project release script. The current official distribution is the one with the b2 sources + docs and there's another "cmake"-distribution by Peter that just aggregates all submodules. The first distribution goes on the website but not on the github release page. This second distribution does not go to the website and goes on the github release page. Interestingly the second distribution is the one I see being used more and more around github. I think people just figured out this works with fetchcontent and started spreading the word.

In any case, to improve things "officially", in the new release process in cppalliance/boost, the workflow creates 4 artifacts: the usual b2+docs distribution (to keep things stable - 120 MB), a docs-only distribution (the one we upload to the website - 85.9 MB), a source-only distribution (since the docs is interestingly a big part of the "monolith" problem - 27.2MB), and a cmake + source-only distribution (similar to Peter's distribution in the release page - 15.5MB). Even leaving aside the fact that most of the source-only distribution is dominated by less than 5 old libraries with automatically generated files, I believe the last two distributions fix the monolith problem for most users and developers who need to fetch boost in CI. 15.5MB is a huge gain compared to the ~200MB official release and even boost developers could use it, which might be even more efficient than caching the libraries on which they depend.