so do you also not use std::unordered_map, std::shared_ptr, std::thread, std::regex, or std::mutex ? because they all come from boost.

I used boost extensively in the past (2006-2011). But I have been disillusioned by all the accidental complexity. It's easy to use the complicated parts of boost, but you lose sight of the inefficiencies you introduce all over the place, be it code bloat, unnecessary indirections, splitting up of allocations, or merely bloating your build times.

Besides, std::unordered_map is flawed, the bucket interface forces suboptimal cache behavior. std::thread is such a thin abstraction, if you use C++ you might as well use it but it doesn't buy you much. same with std::mutex. std::regex on the other hand I avoid because it's easy to write "regular" expressions that cause backtracking with it. I would look at something like re2 instead, if I had to deal with text parsing a lot. or a proper LALR parser generator if the language is not regular.

Once they're safely out of Boost and implemented by the stdlib they're an order of magnitude more convenient to use. You can also be more confident in their future stability.

> Once they're safely out of Boost and implemented by the stdlib they're an order of magnitude more convenient to use.

I don't understand this. Most of the time the API doesn't even change; you can just do `namespace lib = std` or `namespace lib = boost` according to which one you want to use. In my own code for instance I have a header where I choose the std::, std::experimental or boost:: version of `optional`, `string_view`, and `any` according to the recentness of the stdlib I'm using; nothing else is needed.