There is an extremely small set of domains where simple threading doesn't suffice, and async/await is too high a price to pay across the entire software ecosystem just to slightly optimize those domains.

It's typically less than a hundred kilobytes and (on the systems I've benchmarked using std::thread) it takes 60usec (wall time in userspace) to create and destroy a thread.

Threads have gotten so fast that paying the async function coloring price makes very little sense for most software.

Does this surprise you? The council of Nicea where this was defined as the orthodox claim happened in A.D. 325.

> I'm sure different sects believe differently on that, but plenty do accept that. When I ask "how is it possible to be 100% human and 100% God?" you'll sometimes get answers like, "well it's like water in different for

The _vast majority_ hold that, because the vast majority affirm Nicea. The only major denominations not holding to the orthodoxy here are (in descending order of size) Latter Day Saints (Mormons), Oneness Pentecostals, Jehovah's Witnesses, Unitarians, and Christadelphians. They represent approximately 1.6-2.4% of the Christian population.

> you'll sometimes get answers like, "well it's like water in different forms, ice, liquid, and vapor" but that doesn't answer the question

The real (orthodox) answer depends on a metaphysics of substance that most Christians, even those who hold the orthodox view, are ill-prepared to elaborate on.

John, on the other hand, is organized around theological and moral themes, rather than the totality of Jesus' ministry and teachings. That's why it's not considered a synoptic gospel.

A cubic lightyear is about 8.468e+50 liters, and butter weighs 911 g/L, giving the mass of a cubic lightyear of butter to be 7.714348e+50, whose Schwarzchild radius is about 121,103,293 lightyears, about 100x smaller than the radius of the known universe.

In my experience, practically every single time I've used absl::btree_map, I've ended up reverting for performance reasons to either a flat hash map or, in some relatively rare cases, a sorted vector map (despite its O(n) insert/erase) because the constant factors are _so doggone low_. The experience remains: btree_map (or SkipLists, or whatever) has (in my experience) essentially never, in over a half million lines of C++, actually remained in the code.

Also, I presume (based on the implementation details, not based on actual use) that roaring bitmaps have some reasonable iteration API that would make them relevant even to the ordered comparison.

The important thing here is that if anyone wants to contend that someone should use their new data structure because it's better or faster or more optimal for some particular use case, it's important for them to demonstrate that they've thoroughly investigated the data structure space around their proposal. Comparison against std::map and std::unordered_map simply doesn't demonstrate the kind of comprehensive knowledge that I would expect from someone who claims that I should use their optimized integer map in my own code.

Heck, let's go even further. All the computers I've used have a fixed amount of memory, addressable by a u64, so I guess all my algorithms are constant time now.

I guess we've solved the interview, folks.

If a colleague came to me to discuss a question this basic, I'd want them PIPed out. This is miles from the complexity of problems that require collaboration. It's a shell pipeline that I'd write with sort/uniq in less than five minutes. I just did it to make sure my estimate wasn't wrong:

    sort <(sort -u <(cut -d' ' -f1,2 /tmp/day1)  <(cut -d' ' -f1,2 /tmp/day2) | cut -d' ' -f1 | uniq -d) <(sort <(cut -d' ' -f1 /tmp/day1 | sort | uniq) <(cut -d' ' -f1 /tmp/day2 | sort | uniq) | uniq -d) | uniq -d

If your perspective is that it's unrealistic to ask anyone to come up with an answer to this question on the spot, you should take a long, hard look at yourself and the quality of your colleagues.