Right now the title reads essentially: "Here's a library".
Right now the title reads essentially: "Here's a library".
It takes about a minute to find any information at all about this library besides the fact that it's used at Facebook (by the way, did you miss that? it's used at Facebook! Facebook!!). And even that information is empty bromides about how it's "designed with practicality and efficiency in mind". Hmm, I prefer my software to be impractical and inefficient...
All I take away from this is that Facebook has an irrationally optimistic expectation of how the world views its engineering prowess.
Right in the intro section, second paragraph, it says "It complements (as opposed to competing against) offerings such as Boost and of course std". Come on, what more do people want?
Professionals often don't have that choice. Cue many thousands of comments on HN why working in c++ sucks.
Looking to implement a memory efficient search engine.
That said, this is an issue for other languages as well. Another example: the "Google core libraries for Java": https://github.com/google/guava
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.
(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.
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
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).
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
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?
std::variant does not do this.
C++ is a massive beast but it works.
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?
Uh .. Yes? Yes, very much so.
the opposite from practical is general. for example is std not practical but general. Its api is not optimized for 95% of the use cases but rather so that everything is possible and equaly verbose.
the opposite of efficient can for example be trade of for readability, portability and cost (as in development time).
For me as a possible user of the lib i found this information critical. I write always similar info in the readme for my libraries.
No, it's certainly not at all. Those are completely unrelated spectrums. Something can easily be practical and general, or impractical and specific.
> the opposite of efficient can for example be trade off for [...]
And if they stated what trade-offs they made, then that paragraph would actually start to say something useful. Unfortunately, they don't.
Also, if you're developing documentation for libraries, I really would recommend finding a better source of inspiration. Take Redis, in the very first paragraph:
> What this means is that Redis provides access to mutable data structures via a set of commands, which are sent using a server-client model with TCP sockets and a simple protocol. So different processes can query and modify the same data structures in a shared way.
That's all you need to do: before anything else, tell the user what the thing does. Then you can give some basic details about implementation: "written in Go", "runs on Linux & macOS", "uses GC, so not suitable for RT applications", etc. After that you can get into trade-offs, real narrow implementation details, setup, handwaving abstract adjectives, etc. But lead with what the hell it actually does.
Let me guess: English is not your native language, right?
This has library contents: it’s a mix of various utilities - type conversion, data structures, memory management, random numbers, concurrency, etc.
https://github.com/facebook/folly/blob/main/folly/docs/Overv...