> I can only assume that there must be some interal NIH rule inside Google to use abseil in place of the C++ stdlib

FWIW my understanding is that this is exactly backwards: Abseil exists because the internal code and toolchain evolved to use features that hadn't landed in the standard yet, and releasing the support this way allows that dependent code to be used in open source releases. It's not about features Googler's "can't" use, it's that they[1] could always use better stuff, and this is a way to get the better stuff released so non-Googlers could use it at all (and then, apparently, complain about it).

Obviously looking at this in hindsight from the outside of a project using gcc13/clang15, it seems like it's needlessly different. But when written it was forward-looking.

[1] "We", I guess, though I work in ChromeOS and not in this world.

I cannot more strongly endorse this.

It would be tremendously beneficial if their software dropped the abseil dependency, especially where it is almost entirely unused. Hell it'd be better if they simply vendored the bits they need.

Having to use Bazel, and having to manage an additional dependency like abseil can be hellish for small projects with uncomplicated build systems.

The worst part is that abseil leaks through interfaces and you end up being coupled to it as a consumer of a library. It's bananas. I don't need yet another stdlib.

Just glancing at Dawn, which I never heard of until now, it appears their use of absl is similar in purpose to the way other Google open source projects use it: faced with the choice between requiring C++20 (or 17, or 14) or requiring only C++11 and using absl as a kind of polyfill, they chose the latter.

Many of the authors of abseil are on the C++ committee and contribute to its progress--this is especially true of the string library, where abseil convinced the standards committee to adopt string_view.

The dependency here almost certainly predates C++ adopting the features it has had for a decade.

For string related stuff — there’s not much in the stdlib that can replace the stuff in abseil. (Haven’t looked at Dawn in particular, though.)

E.g. absl::StrFormat — no equivalent until std::format was standardized in C++20.

absl::StrCat: You could use streams, but, ew. Also, StrCat is optimized to reserve sufficient size in advance, so it is more efficient than appending to a string or using a std::stringstream.

absl::Cord. No equivalent in the stdlib.

C++ stdlib didn’t have string_view for ages. Also, until recently, C++ sucked for things like convert to/from strings and string buffers. std::stringstream is awful.

The string stuff in abseil is mostly a historical byproduct of what google was doing in 1998: manipulating lots of strings. at the time, the C++ standard library string implementation (mainly the GNU one) was immature and slow. The string library was written in the early days for performance reasons, as well as reliability (at the time, the libstdc++ was so bad that most string operations just made garbage, not strings). And then it got too expensive to change the entire codebase.

I remember Sanjay Ghemawat or Jeff Dean mentioning that one of their big "optimizations" was to inline short strings into the string object- instead of a string that was "size_t len, size_t capacity, char *data", anything less than 24 bytes was just stored directly instead of with a pointer. when you're running mapreduces with trillions of small keys, this makes a big difference!

Part of the pressure behind abseil is that perf and promotions are correlated with open source (Tensorflow, Chromium, TFX, etc) and it would be essentially impossible to translate internal projects for public release without a public library like abseil.

In contrast Facebook Folly has much less overall clout because engineers there have more incentive to build-from-scratch, which can include simply not using C++.