Just as we were talking about these issues Arthur O’Dwyer posted this:
https://quuxplusone.github.io/blog/2019/10/09/why-no-networking
mostly quoting Billy O’Neal .. and WRT to the subject these stand out:

"The result is that I can’t reasonably recommend anyone use std::regex,
because the 3 major standard library implementations of that are atrocious
(as in 2300% to 83000% slower than a quality implementation for some
inputs)". @ "oh that's 'just' a matter of QoI"

"This means the traditional response “don’t like std::vector? write your
own” is effectively unavailable here, and anyone who has a large body of
code that doesn’t map into whatever ends up in std:: needs to rewrite all
of their code if the std:: model gains wide adoption." @ "don't mention
policies or dare mention the foundational 'don't pay rule' and lose your
efficiency OCD - the committee just really likes vocabulary types and
secretly likes the .NET runtime" ;D

...so I guess/hope that a momentum is building for a 'paradigm shift' - the
realization that the old argument of "parameterization discourages use" is
in fact what _actually_ discourages use (of C++) - not least because that
is actually the selling point of 'managed' and 'scripty' languages - 'it
just works' _and_ you don't care about the inefficiencies and limitations
of that which 'just works' - IOW those who do not care about the overheads
of shared_ptr, std::function, std::thread, futures, streams etc will be
happy to 'just use' JavaScript and not bother with C++ while at the same
time the mentioned overheads will just feed and give credibility to more
anti-cpp rants (Linus Torvalds anyone? ;D)
(end of my rant - until I find the time for a proper SG14 manifesto -
C++-in-the-kernel-now! ;D)

-- 
Domagoj Šarić
Tech lead
C++ engineer
Microblink LTD
www.microblink.com <https://microblink.com/>
<https://microblink.com/>