Wouldn't it be better to have in the title _what_ the library is supposed to achieve, as opposed to who published it?
Right now the title reads essentially: "Here's a library".
I like a lot of things in Folly, but as others have mentioned: you have to pull in quite a lot, even if you care about only a tiny part. It's not very modular in that way.
However, I did have decent success taking the classes I was interested in (CPUThreadPoolExecutor, and surrounding), stripping the library down to just those bits, and using them. Obviously a PITA to stay current with upstream, though.
If nothing else, it's worth reading for some of the highly-optimized stuff going on in there.
See previous discussions dating all the way back to 2012:
Such a massive lib. Interesting, if not too extensive read.
I understand the FB rationale to have it, but what whould be a reason for other projects to adopt this lib?
I won't imagine maintaining such a lib as a dependency by ourselves. Maybe for one short-term purpose, but then it's still safer to go with standard or boost, or, God forbid, carve out some pieces and wrap them up.
Would someone point me to a C implementaion of folly/FBString ? Or any C String OSS lib that is similar to what C++ std::string(/wiew) does ?
More precisely, one that defines a datatype (no SDS-like trick) and has all goodies like SSO, CoW, views, thread-safety, etc..
I'm making such a lib but can't seem to find other examples to compare.
folly [https://www.wordnik.com/words/folly]
fŏl′ē
noun
Lack of good sense, understanding, or foresight.
An act or instance of foolishness.
A costly undertaking having an absurd or ruinous outcome.
At the risk of starting a meta conversation (pun intended) I wonder why the team chose this name for a set of core library components. The GitHub page indicates it is a loose play on an acronym. “acronymed loosely after Facebook Open Source Library”
Yet why accept a name with a negative connotation.. The name leads the product, so why not at least make it _neutral_?If you start a green field C++ project, would you choose Folly, Boost only, or Abseil?
I've been very interested in native C++ development for web-services and other applications. However the development experience always seems like an after thought. I really don't want to role my own package manager or build process - why isn't there a pip/cargo/mvn etc. for C++ devs?
When I write a README for a library I always try to include 1-2 code samples of the highlights of said library. So the reader sees quickly what to expect.
Their Synchronized<> is a thing we also came up with to use in our code. It's so helpful it should be part of the Standard Library.
The thing with folly is: boost.
Not the OP, but active user and contributor to folly, so I can add some context.
folly is a community effort within Meta; it doesn't have a specific theme about what's included in it, but it is a set of core libraries that are likely to be depended on by most C++ software within the company, and are enough high-quality and self-contained that they can be useful externally, or showcase implementations undergoing standardization efforts (for example experimental/coro for coroutines).
Main focus is server applications, but it is also used in mobile, in particular Thrift (the serialization/RPC infrastructure) depends on it.
A very personal list of favorites:
- experimental/coro is the coroutines infrastructure, which is now widely adopted.
- SharedMutex is a heavily optimized mutex which supports shared/upgrade/exclusive semantics, and allows near-linear scalability in shared mode. It is used pretty much everywhere as it is the default mutex for Synchronized, a wrapper to safely synchronize access to objects. Its footprint is just 4 bytes.
- DistributedMutex, OTOH, is an exclusive-only mutex that supports flat combining, and performs extremely well under high contention.
- MPMCQueue and UnboundedQueue are lock-free MPMC queues, respectively bounded and unbounded, which are used in almost all our thread pools (see the executor/ directory)
- Userland implementations of RCU and hazard pointers, for deferred reclamation.
- LifoSem and Baton are other fundamental synchronization primitives that are not available in most core C++ libraries. They do a magic trick internally, where if they're waiting long enough, they unmap the unused suffix of the stack, so idle threads don't hold unused stack memory.
- Function is like std::function, but move-only, so it can hold non-copyable function objects (think lambda that captures unique_ptr). It is the vocabulary type for callbacks used in futures and executors.
- F14 is a SIMD-optimized hash table. Similar to Abseil's SwissTable, it was published around the same time.
- TDigest is a highly scalable quantile estimator, widely used for service counters (see fb303, also open source).
- (shameless plug, as I wrote this one) enumerate() is a replica of the Python function, so you can do
for (auto&& [i, element] : folly::enumerate(collection)) { ... }