[HN Gopher] Folly: An open-source C++ library developed and used...
___________________________________________________________________
Folly: An open-source C++ library developed and used at Facebook
Author : u1tron
Score : 76 points
Date : 2022-01-07 16:41 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ComputerGuru wrote:
| See previous discussions dating all the way back to 2012:
|
| https://news.ycombinator.com/item?id=4059356
|
| https://news.ycombinator.com/item?id=22875090
| oscargrouch wrote:
| Looking again at it, its quite bigger now. I wonder how it
| compares to Boost and now also Abseil? (features and
| performance-wise)
| jsheard wrote:
| Folly depends on Boost so it's more of a superset of it
|
| Which unfortunately means Folly is an _extremely_ heavyweight
| dependency to pull in compared to Abseil, if you 're not
| already using Boost
| Blackthorn wrote:
| Boost doesn't feel like a heavyweight dependency.
|
| I mean, yes, Boost itself is big. But when I think a
| heavyweight dependency, I think of something that itself
| pulls in a shitton of dependencies Javascript-style. And
| AFAIK Boost doesn't have any dependencies.
| dundarious wrote:
| Try debug anything in boost. I didn't enjoy it. It's a
| heavyweight dependency, all on its own.
| boardwaalk wrote:
| I'm afraid that's a very JS viewpoint. A dependency
| doesn't need dependencies itself to be heavy.
|
| Start using some of the heavier weight sub-libraries and
| you can quickly explode your compile times. I have boost
| beast/asio on one project and it takes over a minute to
| compile one of the source files...
| ComputerGuru wrote:
| Boost is (was?) considered to be such a heavy dependency
| (especially in the days before distribution package
| managers and build systems got their act together and
| collaborated or at least acknowledged the reciprocal
| efforts of one another) that it's probably single-
| handedly responsible for easily at least half of the so-
| called "NIH" libraries/ad-hoc solutions I encountered for
| a particular decade of my career as a C++ developer.
|
| At one point, I had a curated SVN repository of certain
| boost header-only includes that didn't require any sort
| of build integration, had no dependencies of their own
| (even other boost libraries), and didn't require any
| build system integration - and I know I wasn't the only
| one.
|
| The world of native software development was just so
| unbelievably different from that of web development -
| it's really no surprise developers from that lived
| through that era have such a hard time accepting the
| modern-day age of PWAs in Electron sandboxes masquerading
| as native programs. People that cut their teeth
| developing desktop software with something like Python
| (just as an example) instead would have a completely
| different perspective on all this, of course.
| interroboink wrote:
| 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.
| vorhemus wrote:
| 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.
| lumost wrote:
| 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?
| adamnemecek wrote:
| Why not just do Rust?
| saidinesh5 wrote:
| We do have
|
| Conan
|
| Vcpkg
|
| Cpm.cmake
|
| A lot of projects these days use conan.
| alcover wrote:
| 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.
| guavaNinja wrote:
| This[1] is a c-flavoured c++ STL replacement, uses minimal
| number of c++ features to be easy to use yet simple. We built
| it and use it internally where I work.
|
| It's not c but almost c, it could be useful for you
|
| [1]
| https://github.com/MoustaphaSaad/mn/blob/master/mn/include/m...
| alcover wrote:
| Thank you. You don't seem to provide a _c_str()_ equivalent
| (a method that gives a pointer to or copies out a C-string)
| or views ? Sorry if I missed them.
| guavaNinja wrote:
| We hate getters/setters. There is `using Str = Buf<char>`
| if you looked into Buf you will find ptr and count and cap.
| You are looking for ptr
| cjensen wrote:
| 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.
| jimsimmons wrote:
| What does it do
| secondcoming wrote:
| It looks like part of it is a similar design to something I
| came up with myself. Do you know if Synchronized<> protects
| against accidental recursive locking?
| ot wrote:
| There is no explicit protection for recursive locking. In
| practice, write locks will deadlock, and read lock under read
| lock will be fine.
|
| However, the API encourages practices that make it very hard
| to recursively acquire the lock (Synchronized is about access
| to objects, not critical sections).
| zoomablemind wrote:
| 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.
| gjulianm wrote:
| I've considered it for some special things, mainly the F14 hash
| table because I needed a highly performant implementation (I
| ended up writing a custom one that takes advantage of domain
| knowledge to go faster). It seems that it has classes and
| constructs not available in other libraries. A lot of them are
| very specific, but at that point having a reliable, tested,
| fast implementation of a complex implementation might be worth
| the hassle of bringing in a new dependency.
| seertaak wrote:
| The thing with folly is: boost.
| dfghdfhs wrote:
| 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".
| MarkSweep wrote:
| The docs have a bit more detail about what is included:
|
| https://github.com/facebook/folly/blob/main/folly/docs/Overv...
| jsheard wrote:
| I agree, but HN policy is to use the title from the link
| verbatim and IME even slight editorializing to provide context
| tends to get reverted by the moderators
| jeffbee wrote:
| It's a kitchen-sink library, like Abseil. It does too many
| different things to state succinctly.
| speedgoose wrote:
| For me it sounds like an argument of authority.
| ianbicking wrote:
| I thought the same, then read the actual page and realized it's
| Just A Library. Of Stuff. Like it could be called fbutil.
| ximeng wrote:
| https://github.com/facebook/folly/blob/main/folly/docs/Overv...
|
| This has library contents: it's a mix of various utilities -
| type conversion, data structures, memory management, random
| numbers, concurrency, etc.
| simplestats wrote:
| Looks like that's because the library isn't for anything
| specific, other than general C++ programming at Facebook. They
| might worded it a bit better, like "core library" or common
| library" or something.
| samhw wrote:
| It's worse than that. The GitHub title is "Folly: Facebook
| Open-source Library". The bolded sentence in the readme is
| "Folly contains a variety of core library components used
| extensively at Facebook". In fact, the entire first paragraph
| is about how it's used at Facebook.
|
| It takes about a minute to find any information at all about
| this library besides the fact that it's used at Facebook (by
| the way, did you miss that? it's used at Facebook! Facebook!!).
| And even that information is empty bromides about how it's
| "designed with practicality and efficiency in mind". Hmm, I
| prefer my software to be impractical and inefficient...
|
| All I take away from this is that Facebook has an irrationally
| optimistic expectation of how the world views its engineering
| prowess.
| Blackthorn wrote:
| People are so grouchy over even mildly ambiguous titles.
|
| Right in the intro section, second paragraph, it says "It
| complements (as opposed to competing against) offerings such
| as Boost and of course std". Come on, what more do people
| want?
| smrtinsert wrote:
| People want an article in a headline, it's ridiculous
| frankly. Take the extra 3 seconds to scan the page.
| Veuxdo wrote:
| Rule one is don't waste people's time. Waiting until the
| second paragraph to get to the point violates that rule.
| And that's assuming your reader knows what boost or std
| are.
| Blackthorn wrote:
| Virtually everyone who uses C++ knows what Boost and std
| are.
| Veuxdo wrote:
| Perfect. Put that in your title. Or at least in the first
| sentence of your description. Not paragraph 2.
| yegle wrote:
| I would say most people who are writing C++
| professionally should known what folly (and abseil from
| Google) is.
| downut wrote:
| Missing the most important part: avoid them (including
| boost), when you have a choice.
|
| Professionals often don't have that choice. Cue many
| thousands of comments on HN why working in c++ sucks.
| aantix wrote:
| What should be used for a solid trie tree implementation?
|
| Looking to implement a memory efficient search engine.
| drewda wrote:
| Instead of pointing a finger at Facebook, I'd scoff at C++
| and the way in which the language has grown where orgs build
| up their own utility libraries rather than depend on a
| standard library.
|
| That said, this is an issue for other languages as well.
| Another example: the "Google core libraries for Java":
| https://github.com/google/guava
| jcelerier wrote:
| But why is that an issue at all ? Having boost and other
| utilities is great. And since it's all templates there's in
| practice in your binary no added cost if you're using
| folly::foo or std::foo or boost::foo, you can pick and
| choose the exact data structures that allow exactly what
| you want (or write your own if you think that you can do a
| few percent better than folly of abseil in your specific
| use case).
|
| If I was using java or python I'd definitely not use the
| standard things most of the time either because it's more
| than likely that there's a more efficient way in some other
| library, and because my main paycheck comes from "can you
| make this as fast as technically possible given this
| average consumer hardware"-problems
| PaulDavisThe1st wrote:
| interesting case in point. i just learned today that
| std::variant and boost::variant differ in their:
| 1. exception-safety guarantees 2. real-time safety
|
| 2 is caused by 1, because to be exception safe requires a
| heap allocation, and that's not RT-safe.
|
| Who would want to work in a language where you could not
| make these choices?
| simplestats wrote:
| You mean because it has gotten so unreadable and vast?
|
| I've never worked with a place using C++ that didn't make
| their own core libraries. As a low-level language, there's
| almost always a way to get some performance benefit by
| starting from scratch for your specific case.
| ryandrake wrote:
| I've also never worked in a C++ place that didn't make
| their own core libraries, but when you ask, their
| rationale for building and maintaining their own
| libraries (as opposed to using the Standard Library) is
| often very weak. It's usually based on very outdated
| assumptions and Cargo Cutting, such as "the STL[1] is
| slow (but we haven't profiled ours to prove it's
| faster)." Or "We need our own string type because decades
| ago, there was something that std::string didn't do." Or
| "Our founding developer didn't like templates, so he
| build this vast copy of the standard library but using
| explicit data types."
|
| (yes I've heard all of these "reasons")
|
| 1: Just calling it "the STL" is a key sign of living in
| the past--pretty much nobody uses the actual STL anymore:
| What we use is called the C++ Standard Library.
| antiterra wrote:
| Often these libraries exist as glue to an existing
| ecosystem. To that end, I have also seen portability
| libraries that provide a single interface to multiple
| implementations of system functions or datatypes on
| different operating systems.
| PaulDavisThe1st wrote:
| Instead of pointing the finger at C++, I'd scoff at any
| language that promotes the belief that a standard library
| could possibly meet all the needs of a project.
| Mikeb85 wrote:
| Why? Having millions of libraries is a good dilemma to
| have, even if it means a bunch don't work well together so
| you make your own anyway. Better than having no choice.
|
| C++ is a massive beast but it works.
| dosshell wrote:
| >> And even that information is empty bromides about how it's
| "designed with practicality and efficiency in mind". Hmm, I
| prefer my software to be impractical and inefficient...
|
| the opposite from practical is general. for example is std
| not practical but general. Its api is not optimized for 95%
| of the use cases but rather so that everything is possible
| and equaly verbose.
|
| the opposite of efficient can for example be trade of for
| readability, portability and cost (as in development time).
|
| For me as a possible user of the lib i found this information
| critical. I write always similar info in the readme for my
| libraries.
| didip wrote:
| If you start a green field C++ project, would you choose Folly,
| Boost only, or Abseil?
| versatran01 wrote:
| abseil and part of boost
| ot wrote:
| 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)) { ... }
___________________________________________________________________
(page generated 2022-01-07 23:01 UTC)