Folly needs a revision policy before you adopt a component
Folly provides no ABI compatibility guarantee between commits, and its README recommends a static library. That should shape the dependency decision before a useful container or executor catches your attention. If you expect to replace a shared library independently of the applications calling it, Folly's stated policy is a reason to choose something else.
Meta's Folly is a collection of C++20 components, including F14 hash containers, futures, executors and IOBuf byte buffers. The project says it fills gaps where the standard library does not meet Meta's needs. That is a sensible starting point for investigating a particular component. It gives you no measured reason to expect a performance gain in your own application.
What happened when we ran it
Our Folly Python-subdirectory install succeeded in 13 seconds and the recorded build step in 1 second at commit f190b61 on November 4, 2026. The run recorded 35 dependencies and 38 MB on disk. Tests exited 1 after 2 seconds: pytest recorded 0 passed, 0 failed and 2 collection/setup errors. A successful recorded build step did not produce a passing Python suite.
The tail names test/test_iobuf_ext.py and test/test_set_executor.py as errors. The visible traceback imports test_set_executor_cython through folly.python.test and ends with ModuleNotFoundError: No module named 'folly'. It establishes an unavailable import, without establishing why it was unavailable. There is insufficient evidence to prescribe a package or path change as the fix.
The target was ./folly/python/, so these results do not verify the main C++ library, its components or a native consumer. Nor do the collection errors prove those components are broken. The recorded pip-audit reported zero known vulnerabilities, which supplies no assessment of the native library's security. Treating either result as a verdict on all of Folly would cross the boundary of the run.
The sandbox configuration lists 3 CPUs, 8 GB RAM and image ghcr.io/astral-sh/uv:python3.12-bookworm. The image label does not establish actual runtime or operating-system versions. The checkout contained 3,272 files, approximately 763,762 source lines and 31.3 MB. The scan found five CI workflow files and a tests directory, with no Dockerfile. None of that substitutes for exercising the component your application needs.
A successful native integration still needs the right optional features
The current README says OpenSSL is optional and that libraries needing it are omitted when it is absent. Examples include AsyncSSLSocket and SSLContext. It identifies FOLLY_HAVE_OPENSSL in the installed configuration header as the indicator of how Folly was built. For an application needing those interfaces, a generic success message would therefore leave an important question unanswered.
The README gives a similar warning for gflags. Its presence is decided when Folly is built and recorded in folly-config.h. Linking gflags into a consumer afterward does not enable Folly's flag handling. If your integration expects command-line flag parsing, check the installed configuration instead of assuming the consumer's dependencies determine Folly's behavior.
Those are documented configuration boundaries, not failures reproduced in our sandbox. They suggest a useful evaluation: choose the public interface you require and create a small native consumer that actually calls it. Preserve the dependency options with the revision. That exercise can expose an omitted component or changed behavior that our Python-subdirectory result cannot address.
Relatively independent components can depend on each other
Folly describes its components as relatively independent, while allowing any module to depend on other Folly components. A small public interface therefore does not establish a small integration burden. Inspect the requirements of the chosen component before treating it as an isolated header you can carry without further decisions.
The README also tells users to avoid internal and detail namespaces. Files in folly/experimental are not considered stable enough for client use, with an explicit warning that updates can break callers. If the example motivating adoption reaches into those areas, accept that maintenance burden deliberately or look for a supported public interface.
My recommendation is to pin Folly with the consuming application and rehearse an upgrade through that consumer. This follows the documented compatibility boundary rather than an assumption that frequent releases preserve interchangeable binaries. The README itself recommends a temporary installation location over traditional system directories, then pointing the application's build at that location.
Windows support comes with narrower coverage
The README names Linux, macOS, iOS and Windows, but says the CMake build is checked on only some platforms. It explicitly warns that many Windows tests are disabled. A supported-platform list therefore needs a component-specific follow-up before it can answer a Windows deployment question.
For a Windows application, inspect the disabled cases relevant to your component and exercise its behavior in the intended consumer. That is a proposed next step, with no native Windows outcome in our record. A team unable to own that platform work has a concrete reason to decline Folly, even if its desired API looks attractive.
Abseil and Boost deserve a component-level comparison
Abseil provides C++ utilities and Long Term Support releases with backported severe-bug fixes. Consider it when its utilities solve the requirement and that release policy fits your maintenance process. This review does not establish interchangeable ABI compatibility or a smaller installation footprint for Abseil.
Boost provides peer-reviewed portable C++ source libraries. Look there when a specific library already covers the required capability. Compare that library's interface and requirements with the Folly component you would actually use. Neither alternative was measured alongside Folly, so there is no comparative setup or performance result here.
GitHub records a Folly push on November 10, 2026. Recent issue-and-PR activity includes AsyncUDPSocket payload handling and ProducerConsumerQueue alignment work, while the latest release endpoint lists v2026.10.26.00 from October 26. Together these show current maintenance, without changing the compatibility policy. Before adoption, require a native consumer that exercises the needed interface and a repeatable way to move that consumer to the next pinned revision.