[Chaosvex]

That article probably isn't the best source to cite. You can look at the discussions on it elsewhere, although I'd just dismiss it as slop.

The standard library is mostly fine to use unless you have specific needs.

The bit about libraries is nonsense, sorry.

[flohofwoe]

The article might be slop, but the problems described in it are definitely real ;)

[Chaosvex]

Grossly exaggerated or misunderstood in many cases. Some of their arguments are just flat-out wrong.

I mean, why are they blaming the standard library for inherent properties of linked lists? Yeah, you don't want to use them without good reason. That's just called picking the right data structure for the job, not a flaw with the standard library.

Some of the other choices were tradeoffs between performance and usability. The standard maps have stable iterators, whereas third-party implementations almost never do because you can write faster implementations if you're willing to live without those guarantees. Was it the right choice in hindsight? Maybe, maybe not.

I'd personally like to see a namespaced versioned standard library but like that's ever going to happen

[flohofwoe]

As I understood the article, the main critique is that the stdlib has no concept of deprecation and breaking backward compatibility. E.g. the C++ committee is quick to add badly designed features to the stdlib but then can't roll them back when people actually realize that those new features are useless for most real-world code.

[domenicd]

I'm not sure this is a winnable game for programming languages.

- Keep a small stdlib, like JavaScript (especially earlier JavaScript): everyone complains about missing features, warring communities form around jQuery promises vs. Promises/A+ vs. callbacks, supply chain attacks, left-pad/is-even dependencies, etc.

- Grow a big stdlib while keeping backward compatibility, like C++: lots of cruft left around that must never be used, sitting next to newer stuff with similar names. People complain about the bloat.

- Grow a big stdlib and then break backward compatibility, like Python 2 -> 3: everyone is sad, the ecosystem churns for years.

I admit there are probably better and worse versions of each strategy, e.g., it seems to me like JavaScript's slow-but-steady accretion of primitives over time has gone OK, and it seems like apart from Python 2 -> 3 some of the PEPs I see for deprecations and replacements are reasonable. But no language has ever hit on a strategy that everyone loves, as far as I can tell.

[Chaosvex]

Yet they spend a lot of time complaining about features that were deprecated or removed.

[zabzonk]

Badly designed things get replaced. For example unique_ptr replaced auto_ptr. I'm not sure if the language standard actually supports the term "deprecation" though.

Edit: Also not sure what can possibly be downvoted here.

[bregma]

ISO/IEC 14882 contains many uses of the word "deprecation", including all the sections of Appendix D that explicitly lists all of the deprecated and removed features of the language and library.

[johannes1234321]

auto_ptr is an exception. Not the rule.

Regular expressions in C++ are an example "everybody" advises against using, but it's still there. vector<bool> will stay forever and so on.