Folly: Meta's C++20 Component Library and the Cost of Depending on It

The gap Folly fills between std and Boost

The README says Folly "builds on `std` and fills its gaps." The stated rule is narrow: a component is added when std does not provide it or does not meet the performance, scalability or interface Meta's code needs, and when std provides an equivalent, folly and its users move to the standard one. That is a different posture from a general utility library. It means the contents are shaped by Meta's production workloads rather than by a desire for coverage. The README points at PackedSyncPtr.h and SmallLocks.h as examples where "performance concerns permeate much of Folly, sometimes leading to designs that are more idiosyncratic than they would otherwise be." Those two headers are the honest signal: this is a library where a pointer is packed with a synchronization word, and where a lock is small enough that the size itself is the design constraint. If your project does not have that constraint, the idiosyncrasy is cost without benefit.

Who this library is actually for

Folly is for engineers writing C++20 who need a specific primitive that the standard library does not ship, and who can accept a source-level dependency rather than a stable binary one. The README says Folly is "often a dependency of Meta's other open source C++ efforts and place where those projects can share code." That sentence is the clearest statement of the intended audience: if you are building on Meta's other open source C++ projects, Folly is likely already in your dependency graph and adopting it directly changes nothing about your build's shape. If you are not, you are taking on a dependency whose upgrade story is defined by the absence of guarantees. The namespace convention reinforces the boundary. All symbols live in namespace folly, with internal namespaces such as internal and detail, and the README says user code should not depend on symbols in those namespaces. That is a normal arrangement, but it also means the surface you may rely on is the one the project chooses to keep public, and it can shrink.

Flat layout, stuttering include paths, and the experimental trap

The physical design is deliberately plain. The sources live in the folly/ directory, so headers are included with the library name as a prefix, as in #include <folly/FBString.h>. The directory structure is flat, mirroring the namespace structure, and the README notes it is possible this will change in future versions. Two subdirectories matter for anyone deciding what to depend on. folly/experimental contains files used inside Folly and possibly at Meta but not considered stable enough for client use, and the README is direct: "Your code should not use files in folly/experimental lest it may break when you update Folly." folly/test holds unittests named ComponentXyzTest.cpp for each ComponentXyz.*, and folly/docs holds documentation. The practical consequence is that the header path itself tells you your risk level, and there is no packaging mechanism that enforces the distinction for you.

Building it with getdeps.py, and why the install location matters

The README's primary build path is CMake: after cloning the repository, run `cmake -B _build` and `cmake --build _build`. The CMake build fetches any required dependency it cannot find installed, and anything already on the system is used as-is. Alternatively, you can install the system packages first with `sudo build/fbcode_builder/getdeps.py install-system-deps --recursive`. Tests are not part of the `all` target; configure with `-DBUILD_TESTS=ON` to build them, which also fetches googletest and gflags if they are not installed. Because folly provides no ABI compatibility guarantees from commit to commit, the README recommends building it as a static library. OpenSSL is optional: without it, the libraries that need it, such as `folly/ssl` and `AsyncSSLSocket`, are not built or installed. `cmake --install` needs CMake 3.28 or newer once anything has been fetched, and an installed folly expects its dependencies on the consumer's system.

The ABI decision is the whole adoption decision

The README states plainly that Folly does not provide any ABI compatibility guarantees from commit to commit and generally recommends building it as a static library. That single sentence determines most of the operational cost. A static link means Folly's code is compiled into your binary, so an upgrade requires recompiling your translation units that include Folly headers, not just swapping a shared object. The cost is build time and binary size, and it grows with how much of Folly you touch. The release cadence visible in the repository is weekly, with tags in a date-based form such as v2026.10.26.00. Nothing in the README says you must track that cadence, but it does mean the distance between the commit you pin and current main widens quickly.

Where Folly is the wrong tool

Folly is a poor fit when your project needs a stable binary interface. If you ship a shared library to third parties and expose Folly types in your public headers, the absence of ABI guarantees between commits turns every Folly bump into a coordinated release with your consumers. It is also a poor fit when the component you want already exists in std or Boost in an adequate form. The README's stated policy is to move folly and its users to the standard version when std provides an equivalent, which means any given component may be on a path to deprecation, and betting on it is betting against the project's own stated direction. Finally, the platform support deserves a careful read. The README says Folly supports gcc, clang, or MSVC with C++20 support and should run on Linux (x86-32, x86-64, and ARM), iOS, macOS, and Windows (x86-64), but it also says the CMake build is only tested on some of these platforms, aiming at minimum for macOS and Linux on the latest Ubuntu LTS or newer. "Should run" and "is tested" are different claims, and the gap is where your build breakage lives.

Boost and std as the comparison, and what the difference actually is

The natural alternative is Boost, and the README frames Folly in terms of std: it builds on std and adds a component when std does not provide it or does not meet Meta's needs. The difference in approach is governance and scope. Boost is a collection of separately reviewed libraries with a long history of interface stability and a wide platform matrix. Folly is a single repository with no internal dependency restrictions, meaning any Folly module may use any other Folly component, and a flat directory structure that mirrors one namespace. That internal freedom is what allows a header like SmallLocks.h to exist at all, because a component can reach into another component's internals without negotiating an interface boundary. The trade is that you cannot take one Folly component in isolation as cleanly as you can take one Boost library, and the README confirms there is no restriction on internal dependencies. If you want a small, stable, independently versioned piece of functionality, Boost's model fits better. If you want the thing Meta built because the existing options were too slow at Meta's scale, Folly is the only place that thing exists.

Maintenance cost and licence

The maintenance burden is dominated by the rebuild-on-upgrade model described above. Because Folly is built as a static library with no ABI guarantees between commits, the recurring cost is compile time in your own build, not a dependency resolution step. The CMake build mitigates part of this by fetching any required dependency it cannot find installed, and the README offers install-system-deps as an alternative way to install system packages first. Folly is licensed under Apache-2.0, which is a permissive licence that permits use in proprietary software and requires preservation of notices. This article is not legal advice; if you redistribute Folly in binary form, read the licence text and your organisation's policy before relying on that summary.

Editorial conclusion

Adopt Folly if you are already inside a Meta-adjacent C++ stack (Meta's other open source C++ projects) or you specifically need a component such as FBString or the folly synchronization primitives that std and Boost do not provide in the form you need. Do not adopt it as a general-purpose utility library for a small project: the README states there are no ABI compatibility guarantees from commit to commit, so every upgrade is a rebuild of your own code. Before committing, clone the repository, run `cmake -B _build` and `cmake --build _build`, and read folly/docs/Overview.md to see whether the specific header you want is stable or lives under folly/experimental.

Frequently asked questions

Official sources

1. facebook/folly on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases