folly provides functions to resize std::string & std::vector without initialization [0].
[0] https://github.com/facebook/folly/blob/3c8829785e3ce86cb821c...
In Appending to an std:string character-by-character: how does the capacity grow?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
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
- meta/wangle · linked in 2 of the same discussions
- scylladb/scylladb · linked in 2 of the same discussions
- scylladb/seastar · linked in 2 of the same 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, 9:01:12 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.
* 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
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 7 | 4 | 3 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 13 | 2 | 11 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 16 | 1 | 15 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 12 | 1 | 11 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
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 GitHubWhat Hacker News says
14 sourcesIt is doable, `folly::Expected` supports that: https://github.com/facebook/folly/blob/main/folly/test/Expec...
In How to Use Monadic Operations for `std:optional` in C++23> How is that relevant?
Roaring bitmaps and similar data structures get their speed from decoding together consecutive groups of elements, so if you do sequential decoding or decode a large fraction of the list you get excellent performance.
EF instead excels at random skipping, so if you visit a small fraction of the list you generally get better performance. This is why it works so well for inverted indexes, as generally the queries are very selective (otherwise why do you need an index?) and if you have good intersection algorithms you can skip a large fraction of documents.
I didn't follow the rest of your comment, select is what EF is good at, every other data structure needs a lot more scanning once you land on the right chunk. With BMI2 you can also use the PDEP instruction to accelerate the final select on a 64-bit block: https://
In A compressed indexable bitset> We haven't discussed other solutions like Partitioned Elias-Fano indexes or Tree-Encoded Bitmaps. We simply did not investigate them. There are no efficient off-the-shelf implementations of these solutions, so we had to implement one.
I guess they mean there are no implementations in Rust? The Partitioned Elias-Fano (PEF) paper links to the C++ implementation ([1], which I wrote) used for the experiments, it was efficient 9 years ago :) The library was later forked [2] and used in a few other papers, I believe it is somewhat maintained.
The EF core algorithm implemented in folly [3] may be a bit faster, and implementing partitioning on top of that is relatively easy.
It would definitely compress much better than roaring bitmaps. In terms of performance, it depends on the access patterns. If very sparse (large jumps), PEF would likely be
Read the rest
faster, if dense (visit a large fraction of the bitmap), it'd be slower.
It is possible to squeeze a bit more compression out of PEF by introducing a chunk type for Elias-Fano of the chunk complement (for very dense chunks), but you lose the operation of skipping to a given position, which is however not needed in inverted indexes (you only need to skip past a given id, and that can be supported efficiently). That is not mentioned in the paper because at the time I thought the skip-to-position operation was a non-negotiable.
[1] https://github.com/ot/ds2i/
[2] https://github.com/pisa-engine/pisa
[3] https://github.com/facebook/folly/blob/main/folly/experiment...
C++ with folly's SCOPE_EXIT {} construct:
https://github.com/facebook/folly/blob/main/folly/ScopeGuard...
In Defer for Shell (2020)Can't speak for abseil and tbb, but in folly there are a few solutions for the common problem of sharing state between a writer that updates it very infrequently and concurrent readers that read it very frequently (typical use case is configs).
The most performant solutions are RCU (https://github.com/facebook/folly/blob/main/folly/synchroniz...) and hazard pointers (https://github.com/facebook/folly/blob/main/folly/synchroniz...), but they're not quite as easy to use as a shared_ptr [1].
Then there is simil-shared_ptr implemented with thread-local counters (https://github.com/facebook/folly/blob/main/folly/experiment...).
If you absolutely need a std::shared_ptr (which can be the case if you're working with pre-existing interfaces) there is CoreCachedSharedPtr (https://github.com/facebook/folly/blob/main/folly/concurrenc...), which uses
Read the rest
an aliasing trick to transparently maintain per-core reference counts, and scales linearly, but it works only when acquiring the shared_ptr, any subsequent copies of that would still cause contention if passed around in threads.
[1] Google has a proposal to make a smart pointer based on RCU/hazptr, but I'm not a fan of it because generally RCU/hazptr guards need to be released in the same thread that acquired them, and hiding them in a freely movable object looks like a recipe for disaster to me, especially if paired with coroutines https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p05...
Not sure if it's still the case but about 6 years ago Facebook's folly C++ library was something I'd point to for my junior engineers to get a sense of "good" C++ https://github.com/facebook/folly
In Ask HN: What are some of the most elegant codebases in your favorite language?Growing std::vector by a factor that allows memory reuse (2020)
1 points · Open discussionMost modern hash map designs don't do this weird shuffle with buckets and linked lists because pointer chasing is super expensive.
https://doc.rust-lang.org/std/collections/struct.HashMap.htm...
Because it's documenting the actual API in the standard library this even spells out that the result has "at least the specified capacity"
https://github.com/facebook/folly/blob/main/folly/container/...
F14 is a linear map but I couldn't immediately find actual API documentation, however it should have the same property where if you ask for an F14 with specific capacity or you reserve enough capacity, that's an "at least" promise not an approximate one.
In Deduplicate a slice in Go, use sort or a map?folly::Synchronized<T> provides a similar pattern. It works well for very simplistic concurrency schemes.
struct { int a; int b; } A;
folly::Synchronized<A> syncA;
int c;
{
auto aReader = syncA.rlock();
c = aReader->a;
// aReader going out of scope drops the rlock
}
{
auto aWriter = syncA.wlock();
aWriter->b = 15;
// aWriter going out of scope drops the wlock
}
I would argue that the pseudo-pointer accessor objects are more usable than passing lambdas to a `with()` method, but if you want that, folly::Synchronized provides similar `withWLock()` and `withRLock()` methods.
And in fact, MutexProtected seems to provide APIs like Synchronized's `rlock()`/`wlock()`: `lock_shared()` and `lock_exclusive()`: https://github.com/SerenityOS/serenity/blob/master/Kernel/Lo... I don't know why the article does
Read the rest
How does this compare with:
* Using std::atomic<T> ? https://en.cppreference.com/w/cpp/atomic/atomic
* folly::Synchronized, mentioned by ot57? https://github.com/facebook/folly/blob/main/folly/docs/Synch...
* Boost synchronized data structures, -mentioned by mchicken 53? https://www.boost.org/doc/libs/1_81_0/doc/html/thread/sds.ht...
?
... it looks like the SerenityOS people developed this without considering the C++ ecosystem of today.
In MutexProtected: A C++ Pattern for Easier ConcurrencyThat's how folly::Synchronized works, it supports both the callback interface as MutexProtected, and an interface that returns a RAII lock holder that gives access to the underlying object. It is generally the preferred synchronization utility at Meta and thus it is widely used.
https://github.com/facebook/folly/blob/main/folly/docs/Synch...
In MutexProtected: A C++ Pattern for Easier ConcurrencyYeah. In the C++ codebase I work on, we use folly::Expected<T, E> (essentially similar to Rust's Result<T, E>) heavily. Is it as ergonomic as Result is in Rust? Absolutely not. But it's still a nice design pattern for some of the same reasons people use Result in Rust.
(And C++ std::optional<T> is somewhat similar to Rust's Option<T> type.)
https://github.com/facebook/folly/blob/main/folly/Expected.h...
In Switching from C++ to Rust