Re: [boost] Boost, not LEWG

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 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@lists.boost.org> 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@lists.boost.org> wrote:

...

On 2020-06-30 12:42, Vinnie Falco via Boost wrote:

...

On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost

...

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