Hi all, At C++Now this year I gave a talk on the status of Boost and presented this graph which illustrated the trend of Boost mailing list participation. https://docs.google.com/presentation/d/1ocX8Dh4B98gxfXJTWOriaEU1tmJN61M4RfjU... I'm interested to hear your opinions as to what happened over that time period to cause such a trend. There's truth to the claim that this question is being asked of the wrong people; those who left, stopped participating, or would otherwise start probably have good insight. Nevertheless, I think it would be interesting for us to brainstorm on this. Thanks in advance for your thoughts. -- David
On 03/12/2022 02:02, David Sankel via Boost wrote:
Hi all,
At C++Now this year I gave a talk on the status of Boost and presented this graph which illustrated the trend of Boost mailing list participation.
https://docs.google.com/presentation/d/1ocX8Dh4B98gxfXJTWOriaEU1tmJN61M4RfjU...
I'm interested to hear your opinions as to what happened over that time period to cause such a trend. There's truth to the claim that this question is being asked of the wrong people; those who left, stopped participating, or would otherwise start probably have good insight. Nevertheless, I think it would be interesting for us to brainstorm on this.
Good question! I do wonder how much we've all disappeared off into our own Github silos, and discussion is now "library specific" held on each repro's account? I know that a lot of issues for Math/Multiprecision that would previously have been discussed around here, are now taking place on Github rather than here. We may well be missing something: to pick one example, anyone have any strong feelings on the use of Concepts within Boost libraries: https://github.com/boostorg/math/pull/848 ? I use this as a for-instance, not to hijack this topic BTW! John.
El 03/12/2022 a las 3:02, David Sankel via Boost escribió:
Hi all,
At C++Now this year I gave a talk on the status of Boost and presented this graph which illustrated the trend of Boost mailing list participation.
https://docs.google.com/presentation/d/1ocX8Dh4B98gxfXJTWOriaEU1tmJN61M4RfjU...
I'm interested to hear your opinions as to what happened over that time period to cause such a trend.
I've been wondering for a while if maybe people are moving to some other discussion forums such as Stack Overflow. Some queries for [c++]- and [boost]-tagged questions in SO yield these numbers: C++ Boost 2013 231284 7589 3.3% 2014 216447 7243 3.3% 2015 201461 6300 3,1% 2016 177118 5267 3.0% 2017 147769 4340 2.9% 2018 124093 3431 2.8% 2019 116588 2414 2.1% 2020 131680 2512 1.9% 2021 102111 2115 2.1% 2022 80383 1795 2.2% So, there's been a downward trend both for C++ and Boost, while the Boost/C++ ratio has sort of stabilized at 2.x%. Not that I know what to make of these figures. Joaquín M López Muñoz
I actually never participated that much, so this is just my outside view: - mailing lists are terrible technology in year 2022(actually in year 2012 they were already bad), beyond simple queries stuff is hard to follow, e.g. thread hijacking is easily solvable with "new" technologies(available for 15+ years) where you can move that part of conversation easily out from original discussion. mutability ftw ;) - C++ standardization has taken the wrong path of making happy trillion dollar corporations that do not want to spend millions to update their codebases while migrating to new versions of C++ and that is not really something that inspires people to do free work. - Rust - I know some people hate Rust and consider it a fad, but it is absolutely true in my experience that a lot of my coworkers are much more excited about Rust than C++ 23/26, although this is a mix of Rust fanboy stuff and disappointment in C++ standardization speed. - Titus is a merciful god but you have angered him by rejecting his ABI breakage proposal ;) Since Google gave up on C++ it is kind of hard to get excited about future of C++. One important thing about standardization: I think primary problem is lack of resources(e.g. Sankel talk about Rust/C++ mentions the speed of adoption of features, only in C++ land 3 year period is considered a small cleanup release), and I am grateful to everybody who donates their free time and expertise to standardization, but but but it is also true that standardization choose terrible path of stable ABI, co_ nonsense... C++ choose slow certain death over highly likely survival in case of going for breaking changes. And just to be clear: I am not talking about next 2-3 years, more about next decades so I am certain there is still a lot of value to provide for people who work on standardization and/or in Boost. P.S. Regarding resources: I know money is considered dirty in most open source communities(I never understood that), but if Boost would set up some way to support people doing work and resources were spend transparently I think that would be beneficial to the community and Boost itself. Again I might be too optimistic, mold linker author recently mentioned how he is unable to support mold development from donations, but you can count on mine 5$/month :) On Sat, Dec 3, 2022 at 3:03 AM David Sankel via Boost <boost@lists.boost.org> wrote:
Hi all,
At C++Now this year I gave a talk on the status of Boost and presented this graph which illustrated the trend of Boost mailing list participation.
https://docs.google.com/presentation/d/1ocX8Dh4B98gxfXJTWOriaEU1tmJN61M4RfjU...
I'm interested to hear your opinions as to what happened over that time period to cause such a trend. There's truth to the claim that this question is being asked of the wrong people; those who left, stopped participating, or would otherwise start probably have good insight. Nevertheless, I think it would be interesting for us to brainstorm on this.
Thanks in advance for your thoughts.
-- David
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, Dec 3, 2022 at 7:37 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:
P.S. Regarding resources: I know money is considered dirty in most open source communities(I never understood that),
I don't think that's the sentiment. The thought I hear more often is that it's almost impossible to earn a living with OSS development.
but if Boost would set up some way to support people doing work and resources were spend transparently I think that would be beneficial to the community and Boost itself.
That could, minimally, provide some funds for people. The logistics would be a bit complicated though.
Again I might be too optimistic, mold linker author recently mentioned how he is unable to support mold development from donations, but you can count on mine 5$/month :)
There are at least 103 BoostORG members. Probably a fair number are not active -- and at least one passed away :-( But to give you an idea of how direct financing does and does work.. The C++ Alliance employs/pays a handful (8) of Boost programmers. And the benefits are clear. As what they work on is getting improvements (hash containers, json, url). Others may try to get GitHub sponsorships to encourage their work. Here's a breakdown of the current sponsorship picture (this includes the C++ Alliance people also): BoostORG Members (103) Sponsors: ("None" stands for not accepting sponsors.) Andrzej Krzemieński (akrzemi1): None Alan de Freitas (alandefreitas): None Alain Miniussi (aminiussi): None Antony Polukhin (apolukhin): None Artyom Beilis (artyom-beilis): None Andrii Sydorchuk (asydorchuk): None Adam Wulkiewicz (awulkiew): None Barend Gehrels (barendgehrels): None Noel Belcourt (Belcourt): None Brandon Kohn (brandon-kohn): None brunolalande (brunolalande): None chhenning (chhenning): None chriskohlhoff (chriskohlhoff): None Christopher Kormanyos (ckormanyos): None Christian Mazakas (cmazakas): None Sebastian Redl (CornedBee): None Daryle Walker (CTMacUser): None Daniel Frey (d-frey): None Daniel James (danieljames): None Joel de Guzman (djowel): None Edward Diener (eldiener): None Eric Niebler (ericniebler): None Fernando Cacciola (fcacciola): None Alexander Grund (Flamefire): None John Fletcher (fletchjp): None Frank Mori Hess (fmhess): None Aaron Boman (frenchtoast747): None Glen Fernandes (glenfe): None René Ferdinand Rivera Morell (grafikrobot): 0 Dmitry (grisumbras): None Hans Dembinski (HDembinski): None headmyshoulder (headmyshoulder): None henry-ch (henry-ch): None Nathan Ridge (HighCommander4): None Hartmut Kaiser (hkaiser): None Ion Gaztañaga (igaztanaga): None Jeff Garland (JeffGarland): None Jeff Trull (jefftrull): None Jim King (jeking3): None Jeremy W. Murphy (jeremy-murphy): None Jesun Sahariar Firoz (jesunsahariar): None Joel Falcou (jfalcou): None Jürgen Hunold (jhunold): None joaquintides (joaquintides): None jofaber (jofaber): None jzmaddock (jzmaddock): None Agustín Bergé (K-ballo): None Kyle Lutz (kylelutz): None Andrey Semashev (Lastique): None Lorenzo Caminiti (lcaminiti): None Louis Dionne (ldionne): None Pranam Lashkari (lpranam): None Richard Hodges (madmongo1): None Marcin Zalewski (marcinz): None Mario Mulansky (mariomulansky): None Matthias Troyer (matthiastroyer): None Marshall Clow (mclow): None Prathamesh Tagore (meshtag): None MIRAL SHAH (miralshah365): None Michael Caisse (mjcaisse): None Menelaos Karavelas (mkaravel): None Marek Kurdej (mkurdej): None Mateusz Łoskot (mloskot): None morinmorin (morinmorin): None Nick (NAThompson): None Niall Douglas (ned14): 0 neilgroves (neilgroves): None Nikhar Agrawal (Nikhar): None Oliver Kowalke (olk): None Paul A. Bristow (pabristow): None Peter Zhang (paldar): None patak (patak-dev): 0 Peter Dimov (pdimov): None Daniel Pfeifer (purpleKarrot): None Raffi Enficiaud (raffienficiaud): None Robert Ramey (robertramey): None Gennadiy Rozental (rogeeff): None rsdale (rsdale): None Ronald Garcia (rxg): None Abel Sinkovics (sabel83): None Sam Darwin (sdarwin): None Samuel Debionne (sdebionne): None Krystian Stasiowski (sdkrystian): None sehe (sehe): None Olzhas Zhumabek (simmplecoder): None Thomas Heller (sithhell): None spreadsort (spreadsort): None Stefan Seefeld (stefanseefeld): None swatanabe (swatanabe): None Tim Blechmann (timblechmann): None Jonathan Turkanis (turkanis): None Zach Laine (tzlaine): None Jeroen Habraken (VeXocide): None Vicente J. Botet Escriba (viboes): None Vinnie Falco (vinniefalco): None Vissarion Fisikopoulos (vissarion): None Vladimir Prus (vprus): None Mike Wazowski (yet-another-user): None David Bellot (yimyom): None Emil Dotchevski (zajo): None Total members looking for sponsorship: 3 (out of 103 Total individuals sponsoring members: 0 -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
interested to hear your opinions as to> what happened over that time> period to cause such a trend. I believe that both Boost and C++ as wellas the general skill level in the communityall simply increased. C++ has become mainstream for thosewho want to use it. Also C++ (in its post C++11form) has gotten very good, as have compilers.The situation is much more comfortableand stable/reliable than in 98, even forembedded systems where great strigdestoward language adherence have been made.
Boost is mature.So the whole C++/Boost thingis just getting well-industrialized - as it should. C++ remains an excessively popularlanguage and Boost adds to its richness.But I think the traffic regarding openquestions and queries is simply reducedexactly by this established stability. Chris On Sunday, December 4, 2022 at 04:26:31 AM GMT+1, René Ferdinand Rivera Morell via Boost <boost@lists.boost.org> wrote: On Sat, Dec 3, 2022 at 7:37 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:
P.S. Regarding resources: I know money is considered dirty in most open source communities(I never understood that),
I don't think that's the sentiment. The thought I hear more often is that it's almost impossible to earn a living with OSS development.
but if Boost would set up some way to support people doing work and resources were spend transparently I think that would be beneficial to the community and Boost itself.
That could, minimally, provide some funds for people. The logistics would be a bit complicated though.
Again I might be too optimistic, mold linker author recently mentioned how he is unable to support mold development from donations, but you can count on mine 5$/month :)
There are at least 103 BoostORG members. Probably a fair number are not active -- and at least one passed away :-( But to give you an idea of how direct financing does and does work.. The C++ Alliance employs/pays a handful (8) of Boost programmers. And the benefits are clear. As what they work on is getting improvements (hash containers, json, url). Others may try to get GitHub sponsorships to encourage their work. Here's a breakdown of the current sponsorship picture (this includes the C++ Alliance people also): BoostORG Members (103) Sponsors: ("None" stands for not accepting sponsors.) Andrzej Krzemieński (akrzemi1): None Alan de Freitas (alandefreitas): None Alain Miniussi (aminiussi): None Antony Polukhin (apolukhin): None Artyom Beilis (artyom-beilis): None Andrii Sydorchuk (asydorchuk): None Adam Wulkiewicz (awulkiew): None Barend Gehrels (barendgehrels): None Noel Belcourt (Belcourt): None Brandon Kohn (brandon-kohn): None brunolalande (brunolalande): None chhenning (chhenning): None chriskohlhoff (chriskohlhoff): None Christopher Kormanyos (ckormanyos): None Christian Mazakas (cmazakas): None Sebastian Redl (CornedBee): None Daryle Walker (CTMacUser): None Daniel Frey (d-frey): None Daniel James (danieljames): None Joel de Guzman (djowel): None Edward Diener (eldiener): None Eric Niebler (ericniebler): None Fernando Cacciola (fcacciola): None Alexander Grund (Flamefire): None John Fletcher (fletchjp): None Frank Mori Hess (fmhess): None Aaron Boman (frenchtoast747): None Glen Fernandes (glenfe): None René Ferdinand Rivera Morell (grafikrobot): 0 Dmitry (grisumbras): None Hans Dembinski (HDembinski): None headmyshoulder (headmyshoulder): None henry-ch (henry-ch): None Nathan Ridge (HighCommander4): None Hartmut Kaiser (hkaiser): None Ion Gaztañaga (igaztanaga): None Jeff Garland (JeffGarland): None Jeff Trull (jefftrull): None Jim King (jeking3): None Jeremy W. Murphy (jeremy-murphy): None Jesun Sahariar Firoz (jesunsahariar): None Joel Falcou (jfalcou): None Jürgen Hunold (jhunold): None joaquintides (joaquintides): None jofaber (jofaber): None jzmaddock (jzmaddock): None Agustín Bergé (K-ballo): None Kyle Lutz (kylelutz): None Andrey Semashev (Lastique): None Lorenzo Caminiti (lcaminiti): None Louis Dionne (ldionne): None Pranam Lashkari (lpranam): None Richard Hodges (madmongo1): None Marcin Zalewski (marcinz): None Mario Mulansky (mariomulansky): None Matthias Troyer (matthiastroyer): None Marshall Clow (mclow): None Prathamesh Tagore (meshtag): None MIRAL SHAH (miralshah365): None Michael Caisse (mjcaisse): None Menelaos Karavelas (mkaravel): None Marek Kurdej (mkurdej): None Mateusz Łoskot (mloskot): None morinmorin (morinmorin): None Nick (NAThompson): None Niall Douglas (ned14): 0 neilgroves (neilgroves): None Nikhar Agrawal (Nikhar): None Oliver Kowalke (olk): None Paul A. Bristow (pabristow): None Peter Zhang (paldar): None patak (patak-dev): 0 Peter Dimov (pdimov): None Daniel Pfeifer (purpleKarrot): None Raffi Enficiaud (raffienficiaud): None Robert Ramey (robertramey): None Gennadiy Rozental (rogeeff): None rsdale (rsdale): None Ronald Garcia (rxg): None Abel Sinkovics (sabel83): None Sam Darwin (sdarwin): None Samuel Debionne (sdebionne): None Krystian Stasiowski (sdkrystian): None sehe (sehe): None Olzhas Zhumabek (simmplecoder): None Thomas Heller (sithhell): None spreadsort (spreadsort): None Stefan Seefeld (stefanseefeld): None swatanabe (swatanabe): None Tim Blechmann (timblechmann): None Jonathan Turkanis (turkanis): None Zach Laine (tzlaine): None Jeroen Habraken (VeXocide): None Vicente J. Botet Escriba (viboes): None Vinnie Falco (vinniefalco): None Vissarion Fisikopoulos (vissarion): None Vladimir Prus (vprus): None Mike Wazowski (yet-another-user): None David Bellot (yimyom): None Emil Dotchevski (zajo): None Total members looking for sponsorship: 3 (out of 103 Total individuals sponsoring members: 0 -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sun, Dec 4, 2022 at 1:14 AM Christopher Kormanyos via Boost < boost@lists.boost.org> wrote:
interested to hear your opinions as to> what happened over that time> period to cause such a trend. I believe that both Boost and C++ as wellas the general skill level in the communityall simply increased. C++ has become mainstream for thosewho want to use it. Also C++ (in its post C++11form) has gotten very good, as have compilers.The situation is much more comfortableand stable/reliable than in 98, even forembedded systems where great strigdestoward language adherence have been made.
Boost is mature.So the whole C++/Boost thingis just getting well-industrialized - as it should. C++ remains an excessively popularlanguage and Boost adds to its richness.But I think the traffic regarding openquestions and queries is simply reducedexactly by this established stability. Chris
I agree with this assessment. Boost was largely inspired by the lack of progress after C++98. But after all the new development since C++11 up to C++20, the language (together with the latest compilers) is much more modern, mature, stable and comfortable to use. Kudos to the people who have been involved in the standardization work over the past (more than) two decades.
On Sunday, December 4, 2022 at 04:26:31 AM GMT+1, René Ferdinand Rivera Morell via Boost <boost@lists.boost.org> wrote:
On Sat, Dec 3, 2022 at 7:37 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:
P.S. Regarding resources: I know money is considered dirty in most open source communities(I never understood that),
I don't think that's the sentiment. The thought I hear more often is that it's almost impossible to earn a living with OSS development.
but if Boost would set up some way to support people doing work and resources were spend transparently I think that would be beneficial to the community and Boost itself.
That could, minimally, provide some funds for people. The logistics would be a bit complicated though.
Again I might be too optimistic, mold linker author recently mentioned how he is unable to support mold development from donations, but you can count on mine 5$/month :)
There are at least 103 BoostORG members. Probably a fair number are not active -- and at least one passed away :-( But to give you an idea of how direct financing does and does work..
The C++ Alliance employs/pays a handful (8) of Boost programmers. And the benefits are clear. As what they work on is getting improvements (hash containers, json, url).
Others may try to get GitHub sponsorships to encourage their work. Here's a breakdown of the current sponsorship picture (this includes the C++ Alliance people also):
BoostORG Members (103) Sponsors: ("None" stands for not accepting sponsors.)
Andrzej Krzemieński (akrzemi1): None Alan de Freitas (alandefreitas): None Alain Miniussi (aminiussi): None Antony Polukhin (apolukhin): None Artyom Beilis (artyom-beilis): None Andrii Sydorchuk (asydorchuk): None Adam Wulkiewicz (awulkiew): None Barend Gehrels (barendgehrels): None Noel Belcourt (Belcourt): None Brandon Kohn (brandon-kohn): None brunolalande (brunolalande): None chhenning (chhenning): None chriskohlhoff (chriskohlhoff): None Christopher Kormanyos (ckormanyos): None Christian Mazakas (cmazakas): None Sebastian Redl (CornedBee): None Daryle Walker (CTMacUser): None Daniel Frey (d-frey): None Daniel James (danieljames): None Joel de Guzman (djowel): None Edward Diener (eldiener): None Eric Niebler (ericniebler): None Fernando Cacciola (fcacciola): None Alexander Grund (Flamefire): None John Fletcher (fletchjp): None Frank Mori Hess (fmhess): None Aaron Boman (frenchtoast747): None Glen Fernandes (glenfe): None René Ferdinand Rivera Morell (grafikrobot): 0 Dmitry (grisumbras): None Hans Dembinski (HDembinski): None headmyshoulder (headmyshoulder): None henry-ch (henry-ch): None Nathan Ridge (HighCommander4): None Hartmut Kaiser (hkaiser): None Ion Gaztañaga (igaztanaga): None Jeff Garland (JeffGarland): None Jeff Trull (jefftrull): None Jim King (jeking3): None Jeremy W. Murphy (jeremy-murphy): None Jesun Sahariar Firoz (jesunsahariar): None Joel Falcou (jfalcou): None Jürgen Hunold (jhunold): None joaquintides (joaquintides): None jofaber (jofaber): None jzmaddock (jzmaddock): None Agustín Bergé (K-ballo): None Kyle Lutz (kylelutz): None Andrey Semashev (Lastique): None Lorenzo Caminiti (lcaminiti): None Louis Dionne (ldionne): None Pranam Lashkari (lpranam): None Richard Hodges (madmongo1): None Marcin Zalewski (marcinz): None Mario Mulansky (mariomulansky): None Matthias Troyer (matthiastroyer): None Marshall Clow (mclow): None Prathamesh Tagore (meshtag): None MIRAL SHAH (miralshah365): None Michael Caisse (mjcaisse): None Menelaos Karavelas (mkaravel): None Marek Kurdej (mkurdej): None Mateusz Łoskot (mloskot): None morinmorin (morinmorin): None Nick (NAThompson): None Niall Douglas (ned14): 0 neilgroves (neilgroves): None Nikhar Agrawal (Nikhar): None Oliver Kowalke (olk): None Paul A. Bristow (pabristow): None Peter Zhang (paldar): None patak (patak-dev): 0 Peter Dimov (pdimov): None Daniel Pfeifer (purpleKarrot): None Raffi Enficiaud (raffienficiaud): None Robert Ramey (robertramey): None Gennadiy Rozental (rogeeff): None rsdale (rsdale): None Ronald Garcia (rxg): None Abel Sinkovics (sabel83): None Sam Darwin (sdarwin): None Samuel Debionne (sdebionne): None Krystian Stasiowski (sdkrystian): None sehe (sehe): None Olzhas Zhumabek (simmplecoder): None Thomas Heller (sithhell): None spreadsort (spreadsort): None Stefan Seefeld (stefanseefeld): None swatanabe (swatanabe): None Tim Blechmann (timblechmann): None Jonathan Turkanis (turkanis): None Zach Laine (tzlaine): None Jeroen Habraken (VeXocide): None Vicente J. Botet Escriba (viboes): None Vinnie Falco (vinniefalco): None Vissarion Fisikopoulos (vissarion): None Vladimir Prus (vprus): None Mike Wazowski (yet-another-user): None David Bellot (yimyom): None Emil Dotchevski (zajo): None
Total members looking for sponsorship: 3 (out of 103
Total individuals sponsoring members: 0
-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 04/12/2022 03:25, René Ferdinand Rivera Morell via Boost wrote:
Niall Douglas (ned14): 0
Total members looking for sponsorship: 3 (out of 103
Total individuals sponsoring members: 0
A perhaps useful data point is that people sponsor me for my minor contributions to Python, but they don't for my much larger (relatively speaking) contributions to C++. Different cultures. Back when I was working a contract writing in Rust people were a lot more generous with the money too. You couldn't live off it, but the cultural difference around money vs C++ was very obvious. Niall
On Sun, Dec 4, 2022 at 4:26 AM René Ferdinand Rivera Morell < grafikrobot@gmail.com> wrote:
On Sat, Dec 3, 2022 at 7:37 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:
Total members looking for sponsorship: 3 (out of 103
Excuse my ignorance(but again I might be a good representation of outside person that does not follow boost that closely). Is there some part of boost website where this individuals are listed and their projects and funding links are provided? regards, Ivan
On Wed, Dec 7, 2022 at 12:54 PM Ivan Matek <libbooze@gmail.com> wrote:
On Sun, Dec 4, 2022 at 4:26 AM René Ferdinand Rivera Morell <grafikrobot@gmail.com> wrote:
On Sat, Dec 3, 2022 at 7:37 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:
Total members looking for sponsorship: 3 (out of 103
Excuse my ignorance(but again I might be a good representation of outside person that does not follow boost that closely). Is there some part of boost website where this individuals are listed and their projects and funding links are provided?
Not that I know. Perhaps something to make sure exists in the redesigned website. And I generated that list by writing a Python program to talk to the GitHub API and then had to do some HTML web scraping (because GitHub doesn't have an API for sponsors). -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
On Sat, Dec 3, 2022 at 8:37 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:
P.S. Regarding resources: I know money is considered dirty in most open source communities(I never understood that), but if Boost would set up some way to support people doing work and resources were spend transparently I think that would be beneficial to the community and Boost itself. Again I might be too optimistic, mold linker author recently mentioned how he is unable to support mold development from donations, but you can count on mine 5$/month :)
The Boost Foundation <https://sites.google.com/a/boost.org/steering/> is a 100% volunteer-led 501(c)3 non-profit with transparency as part of its mission. You can see our meeting minutes right on the website. Donations, which are matched by many employers, help fund the mailing list, boost.org servers, and other Boost expenses. I think circulating an annual report would help socialize the good work the Boost Foundation does. We should do that. I know the board is more than happy to entertain proposals on how to use funding to forward the mission. Just recently we opened up the possibility for those in the Boost community to contribute directly to C++ standardization through its membership.
On 12/6/22 10:29 AM, Vinnie Falco via Boost wrote:
On Mon, Dec 5, 2022 at 2:26 PM David Sankel via Boost <boost@lists.boost.org> wrote:
You can see our meeting minutes right on the website.
Nothing good comes from publishing minutes.
Publishing minutes is essential. It's about time. Robert Ramey
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
sob., 3 gru 2022 o 03:03 David Sankel via Boost <boost@lists.boost.org> napisał(a):
Hi all,
At C++Now this year I gave a talk on the status of Boost and presented this graph which illustrated the trend of Boost mailing list participation.
https://docs.google.com/presentation/d/1ocX8Dh4B98gxfXJTWOriaEU1tmJN61M4RfjU...
I'm interested to hear your opinions as to what happened over that time period to cause such a trend. There's truth to the claim that this question is being asked of the wrong people; those who left, stopped participating, or would otherwise start probably have good insight. Nevertheless, I think it would be interesting for us to brainstorm on this.
Thanks in advance for your thoughts.
Let me share my experience. Recently I learned that there is a Boost Slack channel, where Boost developers converse, and where one can obtain help even faster than in this mailing list. This indeed turned out to be the case for me, so my attention shifted there, at least for small things. 10 years ago it was just the mailing list. Now my impression is that there is no one single point where Boost discussions take place. For bigger topics, where I need to write more than three paragraphs, I would still go with the mailing list, as the Slack interface is hardly suitable for tracking longer discussions. For another example, the design discussions regarding Boost.URL, I had them in Boost.URL GitHub, as this appeared a more natural place. Maybe we are decentralizing. Regards, &rzej;
-- David
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi all,
At C++Now this year I gave a talk on the status of Boost and presented
On 03/12/2022 02:02, David Sankel via Boost wrote: this
graph which illustrated the trend of Boost mailing list participation.
https://docs.google.com/presentation/d/1ocX8Dh4B98gxfXJTWOriaEU1tmJN61M4RfjU...
I'm interested to hear your opinions as to what happened over that time period to cause such a trend. There's truth to the claim that this
question
is being asked of the wrong people; those who left, stopped participating, or would otherwise start probably have good insight. Nevertheless, I think it would be interesting for us to brainstorm on this.
I presented a graph I think at C++ Now 2015 with the exact same trend. Apart from the year in which the design of Outcome was discussed here, mailing list volume continues its trend line downwards. I mention that Outcome review year, because it shows that if there is something interesting to discuss here, people do discuss it here and they come from elsewhere to here to read the discussion. People will link to discussion threads from social media, and from other languages. I remember links to Boost mailing list discussion points on Outcome being linked to from Rust, Python and other programming language communities, not just from within C++. Back in the day when I had time to donate, my solution to creating more interesting things to discuss here was to set up a pipeline of new young developers coming into Boost and sometimes C++ using Google Summer of Code. I think that was quite successful, we got a few new libraries out of it, and some new young developer talent into C++ as an ecosystem. I've always been of the belief that successfully ingressing new young developers is the best way to revitalising any mature ecosystem. Not necessarily because the old timers are out of ideas, but they are usually extremely time pressed in a way younger developers are not. Also, contributions of new big stuff to open source particularly benefits the career of a younger dev in a way it doesn't for an older dev - most of those Google Summer of Code young devs immediately stepped into a six figure income after I wrote them a glowing reference based on their participation in the Boost SoC, and that's huge for them in a way it can't be for older devs. So they've got a bigger incentive to invest their free time in a way few old timers can rationalise. It requires sustained effort to bring new devs into C++. It isn't exactly cool nor sexy like say Rust is, so they don't ingress on their own anything like as quickly as if they are proactively nurtured in. So if you want revitalisation, that needs constant daily work to nurture and bring forth new talent, and all the drudgery that entails. Niall
It requires sustained effort to bring new devs into C++.
My experience as a young (28) C++ developer who has recently become a Boost author: Developing in C++ is exciting, and more for Boost, which I've been using since college. The main pain is not the language itself but the tools and practices around it. These are the things I've found really problematic: 1. Dependency management. There is a place where I've had to list my indirect dependencies. Depinst takes a lot of time to run. Depending on OpenSSL is a pain. If we're to attract any young devs, we can't say "uf, a dependency, that's going to be a problem". 2. Bjam. I love B2, I think it's much better than CMake in a lot of things. But the language doesn't help. The same set of concepts, but exposed in a modern scripted language (say Python, Starlark, JS) would be great. 3. Build times. I have a TU taking ~30s to build. I think we should pay more attention to this. I can live with 2 and 3, but 1 is, for me, *the* reason why I wouldn't do C++. I hope my thoughts help anyhow. Regards, Ruben.
@Ruben: try conan : https://conan.io/ HTH David Le lun. 5 déc. 2022 à 03:14, Ruben Perez via Boost <boost@lists.boost.org> a écrit :
It requires sustained effort to bring new devs into C++.
My experience as a young (28) C++ developer who has recently become a Boost author:
Developing in C++ is exciting, and more for Boost, which I've been using since college. The main pain is not the language itself but the tools and practices around it. These are the things I've found really problematic:
1. Dependency management. There is a place where I've had to list my indirect dependencies. Depinst takes a lot of time to run. Depending on OpenSSL is a pain. If we're to attract any young devs, we can't say "uf, a dependency, that's going to be a problem". 2. Bjam. I love B2, I think it's much better than CMake in a lot of things. But the language doesn't help. The same set of concepts, but exposed in a modern scripted language (say Python, Starlark, JS) would be great. 3. Build times. I have a TU taking ~30s to build. I think we should pay more attention to this.
I can live with 2 and 3, but 1 is, for me, *the* reason why I wouldn't do C++.
I hope my thoughts help anyhow.
Regards, Ruben.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 5/12/2022 21:15, David Callu via Boost wrote:
@Ruben: try conan : https://conan.io/
The "there are now N+1 competing standards" comic springs to mind. There's conan, vcpkg, nuget, git submodule, various unix package managers, C++ modules, ...
Here's a chart of Boost library Github activity from 2013 through 2022 (created by querying api.github.com). Number of pull requests. Number of issues. Development activity has been mostly constant. https://docs.google.com/spreadsheets/d/1Ds-juqrToQR6fl5Ld7TkUYYOt7MO0hQwtaWp... On Mon, Dec 5, 2022 at 4:21 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 5/12/2022 21:15, David Callu via Boost wrote:
@Ruben: try conan : https://conan.io/
The "there are now N+1 competing standards" comic springs to mind.
There's conan, vcpkg, nuget, git submodule, various unix package managers, C++ modules, ...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Dec 5, 2022 at 3:41 PM Sam Darwin via Boost <boost@lists.boost.org> wrote:
Here's a chart of Boost library Github activity from 2013 through 2022 (created by querying api.github.com). Number of pull requests. Number of issues. Development activity has been mostly constant.
https://docs.google.com/spreadsheets/d/1Ds-juqrToQR6fl5Ld7TkUYYOt7MO0hQwtaWp...
Thank you Sam. I believe this confirms the theory that user support and design discussions have branched away from the mailing list and into GitHub issues and discussions. And the public activity on the Cpplang Slack (https://cpplang.slack.com/) sponsored by the C++ Alliance has been robust in terms of day to day technical discussion regarding Boost, networking, and the C++ standard. My "revitalization" theory of Boost is as follows: * User support has been migrating from the mailing list to GitHub issues * Technical discussion has been migrating to Slack and to some extent Discord; it is more lively and interactive. * Boost is not as popular now because the perception of "monolithism" and duplication of std features (i.e. a victim of our own success) There was a survey three years ago with excellent feedback which provides many answers to "why not Boost?" <https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/> Boost does need a refreshing of talent, however, as we face these problems: * Authors of open source libraries are less inclined to target a Boost review and more inclined to want to create a library that does not depend on Boost (for many of the reasons above, "Why you don't use Boost?") * Authors of library-only proposals for the standard have been incentivized by the political atmosphere of the WG21 bureaucracy to go "direct to standard." That is, to write papers with little to no supporting code, and no attempt to publish an actual library with the goal of attracting projects willing to use the library in real projects. * The rise in objections to using Boost is correlated with a decrease in qualified individuals willing to review proposed Boost libraries and act as review managers. To address these issues requires a multimodal approach, including but not limited to: 1. A modern website. The C++ Alliance is working on a new site for Boost which should help consolidate the social media features together, streamline the review process, and ease the release process, as well as provide easy to access information about the Boost libraries in a visual style that is appealing and promotes interest. We hope to provide a beta in Q1 of 2023. 2. A streamlining of Boost. We need ideas on how to address the issues raised by users. Just thinking out loud this could include breaking Boost up into several smaller libraries, e.g. "core" boost, "math" boost, "network" boost, "C++03 boost". Work on documentation that most people agree is poor or is a pain point for users. There has been a lot of discussion about this so I won't repeat it here. 3. Regularly posting social media content such as blog posts, video tutorials, example programs, or case studies of Boost in the workplace where the benefits of using Boost are clearly enumerated. To this end we have begun to tweet more regularly from the Boost Twitter account, which has gained 15% more followers in the last three months (see https://twitter.com/Boost_Libraries). Retweeting and following will of course help. Thanks
On Dec 5, 2022, at 4:21 PM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Mon, Dec 5, 2022 at 3:41 PM Sam Darwin via Boost <boost@lists.boost.org> wrote:
Here's a chart of Boost library Github activity from 2013 through 2022 (created by querying api.github.com). Number of pull requests. Number of issues. Development activity has been mostly constant.
https://docs.google.com/spreadsheets/d/1Ds-juqrToQR6fl5Ld7TkUYYOt7MO0hQwtaWp...
Thank you Sam. I believe this confirms the theory that user support and design discussions have branched away from the mailing list and into GitHub issues and discussions. And the public activity on the Cpplang Slack (https://cpplang.slack.com/) sponsored by the C++ Alliance has been robust in terms of day to day technical discussion regarding Boost, networking, and the C++ standard.
My "revitalization" theory of Boost is as follows:
* User support has been migrating from the mailing list to GitHub issues * Technical discussion has been migrating to Slack and to some extent Discord; it is more lively and interactive. * Boost is not as popular now because the perception of "monolithism" and duplication of std features (i.e. a victim of our own success)
There was a survey three years ago with excellent feedback which provides many answers to "why not Boost?"
<https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/>
2. A streamlining of Boost. We need ideas on how to address the issues raised by users. Just thinking out loud this could include breaking Boost up into several smaller libraries, e.g. "core" boost, "math" boost, "network" boost, "C++03 boost". Work on documentation that most people agree is poor or is a pain point for users. There has been a lot of discussion about this so I won't repeat it here.
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I concur with the streamlining of Boost to avoid the monolith. ~18 months ago Math offered its first standalone release which was made possible by jumping to C++11. Since we began offering this as an option MSVC has incorporated standalone Math into their implementation of the STL. We are also currently working with SciPy to use the standalone module. We can offer bug fix releases on our Github page outside of the standard Boost release cadence which assists their development cycle. Multiprecision also has a more recent standalone module that I know people are using because it was by request, and we get standalone specific bug reports. I am willing to assist other maintainers in offering a standalone module of their libraries. Matt
On Mon, Dec 5, 2022 at 6:36 PM Proton <matt@mattborland.com> wrote:
I am willing to assist other maintainers in offering a standalone module of their libraries.
Sloooooooooow down there cowboy :) I'm not suggesting to start turning out a series of Boost libraries converted to standalone. That's not going to be practical, because there are Boost facilities that are too darn good to do without: Boost.Align - everything Boost.Assert - BOOST_ASSERT, source_location, current_function Boost.Config - everything Boost.Container - memory_resource for C++11 Boost.Core - string_view, allocator_traits Boost.Describe - practical reflection Boost.Mp11 - everything Boost.System - error_code, result Boost.ThrowException - throw_exception (attached stacks) Boost.Variant2 - A never valueless variant (how it should have been) These libraries are important for me and I find myself using them in every single project I author. The features fall into several categories: * Utilities to help code work on all toolchains * C++11 implementations of C++17 or later features (string_view, variant2) * Better versions of things in C++ (throw_exception, error_code) * Features that would be a pessimization to have to reimplement (Mp11, Describe, et. al.) The original release of Boost.JSON had a "standalone" mode but I quickly ran into the problem where denying myself access to all of the useful libraries described above became unworkable. We might consider offering smaller a-la carte bundles of Boost libraries. For example, bundle the libraries above into a "Boost Essentials." Of course this might be a dumb idea and I will not be offended if anyone says so. Making Boost.JSON, Boost.URL, Boost.HTTP.Proto "mostly standalone" (i.e. depend only on a "Boost Essentials" type library) is much more realistic than having to make it totally standalone and reimplement everything over and over. There is also another problem which is that as I write higher level libraries, I depend on the lower level libraries. For example: Beast depends on Asio HTTP.Proto depends on URL HTTP.IO depends on HTTP.Proto and Asio A hypothetical "Boost.HTTP.Requests" library would depend on Asio, HTTP.Proto, HTTP.IO, and Boost.JSON. And so on. It is not sustainable to try to make every single library standalone. This subverts the benefits of separation of concerns and physical separation of libraries. Instead we should focus on how we can make it more palatable for users to add our libraries to their project, if not the singular monolithic Boost installation, then perhaps the smaller library aggregates I alluded to above. Thanks
On Dec 5, 2022, at 6:58 PM, Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Mon, Dec 5, 2022 at 6:36 PM Proton <matt@mattborland.com> wrote:
I am willing to assist other maintainers in offering a standalone module of their libraries.
Sloooooooooow down there cowboy :)
I'm not suggesting to start turning out a series of Boost libraries converted to standalone. That's not going to be practical, because there are Boost facilities that are too darn good to do without:
Boost.Align - everything Boost.Assert - BOOST_ASSERT, source_location, current_function Boost.Config - everything Boost.Container - memory_resource for C++11 Boost.Core - string_view, allocator_traits Boost.Describe - practical reflection Boost.Mp11 - everything Boost.System - error_code, result Boost.ThrowException - throw_exception (attached stacks) Boost.Variant2 - A never valueless variant (how it should have been)
These libraries are important for me and I find myself using them in every single project I author. The features fall into several categories:
* Utilities to help code work on all toolchains * C++11 implementations of C++17 or later features (string_view, variant2) * Better versions of things in C++ (throw_exception, error_code) * Features that would be a pessimization to have to reimplement (Mp11, Describe, et. al.)
The original release of Boost.JSON had a "standalone" mode but I quickly ran into the problem where denying myself access to all of the useful libraries described above became unworkable.
We might consider offering smaller a-la carte bundles of Boost libraries. For example, bundle the libraries above into a "Boost Essentials." Of course this might be a dumb idea and I will not be offended if anyone says so. Making Boost.JSON, Boost.URL, Boost.HTTP.Proto "mostly standalone" (i.e. depend only on a "Boost Essentials" type library) is much more realistic than having to make it totally standalone and reimplement everything over and over.
There is also another problem which is that as I write higher level libraries, I depend on the lower level libraries. For example:
Beast depends on Asio HTTP.Proto depends on URL HTTP.IO depends on HTTP.Proto and Asio
A hypothetical "Boost.HTTP.Requests" library would depend on Asio, HTTP.Proto, HTTP.IO, and Boost.JSON.
And so on. It is not sustainable to try to make every single library standalone. This subverts the benefits of separation of concerns and physical separation of libraries. Instead we should focus on how we can make it more palatable for users to add our libraries to their project, if not the singular monolithic Boost installation, then perhaps the smaller library aggregates I alluded to above.
Thanks
For higher level libraries bundling is certainly more practical. I think there are other libraries like Math that don’t require anything Boost for proper functionality. Most of Math’s Boost dependencies were features replaced in C++11 (e.g. array, atomic, type_traits, etc.). Either way, we are experiencing success moving away from the monolithic dependency, and I expect others would have a similar reception. Matt
Le 2022-12-06 12:34, Vinnie Falco via Boost a écrit :
On Mon, Dec 5, 2022 at 7:38 PM Proton <matt@mattborland.com> wrote:
I think there are other libraries like Math that don’t require anything Boost for proper functionality
Do you have any particular Boost libraries in mind?
Jumping into the discussion, but endian comes to mind. Currently it depends on type_traits, config, core and static_assert. All these dependencies are required for C++03 compilation, or to support outdated compilers. None of this should be necessary with a modern (ie, with proper C++11 support) toolchain. Independant modules also means that you can mix boost versions (of course, at your own risks). I'm glad i can just copy/paste MP11 headers to backport them and use them in a project which requires to stay with boost filesystem 1.61 for binary compatibility. Regards, Julien
Julien Blanc wrote:
Le 2022-12-06 12:34, Vinnie Falco via Boost a écrit :
On Mon, Dec 5, 2022 at 7:38 PM Proton <matt@mattborland.com> wrote:
I think there are other libraries like Math that don’t require anything Boost for proper functionality
Do you have any particular Boost libraries in mind?
Jumping into the discussion, but endian comes to mind. Currently it depends on type_traits, config, core and static_assert. All these dependencies are required for C++03 compilation, or to support outdated compilers. None of this should be necessary with a modern (ie, with proper C++11 support) toolchain.
I'll gladly drop these dependencies (well maybe not Config, I'll need to check) if Boost drops C++03 support. Until then, not.
On 7/12/2022 05:55, Peter Dimov wrote:
I'll gladly drop these dependencies (well maybe not Config, I'll need to check) if Boost drops C++03 support.
AFAIK, the consensus was already that maintainers can drop C++03 support whenever they like (preferably after consulting with downstream library maintainers, but that's non-binding). Anyone still stuck on an older compiler can remain stuck on an older Boost too.
Gavin Lambert wrote:
On 7/12/2022 05:55, Peter Dimov wrote:
I'll gladly drop these dependencies (well maybe not Config, I'll need to check) if Boost drops C++03 support.
AFAIK, the consensus was already that maintainers can drop C++03 support whenever they like (preferably after consulting with downstream library maintainers, but that's non-binding).
Sure, and that's when I will like to drop C++03 support. (Either that, or whenever everyone else drops C++03 support - whichever happens first.)
On Dec 6, 2022, at 3:34 AM, Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Mon, Dec 5, 2022 at 7:38 PM Proton <matt@mattborland.com> wrote:
I think there are other libraries like Math that don’t require anything Boost for proper functionality
Do you have any particular Boost libraries in mind?
Thanks
Like other have said endian and regex would be useful by themselves. Random and Odeint are straightforward to make standalone packages. I know there are some concerns about losing the functionality of config. The standalone package on GitHub for multiprecision actually bundles config so that we could still use it. Matt
Am 06.12.22 um 03:36 schrieb Proton via Boost:
I concur with the streamlining of Boost to avoid the monolith. ~18 months ago Math offered its first standalone release which was made possible by jumping to C++11. [...] I am willing to assist other maintainers in offering a standalone module of their libraries. When I took over maintaining Boost.Nowide (actually when I pushed for finally including it in Boost) there already was a standalone version. I wrote CD scripts (Github Actions) to create the standalone version from each commit pushed to the develop branch and the standalone version is tested together with the "Boost version".
At a first glance, the following libraries would have to justify
This was requested by users and I got reports it is (still) used. It also was greatly simplified by requiring C++11 as the minimum. However I agree that Boost.Config is an important foundation and the only thing I'm missing for the standalone version (I had to duplicate 2 macros from Boost.Config in the standalone) This serves as a datapoint that having a subset of libraries available makes sense. I actually like the CMake integration, i.e. the CMakeLists.txt many Boost libraries already have because CMake requires to specify the (direct) dependencies (even header-only ones) explicitly. This makes it much easier to see what is required. Although the transitive dependencies are still an issue (for users having only download a part of Boost) their continued existence as "core" Boost libraries:
Thread (superseded by std::thread)
Actually the std library support for std::thread on Windows at least is still lacking. IIRC it was the MinGW cross-compiler with which we (in another project) were unable to use std::thread for Windows and had to resort to Boost.Thread. So I'd argue this is a point for keeping it in "core" Boost. Alex
Actually the std library support for std::thread on Windows at least is still lacking. IIRC it was the MinGW cross-compiler with which we (in another project) were unable to use std::thread for Windows and had to resort to Boost.Thread. So I'd argue this is a point for keeping it in "core" Boost. That's a good point. I worked around this by using the pthreads variant of MinGW, which fixes the problem for me, but this may not be a viable
On 06.12.22 11:02, Alexander Grund via Boost wrote: option for everyone. -- Rainer Deyke (rainerd@eldwood.com)
On Tue, Dec 6, 2022 at 4:02 AM Alexander Grund via Boost <boost@lists.boost.org> wrote:
I actually like the CMake integration, i.e. the CMakeLists.txt many Boost libraries already have because CMake requires to specify the (direct) dependencies (even header-only ones) explicitly. This makes it much easier to see what is required. Although the transitive dependencies are still an issue (for users having only download a part of Boost)
If we abandoned the consolidated headers, and hence the monolithic structure, you would have to do the same (specifying direct dependencies) with B2, or any other build system. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
On 06.12.22 01:21, Vinnie Falco via Boost wrote:
2. A streamlining of Boost. We need ideas on how to address the issues raised by users. Just thinking out loud this could include breaking Boost up into several smaller libraries, e.g. "core" boost, "math" boost, "network" boost, "C++03 boost". Work on documentation that most people agree is poor or is a pain point for users. There has been a lot of discussion about this so I won't repeat it here.
I think a good first step would be to separate out "legacy" libraries - libraries that exist and will continue to be maintained for users of the library, but which are no longer recommended for new code targeting the latest C++ standard. At a first glance, the following libraries would have to justify their continued existence as "core" Boost libraries: Any (superseded by std::any) Array (superseded by std::array) Assign (superseded by std::initializer_list) Atomic (C++11 feature emulation library) Bind (superseded by lambda expressions) Chrono (superseded by std::chrono) Compatibility (only exists to support obsolete compilers) Concept Check (superseded by C++20 concepts) Coroutine (superseded by Coroutine 2) Coroutine 2 (superseded by C++20 coroutines) Enable If (superseded by std::enable_if) Filesystem (superseded by std::filesystem) Foreach (superseded by range-based for) Function (superseded by std::function) Function Types (superseded by Callable Traits) Iterator (superseded by Stl_interfaces) Lambda (superseded by lambda expressions and Lambda2) Move (superseded by std::move) MPL (superseded by Mp11) Optional (superseded by std::optional) Phoenix (superseded by lambda expressions) Range (superseded by std::ranges) Ratio (superseded by std::ratio) Result Of (superseded by decltype) Smart Ptr (largely superseded by std::shared_ptr and std::unique_ptr) Spirit Classic (superseded by Spirit) Static Assert (superseded by static_assert) String Ref (superseded by std::string_view) Thread (superseded by std::thread) Tuple (superseded by std::tuple) Type Traits (superseded by <type_traits>) Typeof (superseded by decltype) Variant (superseded by Variant2 and std::variant) If they offer significant advantages over their standard counterparts, let them state those advantages front and center in their documentation. If they don't, let them by removed from the main libraries page onto a separate "legacy libraries" page. -- Rainer Deyke (rainerd@eldwood.com)
Rainer Deyke wrote:
At a first glance, the following libraries would have to justify their continued existence as "core" Boost libraries:
Any (superseded by std::any) Array (superseded by std::array) Assign (superseded by std::initializer_list) Atomic (C++11 feature emulation library) Bind (superseded by lambda expressions) Chrono (superseded by std::chrono) ...
This gets us back to our never-ending discussion of Boost dropping C++03 support. I'm sure this time it will be more productive than our last three attempts. Incidentally, std::any is C++17, so classifying Any as "legacy" implies everyone uses C++17 or better. (You also have "superseded by C++20" further down the list, which is even less justifiable.)
On 06/12/2022 16:52, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
At a first glance, the following libraries would have to justify their continued existence as "core" Boost libraries:
Any (superseded by std::any) Array (superseded by std::array) Assign (superseded by std::initializer_list) Atomic (C++11 feature emulation library) Bind (superseded by lambda expressions) Chrono (superseded by std::chrono) ...
This gets us back to our never-ending discussion of Boost dropping C++03 support.
I'm sure this time it will be more productive than our last three attempts.
Perhaps the question should be this: are there libraries still using C++03 Boost versions of these libraries, that are still actually supporting C++03 themselves? Or are these dependencies just cruft left over from previous C++03 support which is no longer there in practice? Just wondering ;) John.
On Tue, Dec 6, 2022 at 9:52 AM John Maddock via Boost <boost@lists.boost.org> wrote:
Perhaps the question should be this: are there libraries still using C++03 Boost versions of these libraries, that are still actually supporting C++03 themselves? Or are these dependencies just cruft left over from previous C++03 support which is no longer there in practice?
Only Boost.Asio comes to mind, upon which my entire empire of libraries is built. Thanks
On 12/6/22 9:52 AM, John Maddock via Boost wrote:
On 06/12/2022 16:52, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
At a first glance, the following libraries would have to justify their continued existence as "core" Boost libraries:
Any (superseded by std::any) Array (superseded by std::array) Assign (superseded by std::initializer_list) Atomic (C++11 feature emulation library) Bind (superseded by lambda expressions) Chrono (superseded by std::chrono) ...
This gets us back to our never-ending discussion of Boost dropping C++03 support.
I'm sure this time it will be more productive than our last three attempts.
Perhaps the question should be this: are there libraries still using C++03 Boost versions of these libraries, that are still actually supporting C++03 themselves? Or are these dependencies just cruft left over from previous C++03 support which is no longer there in practice?
Just wondering ;)
John.
FYI - serialization uses C++03 libraries (e.g. MPL) and builds and passes tests on C++03. I don't know how many users might use that. My motivation for keeping this is: a) the library is for the most part correct. (though it took a while). b) so I disinclined to mess with it. c) it costs nothing to leave it as it is d) it maximizes the number of users/applications it might support. e) There would be no effective benefit to anyone to alter it to use more recent C++ features. So whatever boost "decides", I don't see any reason to change anything Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 06.12.22 17:52, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
At a first glance, the following libraries would have to justify their continued existence as "core" Boost libraries:
Any (superseded by std::any) Array (superseded by std::array) Assign (superseded by std::initializer_list) Atomic (C++11 feature emulation library) Bind (superseded by lambda expressions) Chrono (superseded by std::chrono) ...
This gets us back to our never-ending discussion of Boost dropping C++03 support.
I'm not advocating that any of these libraries are dropped, or even deprecated. I am just advocating that they are pushed into the background a bit. A more neutral approach would be to give each library a range of C++ standards for which the library is useful, and allow the user to filter by the C++ standard they are using. Picking C++11, for example, would filter out both Atomic (because it is superseded by the standard library) and Describe (because it requires C++14).
I'm sure this time it will be more productive than our last three attempts.
Incidentally, std::any is C++17, so classifying Any as "legacy" implies everyone uses C++17 or better. (You also have "superseded by C++20" further down the list, which is even less justifiable.)
It shouldn't be controversial to advocate that new application code should use the newest C++ standard where possible. And for where that's not possible, the legacy libraries will still be available. -- Rainer Deyke (rainerd@eldwood.com)
On Tue, Dec 6, 2022 at 10:36 AM Rainer Deyke via Boost <boost@lists.boost.org> wrote:
I'm not advocating that any of these libraries are dropped, or even deprecated. I am just advocating that they are pushed into the background a bit.
Right. And also note that what I was proposing is rolling up the most foundational Boost libraries and separating that into one composite library as an individual offering upon which other stand-alone libraries may depend. In other words to break up boost into a handful of medium sized collections instead of one large collection. Thanks
Rainer Deyke wrote:
A more neutral approach would be to give each library a range of C++ standards for which the library is useful, and allow the user to filter by the C++ standard they are using. Picking C++11, for example, would filter out both Atomic (because it is superseded by the standard library) and Describe (because it requires C++14).
That's not correct because parts of Atomic are only superseded by the C++20 standard library, not the C++11 one.
On 12/6/22 21:58, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
A more neutral approach would be to give each library a range of C++ standards for which the library is useful, and allow the user to filter by the C++ standard they are using. Picking C++11, for example, would filter out both Atomic (because it is superseded by the standard library) and Describe (because it requires C++14).
That's not correct because parts of Atomic are only superseded by the C++20 standard library, not the C++11 one.
And some features are not in any standard so far.
On 12/6/22 12:37 PM, Andrey Semashev via Boost wrote:
On 12/6/22 21:58, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
A more neutral approach would be to give each library a range of C++ standards for which the library is useful, and allow the user to filter by the C++ standard they are using. Picking C++11, for example, would filter out both Atomic (because it is superseded by the standard library) and Describe (because it requires C++14).
That's not correct because parts of Atomic are only superseded by the C++20 standard library, not the C++11 one.
And some features are not in any standard so far.
Wouldn't all this discussion be irrelevant if Boost was distributed only as source code and not pre-compiled libraries? Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Dec 6, 2022 at 2:45 PM Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 12/6/22 12:37 PM, Andrey Semashev via Boost wrote:
On 12/6/22 21:58, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
A more neutral approach would be to give each library a range of C++ standards for which the library is useful, and allow the user to filter by the C++ standard they are using. Picking C++11, for example, would filter out both Atomic (because it is superseded by the standard library) and Describe (because it requires C++14).
That's not correct because parts of Atomic are only superseded by the C++20 standard library, not the C++11 one.
And some features are not in any standard so far.
Wouldn't all this discussion be irrelevant if Boost was distributed only as source code and not pre-compiled libraries?
No. And no one, except you, has mentioned binaries. The entire discussion has only been about source. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
On 12/6/22 12:50 PM, René Ferdinand Rivera Morell via Boost wrote:
On Tue, Dec 6, 2022 at 2:45 PM Robert Ramey via Boost
Wouldn't all this discussion be irrelevant if Boost was distributed only as source code and not pre-compiled libraries?
No. And no one, except you, has mentioned binaries. The entire discussion has only been about source.
I have to confess I never understand when this question comes up. Why is this "dependency" an issue. If I'm were building an app which uses boost and I wanted to minimize the amount of code included I would: a) download boost. b) use include statements in my app to refer to top level headers used. c) use the boost tool (I forget the name) to scan my code and list the required source modules d) include those source files in my b2 or CMake file. What could be simpler than that? The only possible problem I can imagine is that some older library might not compile under a newer version of C++. But due to the backward compatibility guarantee, that almost never happens. Robert Ramey
On 7/12/2022 10:42, Robert Ramey wrote:
c) use the boost tool (I forget the name) to scan my code and list the required source modules d) include those source files in my b2 or CMake file.
These steps are atypical. Most users will run b2 to build binaries (static or dynamic) and then link with these, or will use the prebuilt bintray or whatever binaries, or the prebuilt Linux distro binaries. While it's possible to import individual .cpp files, that's never the encouraged method to depend on any C++ libraries, Boost or otherwise.
On 12/6/22 2:38 PM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
Wouldn't all this discussion be irrelevant if Boost was distributed only as source code and not pre-compiled libraries?
That's exactly how we're distributing it.
I'm aware of that. But it seems to me that many use the pre-built library versions distributed with linux os versions. I confess I have no data supporting this though. I can't understand why this is a problem if one is building his own binaries from source.
On 06.12.22 19:58, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
A more neutral approach would be to give each library a range of C++ standards for which the library is useful, and allow the user to filter by the C++ standard they are using. Picking C++11, for example, would filter out both Atomic (because it is superseded by the standard library) and Describe (because it requires C++14).
That's not correct because parts of Atomic are only superseded by the C++20 standard library, not the C++11 one.
OK. Then Atomic would not be filtered out, but (to pick another random example) Assign would. I was going by the one-line description of Atomic, which is "C++11-style atomic<>.". -- Rainer Deyke (rainerd@eldwood.com)
Am 06.12.22 um 09:48 schrieb Rainer Deyke via Boost:
At a first glance, the following libraries would have to justify their continued existence as "core" Boost libraries:
Coroutine 2 (superseded by C++20 coroutines)
Coroutines from boost.coroutine2 are stackful != 'stackless' Coroutines from C++20 Stackful coroutines can suspend their execution within a deep callstack of ordinary functions while this is not permitted with C++20 coroutines. A C++20 coroutine requires that all invoked functions return or marked as C++20 coroutines too.
On 08.12.22 17:48, Oliver Kowalke via Boost wrote:
Am 06.12.22 um 09:48 schrieb Rainer Deyke via Boost:
At a first glance, the following libraries would have to justify their continued existence as "core" Boost libraries:
Coroutine 2 (superseded by C++20 coroutines)
Coroutines from boost.coroutine2 are stackful != 'stackless' Coroutines from C++20
Stackful coroutines can suspend their execution within a deep callstack of ordinary functions while this is not permitted with C++20 coroutines. Good to know, that sounds like a valid justification!
-- Rainer Deyke (rainerd@eldwood.com)
Coroutine (superseded by Coroutine 2) - unfortunately boost.asio depends on boost.coroutine I asked last year to cut this dependency by introducing the new lib boost.spawn (depends only on boost.context) and to remove boost::asio::spawn(). Am 06.12.22 um 09:48 schrieb Rainer Deyke via Boost:
On 06.12.22 01:21, Vinnie Falco via Boost wrote:
2. A streamlining of Boost. We need ideas on how to address the issues raised by users. Just thinking out loud this could include breaking Boost up into several smaller libraries, e.g. "core" boost, "math" boost, "network" boost, "C++03 boost". Work on documentation that most people agree is poor or is a pain point for users. There has been a lot of discussion about this so I won't repeat it here.
I think a good first step would be to separate out "legacy" libraries - libraries that exist and will continue to be maintained for users of the library, but which are no longer recommended for new code targeting the latest C++ standard.
At a first glance, the following libraries would have to justify their continued existence as "core" Boost libraries:
Any (superseded by std::any) Array (superseded by std::array) Assign (superseded by std::initializer_list) Atomic (C++11 feature emulation library) Bind (superseded by lambda expressions) Chrono (superseded by std::chrono) Compatibility (only exists to support obsolete compilers) Concept Check (superseded by C++20 concepts) Coroutine (superseded by Coroutine 2) Coroutine 2 (superseded by C++20 coroutines) Enable If (superseded by std::enable_if) Filesystem (superseded by std::filesystem) Foreach (superseded by range-based for) Function (superseded by std::function) Function Types (superseded by Callable Traits) Iterator (superseded by Stl_interfaces) Lambda (superseded by lambda expressions and Lambda2) Move (superseded by std::move) MPL (superseded by Mp11) Optional (superseded by std::optional) Phoenix (superseded by lambda expressions) Range (superseded by std::ranges) Ratio (superseded by std::ratio) Result Of (superseded by decltype) Smart Ptr (largely superseded by std::shared_ptr and std::unique_ptr) Spirit Classic (superseded by Spirit) Static Assert (superseded by static_assert) String Ref (superseded by std::string_view) Thread (superseded by std::thread) Tuple (superseded by std::tuple) Type Traits (superseded by <type_traits>) Typeof (superseded by decltype) Variant (superseded by Variant2 and std::variant)
If they offer significant advantages over their standard counterparts, let them state those advantages front and center in their documentation. If they don't, let them by removed from the main libraries page onto a separate "legacy libraries" page.
On Thu, Dec 8, 2022 at 9:05 AM Oliver Kowalke via Boost <boost@lists.boost.org> wrote:
I asked last year to cut this dependency by introducing the new lib boost.spawn (depends only on boost.context) and to remove boost::asio::spawn().
I rather Asio just add the necessary assembly and minimum code necessary to implement the stackful coroutines it needs - this will make both Standalone Asio and Boost-flavored Asio work. Thanks
On Thu, Dec 8, 2022, at 8:43 PM, Vinnie Falco via Boost wrote:
I rather Asio just add the necessary assembly and minimum code necessary to implement the stackful coroutines it needs - this will make both Standalone Asio and Boost-flavored Asio work.
I think Chris implemented that a version or two back. Have I hallucinated it? Seth
Am 09.12.2022 um 01:02 schrieb Seth via Boost:
On Thu, Dec 8, 2022, at 8:43 PM, Vinnie Falco via Boost wrote:
I rather Asio just add the necessary assembly and minimum code necessary to implement the stackful coroutines it needs - this will make both Standalone Asio and Boost-flavored Asio work. I think Chris implemented that a version or two back. Have I hallucinated it? Unfortunately no - my replacement lib boost.spawn was rejected because Christopher promised to re-factor boost.asio in order to cut the dependency to boost.coroutine...
On Fri, Dec 9, 2022, at 2:47 PM, Oliver Kowalke via Boost wrote:
Am 09.12.2022 um 01:02 schrieb Seth via Boost:
On Thu, Dec 8, 2022, at 8:43 PM, Vinnie Falco via Boost wrote:
I rather Asio just add the necessary assembly and minimum code necessary to implement the stackful coroutines it needs - this will make both Standalone Asio and Boost-flavored Asio work. I think Chris implemented that a version or two back. Have I hallucinated it? Unfortunately no - my replacement lib boost.spawn was rejected because Christopher promised to re-factor boost.asio in order to cut the dependency to boost.coroutine...
Apparently I did hallucinate. I must have mistaken the work Klemens did for something that happened in Asio proper :(
Am 08.12.2022 um 20:43 schrieb Vinnie Falco:
On Thu, Dec 8, 2022 at 9:05 AM Oliver Kowalke via Boost <boost@lists.boost.org> wrote:
I asked last year to cut this dependency by introducing the new lib boost.spawn (depends only on boost.context) and to remove boost::asio::spawn(). I rather Asio just add the necessary assembly and minimum code necessary to implement the stackful coroutines it needs - this will make both Standalone Asio and Boost-flavored Asio work.
boost.spawn ist the minimum code == assembly (boost.context) and uses asio's completion handler framework. It is alsmost the same code as boost::asio::spawn() ... the difference 9st, that it doesn't use the deprecated boost.coroutine
Ruben Perez via Boost <boost@lists.boost.org> writes:
1. Dependency management. There is a place where I've had to list my indirect dependencies. Depinst takes a lot of time to run. Depending on OpenSSL is a pain. If we're to attract any young devs, we can't say "uf, a dependency, that's going to be a problem".
2. Bjam. I love B2, I think it's much better than CMake in a lot of things. But the language doesn't help. The same set of concepts, but exposed in a modern scripted language (say Python, Starlark, JS) would be great.
We (the build2 project) have been working on this problem for the past 8 years and the result is pretty usable, IMO. In particular, we have Boost packaged[1] and the result builds[2] all its dependencies, including OpenSSL and ICU, from source on all the major platforms/compilers using build2. The package manager provides all the necessary mechanisms, such as conditional dependencies, dependency configuration, etc.[3], to solve what is (IMO and as echoed by our users) the biggest barrier to Boost's adoption: it's insane library dependence. And by "insane" here I don't mean just "heavy" (which is definitely the case), but also literally, as in, some of the dependencies just do not make any sense. Like libboost-multi-index depending on libboost-regex and thus ICU. Besides the build system and package manager, the build2 project also provides the CI service that doesn't attempt to cobble together something usable from what's out there and get by with whatever free resources happened to be currently available from GitHub. The result is a reliable and stable service that covers[4] all the major platforms and compilers, including legacy ones. So I believe the technology is there. The question is whether there is an appetite for change. [1] https://cppget.org/?packages=libboost [2] https://cppget.org/?builds=libboost [3] https://build2.org/bpkg/doc/build2-package-manager-manual.xhtml#manifest-pac... [4] https://ci.cppget.org/?build-configs
On Tue, Dec 6, 2022, at 1:14 PM, Boris Kolpackov via Boost wrote:
Like libboost-multi-index depending on libboost-regex and thus ICU.
I was so baffled I had to check: https://pdimov.github.io/boostdep-report/boost-1.80.0/multi_index.html It's actually Boost Range, which is a completely sane dependency for Boost Multi Index. Regex could probably be an optional dependency for Boost Range (which only uses Regex inside the `tokenized` adaptor). Seth
Seth via Boost <boost@lists.boost.org> writes:
On Tue, Dec 6, 2022, at 1:14 PM, Boris Kolpackov via Boost wrote:
Like libboost-multi-index depending on libboost-regex and thus ICU.
I was so baffled I had to check: https://pdimov.github.io/boostdep-report/boost-1.80.0/multi_index.html
It's actually Boost Range, which is a completely sane dependency for Boost Multi Index. Regex could probably be an optional dependency for Boost Range (which only uses Regex inside the `tokenized` adaptor).
Yeah, here are all the direct dependents of libboost-regex (as of the 1.78.0 release): libboost-iostreams libboost-graph libboost-range libboost-spirit libboost-log libboost-algorithm libboost-asio Quite a few of these besides range rise an eyebrow (graph, algorithm, iostreams). In fact, when we package the next release of Boost, we are going to try to make these dependencies optional. But I think this highlights the bigger underlying problem: Boost is not using adequate tooling that would make dealing with this tractable. It's probably not that difficult to make most of the above dependencies optional. But that's not for free: now you have double the number of configurations to test (if your CI service has support for testing such custom build configurations, that is). Add a couple more such optional dependencies and you are looking at a couple of hundreds build configurations. At this point your pull-style CI service will likely start having scaling issues and you have to wait hours for your feature branch to be completely tested. Maybe what you have changed doesn't have anything to do with the optional dependencies, but there is probably no easy way to communicate this to the pull-style CI service.
Here is a data point: Boost.StaticAssert consists of a single header file with 179 lines of code... This could easily be merged into Config or some other essential library. Thanks
On 06/12/2022 16:44, Vinnie Falco via Boost wrote:
Here is a data point:
Boost.StaticAssert consists of a single header file with 179 lines of code...
This could easily be merged into Config or some other essential library.
Thanks
+1 I think it's a really useful utility with no enough complexity to be an independent module... Best, Ion
On 06/12/2022 15:20, Boris Kolpackov via Boost wrote:
Seth via Boost <boost@lists.boost.org> writes:
On Tue, Dec 6, 2022, at 1:14 PM, Boris Kolpackov via Boost wrote:
Like libboost-multi-index depending on libboost-regex and thus ICU. I was so baffled I had to check: https://pdimov.github.io/boostdep-report/boost-1.80.0/multi_index.html
It's actually Boost Range, which is a completely sane dependency for Boost Multi Index. Regex could probably be an optional dependency for Boost Range (which only uses Regex inside the `tokenized` adaptor). Yeah, here are all the direct dependents of libboost-regex (as of the 1.78.0 release):
Just a heads up that Boost.Regex is now header only, and the library is retained for certain legacy uses only, so while there may be some dependency to the headers (and I'm surprised by even that!), there should be no dependency at all to the binaries. John.
On Sat, 3 Dec 2022 at 02:03, David Sankel via Boost <boost@lists.boost.org> wrote:
I'm interested to hear your opinions as to what happened over that time
Some thoughts from no one special, just a jobbing craftsman scraping a living... I've used Boost for quite a while, I think 1.28.0 was my first download. At that time the Standard Library was a bit sparse, so Boost was the only way to gain certain features and facilities, if you didn't want to roll your own. In my mind it was a thing of awesome wonder, even more so when I read Karlsson's book and understood a little of how it was done behind the curtain. Kinda taught me C++ craftsmanship. Dimov's Bind library just blew me away! Then the language and standard library started evolving. Many of the Boost base libraries became (almost) part of the standard library, it became harder to justify using Boost at work. At the same time the management of using Boost in work projects became a bit more challenging. Do you always build with the latest stable, or nail down a version and not automatically receive latest goodies? For a while Boost was not as stable as one would have liked, and not as well tested or supported, and that tarnished the brand. Since then the marginalisation of Boost has continued. Less and less of Boost is in the 'must have' category as the language and standard library mature. I wonder if Boost has had its day and served its purpose in its current form. Kinda sad though, as libraries like Proto still offer wondrous goodies, but they're just too niche. For comparison, libraries like Adobe's ATL do a few fancy things I'd love to see in Boost.
participants (26)
-
Alexander Grund -
Andrey Semashev -
Andrzej Krzemienski -
Boris Kolpackov -
Christopher Kormanyos -
David Callu -
David Sankel -
Gavin Lambert -
Gregory Dai -
Ion Gaztañaga -
Ivan Matek -
Joaquin M López Muñoz -
John Maddock -
Julien Blanc -
Niall Douglas -
Oliver Kowalke -
Peter Dimov -
Proton -
Rainer Deyke -
René Ferdinand Rivera Morell -
Robert Jones -
Robert Ramey -
Ruben Perez -
Sam Darwin -
Seth -
Vinnie Falco