[drewda]

Instead of pointing a finger at Facebook, I'd scoff at C++ and the way in which the language has grown where orgs build up their own utility libraries rather than depend on a standard library.

That said, this is an issue for other languages as well. Another example: the "Google core libraries for Java": https://github.com/google/guava

[jcelerier]

But why is that an issue at all ? Having boost and other utilities is great. And since it's all templates there's in practice in your binary no added cost if you're using folly::foo or std::foo or boost::foo, you can pick and choose the exact data structures that allow exactly what you want (or write your own if you think that you can do a few percent better than folly of abseil in your specific use case).

If I was using java or python I'd definitely not use the standard things most of the time either because it's more than likely that there's a more efficient way in some other library, and because my main paycheck comes from "can you make this as fast as technically possible given this average consumer hardware"-problems

[PaulDavisThe1st]

interesting case in point. i just learned today that std::variant and boost::variant differ in their:

   1. exception-safety guarantees
   2. real-time safety

2 is caused by 1, because to be exception safe requires a heap allocation, and that's not RT-safe.

Who would want to work in a language where you could not make these choices?

[jcelerier]

Boost even has variant2 which comes with another set of design tradeoffs

[hn_go_brrrrr]

When does std::variant allocate?

[PaulDavisThe1st]

boost::variant will allocate to save state during construction of a new value type, in order to be able to roll back if the constructor throws an exception.

std::variant does not do this.

[gumby]

Is std::variant forbidden from doing this per standard or is it simply one (or several) implementations that made this choice?

[fivea]

> I'd scoff at C++ and the way in which the language has grown where orgs build up their own utility libraries rather than depend on a standard library.

This comment makes no sense at all. I mean, would it make any sense to also criticize JavaScript/NodeJS for their relatively spartan standard modules and extensive use of vended modules from the likes of npm?

And have we learned nothing from the mistake of going with the "everything and the kitchen sink" that is java which failed to actually satisfy basic needs and resulted in projects like guava and apache commons and vavr stepping in to provide alternatives? And how about C's infamous standard library with it's security vulnerability-inducing standard functions which remain in the standard?

Perhaps we should learn lessons and avoid basic mistakes such as setting libraries in stone. C++ learned that lesson, and so did C#/.NET, and up to a point Rust. Why unlearn them?

[CRConrad]

> would it make any sense to also criticize JavaScript/NodeJS for their relatively spartan standard modules and extensive use of vended modules from the likes of npm?

Uh .. Yes? Yes, very much so.

[PaulDavisThe1st]

Instead of pointing the finger at C++, I'd scoff at any language that promotes the belief that a standard library could possibly meet all the needs of a project.

[simplestats]

You mean because it has gotten so unreadable and vast?

I've never worked with a place using C++ that didn't make their own core libraries. As a low-level language, there's almost always a way to get some performance benefit by starting from scratch for your specific case.

[ryandrake]

I've also never worked in a C++ place that didn't make their own core libraries, but when you ask, their rationale for building and maintaining their own libraries (as opposed to using the Standard Library) is often very weak. It's usually based on very outdated assumptions and Cargo Cutting, such as "the STL[1] is slow (but we haven't profiled ours to prove it's faster)." Or "We need our own string type because decades ago, there was something that std::string didn't do." Or "Our founding developer didn't like templates, so he build this vast copy of the standard library but using explicit data types."

(yes I've heard all of these "reasons")

1: Just calling it "the STL" is a key sign of living in the past--pretty much nobody uses the actual STL anymore: What we use is called the C++ Standard Library.

[MauranKilom]

> pretty much nobody uses the actual STL anymore: What we use is called the C++ Standard Library.

I won't deny your prior, but my prior is that people who complain about the use of the word "STL" to mean "C++ Standard Library" (and ignore that the latter is 10 times as many keystrokes) do so only to flaunt their knowledge, not because anyone actually experiences confusion nowadays.

Supporting evidence: https://github.com/microsoft/STL

[tialaramex]

To me, the STL is specifically Stepanov's idea for how to do generic programming in C++ in the early 1990s, and so it makes sense to distinguish the STL from unrelated stuff that happens to be in the C++ Standard Library.

For example iostream isn't part of Stepanov's idea, Stroustrup created that bundle of craziness in the 1980s and today it's part of the Standard Library, but it was not part of STL which only came into existence in the 1990s (although Stepanov's ideas about generic programming are older).

[antiterra]

Often these libraries exist as glue to an existing ecosystem. To that end, I have also seen portability libraries that provide a single interface to multiple implementations of system functions or datatypes on different operating systems.

[Mikeb85]

Why? Having millions of libraries is a good dilemma to have, even if it means a bunch don't work well together so you make your own anyway. Better than having no choice.

C++ is a massive beast but it works.