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

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.

People want an article in a headline, it's ridiculous frankly. Take the extra 3 seconds to scan the page.

> the opposite from practical is general

No, it's certainly not at all. Those are completely unrelated spectrums. Something can easily be practical and general, or impractical and specific.

> the opposite of efficient can for example be trade off for [...]

And if they stated what trade-offs they made, then that paragraph would actually start to say something useful. Unfortunately, they don't.

Also, if you're developing documentation for libraries, I really would recommend finding a better source of inspiration. Take Redis, in the very first paragraph:

> What this means is that Redis provides access to mutable data structures via a set of commands, which are sent using a server-client model with TCP sockets and a simple protocol. So different processes can query and modify the same data structures in a shared way.

That's all you need to do: before anything else, tell the user what the thing does. Then you can give some basic details about implementation: "written in Go", "runs on Linux & macOS", "uses GC, so not suitable for RT applications", etc. After that you can get into trade-offs, real narrow implementation details, setup, handwaving abstract adjectives, etc. But lead with what the hell it actually does.

> the opposite from practical is general.

Let me guess: English is not your native language, right?

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

> 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.

This comment makes no sense at all. I mean, would it make any sense to also criticize JavaScript/NodeJS for their relatively spartan standard modules and extensive use of vended modules from the likes of npm?

And have we learned nothing from the mistake of going with the "everything and the kitchen sink" that is java which failed to actually satisfy basic needs and resulted in projects like guava and apache commons and vavr stepping in to provide alternatives? And how about C's infamous standard library with it's security vulnerability-inducing standard functions which remain in the standard?

Perhaps we should learn lessons and avoid basic mistakes such as setting libraries in stone. C++ learned that lesson, and so did C#/.NET, and up to a point Rust. Why unlearn them?

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.

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.

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.

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.

Yes, in the end I had to go to a custom hashmap/linked list combination to get the best performance for our specific use case (basically a flow table with LRU cache behavior and also expiration of flows by time limits).

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

Funny, I have a full time C++ job, and really don't see the appeal. Rust feels superior in every regards and especially dev experience. Want to exchange jobs ;-)?

Could you share a link to any resource that explains the common flaws and workarounds in C++?

They don't, but C++ programmers especially are familiar with not letting inappropriate things escape scopes; they're much less familiar with not letting inappropriate things escape _expressions_. I've reviewed over a half million lines of code from engineers of every level of experience, and I've seen far more bugs from the latter than the former. For instance, a former employer had a function similar to folly::get_default, except it returned the default by reference, and engineers were always running afoul of lifetimes using that function. (It was especially egregious with std::string temporaries returned from string literal defaults.)

Thread annotations also effectively prevent unsynchronized access to the object, but they do it in a way that programmers make fewer mistakes with, and they do it with a less error prone mental model: mutexes are seen as guards of _class invariants_, not merely as guards of _data members_. Apart from encouraging a superior mental model, thread annotations also encourage a one-mutex-per-class model which I've found far more successful and error prone (both in code I've reviewed and in code I've written) over a one-mutex-per-member model which inevitably (in my experience) results in fewer bugs.