[saucetenuto]

Lambdas in C++ are pretty new. Most of us who used std::algorithm had to write our own functor structs and do the variable capture by hand. Except that typically we didn't, because at that point a for loop is more readable. I think that's the essential objection to the STL: it's a library built around functional programming and not OO, in a language built around OO and not functional programming.

And of course there are a bunch of small dumb things in it. Why do we have make_heap() and friends instead of a heap type? Why does binary_search() return a bool instead of an iterator? Why didn't we get any hash tables until like 2010? Who thought the vector<bool> specialization was a good idea, and why didn't they benchmark it first?

The STL is a weird mix of brilliant, visionary API design and abject failure. Because of C++'s many limitations, the fail-y parts are the parts that most people are most familiar with. C++11 has done an incredible amount to turn that around, but at this point, for me, it's too late: I'd rather have a new language and new library, informed by C++'s successes without being bound to its mistakes.

[cageface]

The STL is a weird mix of brilliant, visionary API design and abject failure.

Sounds like most software projects. IIRC the Scala folks have pretty much rewritten their entire collections library twice already, and that's with the benefit of hindsight.

I'd like to see a mature new language in this space with a good ecosystem too but the number of major swerves they've taken in the Rust design already makes me inclined to think that, like C++, they're going to discover they made some serious mistakes along the way.

[saucetenuto]

I see what you mean but I do think the STL was more visionary, and more abject, than almost anything else in its reference class. Truly unified sequence operations, for example, were novel back then. On the other hand, binary search _wasn't_; I'd love to know what that guy thought he was doing.