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.

> 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

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).

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.