HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
meta
folly
C++2012–2026
meta / folly

folly

An open-source C++ library developed and used at Facebook.

90Distinct people
144Mentions
1Explicit recommenders
30.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An open-source C++ library developed and used at Facebook.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

See also F14 (https://github.com/facebook/folly/blob/master/folly/containe...), it uses a similar design to SwissTable but was opensourced a few months earlier. Interestingly…

ot used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:01:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year144 dated mentions

Observed mentions: 2012-06-02 22:14:59 UTC to 2026-01-14 03:35:51 UTC.

0510152012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 7 mentions; 4 submissions, 3 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 13 mentions; 1 submissions, 12 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 13 mentions; 2 submissions, 11 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 16 mentions; 1 submissions, 15 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 14 mentions; 0 submissions, 14 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC743
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC312
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC13112
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC505
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC13211
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC14113
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC1028
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC808
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC16115
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC14014
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC615
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC14113
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC12111
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC808
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Folly: Foundational Open-source Library What is folly? Folly (originally an acronym for Facebook Open-source Library) is a library of C++20 components designed with practicality and efficiency in mind. Folly contains a variety of core library components used extensively at Meta. In particular, it's often a dependency of Meta's other open source C++ efforts and place where those projects can share code. It builds on std and fills its gaps. We add a component when std doesn't provide it, or doesn't meet the performance, scalability or interface Meta's code needs. When std provides an equivalent, we move folly and its users to the standard one and keep the folly name only as long as users need it. Performance concerns permeate much of Folly, sometimes leading to designs that are more idiosyncratic than they would otherwise be (see e.g. PackedSyncPtr.h, SmallLocks.h). Good performance at large scale is a unifying theme in all of Folly. Check it out in the intro video Logical Design Folly is a collection of relatively independent components, some as simple as a few symbols. There is no restriction on internal dependencies, meaning that a given folly module may use any other folly components. All symbols are defined in the top-level namespace folly, except of course macros. Macro names are ALL_UPPERCASE and should be prefixed with FOLLY_. Namespace folly defines other internal namespaces such as internal or detail. User code should not depend on symbols in those namespaces. Physical Design The sources live in the folly/ directory, so headers are included with the library name as a prefix, e.g. #include <folly/FBString.h>. The directory structure is flat (mimicking the namespace structure), i.e. we don't have an elaborate directory hierarchy (it is possible this will change in future versions). The subdirectory experimental contains files that are used inside folly and possibly at Meta but not considered stable enough for client use. Your code should not use files in folly/experimental lest it may break when you update Folly. The folly/test subdirectory includes the unittests for all components, usually named ComponentXyzTest.cpp for each ComponentXyz.*. The folly/docs directory contains documentation. What's in it? Because of folly's fairly flat structure, the best way to see what's in it is to look at the headers in top level folly/ directory. You can also check the docs folder for documentation, starting with the overview. Folly is published on GitHub at https://github.com/meta/folly. Build Notes Because folly does not provide any ABI compatibility guarantees from commit to commit, we generally recommend building folly as a static library. folly supports gcc, clang, or MSVC with C++20 support. It should run on Linux (x86-32, x86-64, and ARM), iOS, macOS, and Windows (x86-64). The CMake build is only tested on some of these platforms; at a minimum, we aim to support macOS and Linux (on the latest Ubuntu LTS release or newer.) Build with CMake The CMake build fetches any dependency it cannot find installed, so a clone and two commands are enough: git clone https://github.com/meta/folly cd folly cmake -B _build cmake --build _build Anything already on the system is used as-is. Alternatively, install the system packages first: 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 (the library itself uses gflags only if it is installed): cmake -B _build -DBUILD_TESTS=ON cmake --build _build (cd _build && ctest) Whether folly uses gflags is decided when folly is built and recorded in the installed folly/folly-config.h; linking gflags into a program later does not turn it on. Without gflags, folly::Init does not parse command-line flags, folly::gflags::FlagSaver and folly::gflags::SetCommandLineOption do nothing, and the cli libraries are not built. Declare folly's flags with the FOLLY_GFLAGS_DECLARE_* macros from folly/portability/GFlags.h, not with gflags' DECLARE_*, which would not match how folly defined them: without gflags, for example, a string flag is a std::string rather than a reference. cmake --install needs CMake 3.28 or newer once anything has been fetched, because fetched dependencies are deliberately left out of what folly installs. An installed folly expects its dependencies on the consumer's system instead; folly-config.cmake looks them up with find_package. getdeps.py getdeps.py also builds folly's sibling projects. Prefer the CMake build above unless you need that. This script is used by many of Meta's OSS tools. It will download and build all of the necessary dependencies first, and will then invoke cmake etc to build folly. This will help ensure that you build with relevant versions of all of the dependent libraries, taking into account what versions are installed locally on your system. It's written in python so you'll need python3.6 or later on your PATH. It works on Linux, macOS and Windows. The settings for folly's cmake build are held in its getdeps manifest build/fbcode_builder/manifests/folly, which you can edit locally if desired. Dependencies If on Linux or MacOS (with homebrew installed) you can install system dependencies to save building them: # Clone the repo git clone https://github.com/meta/folly # Install dependencies cd folly sudo build/fbcode_builder/getdeps.py install-system-deps --recursive If you'd like to see the packages before installing them: build/fbcode_builder/getdeps.py install-system-deps --dry-run --recursive On other platforms or if on Linux and without system dependencies getdeps.py will mostly download and build them for you during the build step. Some of the dependencies getdeps.py uses and installs are: boost. googletest is required to build and run folly's tests. Build # Clone the repo git clone https://github.com/meta/folly cd folly # Build, using system depende
Read the full README on GitHub

What Hacker News says

16 sources
I wouldn't be doing my job if I failed to mention that both Alexei (eBPF) and Jens (io_uring, block) work at Facebook. Beyond them, we've got a bunch of folks working on the primitives as well as low-level userspace libraries [0] that enable us to use all of this stuff in production, so, by the time you're seeing it, we've demonstrated that it works well for all of Facebook's load balancers, container systems, etc. [0] https://github.com/facebook/folly/blob/16d6394130b0961f6d688...
In How io_uring and eBPF Will Revolutionize Programming in Linux
Lets say you have 8 independent counters and 4 CPUs. Each gets 4 slots in 4-cacheline = 256 byte storage. Counter0 gets slots 0, 64, 128, and 192. Counter1 gets slots 8, 72, 136, and 200. And so on. Then you map CPU0 to slot 0, CPU1 to slot 1, CPU2 to slot 2, and CPU3 to slot 3. Since we share the mapping between all counters. Any bump of any counter on CPU0 touches only cache line 0. So there isn't any false sharing. In practice, mapping CPU to slot isn't quite so easy. But you can get a pretty good mapping using the strategy in this post, or something like folly::AccessSpreader::cachedCurrent() [0]. In new kernels, I believe there is kernel support for getting this mapping, using the rseq library. The kernel will update the current CPU in a thread local on every context switch. [0] https://github.com/facebook/folly/blob/a590a0e559d0f1c7
Read the rest
In A Concurrency Cost Hierarchy
There is no reason for memory or speed to be different. What I mean is that parts of these libraries could be single small packages that would be as fast. As an example, look at this folder which: https://github.com/facebook/folly/tree/master/folly/compress... In short, these are compression tools. Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Things don't have to be more or less generic.
In Folly – Faceboook’s open source C++ library
Yes there is some concern that it would affect code size and/or make some optimizations impossible, but on the latter I have yet to see hard data that that is the case. We're talking about adding about 1-2 cycles of latency. Note that the branch can be implemented in a way that compilers will lower into a CMOV, making the code size issue almost moot. I implemented that in fbstring back in the day: https://github.com/facebook/folly/commit/be4c6d6b3e21914df8a... This is the entirety of size(): 0f b6 57 17 movzbl 0x17(%rdi),%edx b8 17 00 00 00 mov $0x17,%eax 48 29 d0 sub %rdx,%rax 48 0f 48 47 08 cmovs 0x8(%rdi),%rax A bit more than a MOV, but not that much. > I'd personally think it would be interesting to test artificially increasing the sizeof() of strings from 24 bytes (
Read the rest
the minimum needed to store a pointer, size and capacity) to something like 64 bytes, just to get longer strings using the SSO And libstdc++ is actually 32 bytes :( It's easy to template on the inline capacity, you can look at llvm::SmallVector or folly::small_vector, but vocabulary types should have the smallest possible footprint. Vast majority of instances are either empty, or very small (think keys in a map).
In Libc++'s Implementation of std::string
Yeah, exactly :) when in SSO mode, it stores the size as a delta occupying a single byte, but when in heap-allocated mode, it stores the size as a an 8-byte size_t, and you require a branch to check which case is the right one. You can see the branch here in the source [0], and godbolt confirms that for std::string it's just a memory load [1]. A shame Folly isn't available on Compiler Explorer, would be interesting to compare. [0]: https://github.com/facebook/folly/blob/master/folly/FBString... [1]: https://godbolt.org/z/U-LvGm
In Libc++'s Implementation of std::string
hey i've worked on this stuff for awhile at fb. One important update is that the primary rationale for us, at the time, to change std::string's implementation to `fbstring` was to get SSO. We got huge perf wins for having SSO on std::string. (small string optimization for those unfamiliar with the initialism). This, at the time, was a violation of the standard. By wording, SSO was not standard compliant. Once the standard was changed (as of C++11) so that std::strings could have SSO, we removed our patches on the standard library and now use "vanilla" std::string (from libstdc++). We still have `folly::fbstring` for people who want that implementation (which is smaller, and has more in-situ capacity, because of various cleverness detailed in that talk), but it's no longer our `std::string`. For reference: https://github.com/facebook/folly
Read the rest
In Libc++'s Implementation of std::string

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.