I think you’re understating how many quic implementations exist. Google, Apple, F5, Facebook, Fastly, Cloudflare, Microsoft, AWS all have separate implementations servicing significant production traffic, most of them open source. That doesn’t even count the smaller, language-specific implementations. Searching for quic interop tests is a good way to discover the various implementations.
Failures while communicating to the external systems (the kv store and elastic in your example) are usually where this falls down. It's easy to build a system that's consistent ~90% of the time, but if you want to build a system where things like failures during snapshot write or failures during export to elastic are handled properly it starts getting complex (you will need to find ways to recover and retract data, or build smarts into the consumer to query around aborts, or find a way to do a 2PC-esque dance with the external system a la Kafka's transaction support, etc.). Getting to full consistency isn't easy.
It's very hard for Kafka Connect plugins to maintain consistency in all scenarios - both because of the semantics of some upstream databases, and because of the guarantees the connect API itself offers. Hopefully KIP-618 will eliminate more of the edge cases though.
IRC is excellent, and located around the Bay Area (there are usually at least a few people carpooling down from Oakland) - https://www.insightretreatcenter.org
It's the retreat side of IMC (https://www.insightmeditationcenter.org). You might listen to some of their talks or read some of Gil's writing[1] to see if it's what you are looking for. It's in the Vipassana tradition, though a number of the teachers had affiliation with the SF Zen Center.
Allen Webster, the creator, was recently interviewed on the Handmade podcast. I thought it was a good discussion - touched on text editors, performance, and some interesting programming language ideas. https://handmade.network/podcast/ep/14a5407e-5f73-4c59-a422-...
Many of the current users, including the creator, are in gamedev. Being extensible in a language they’re already intimately familiar with is a selling point.
This is done by some apps today, though the motivation was typically network perf (http2 and then QUIC support). The stacks are large - on iOS it's difficult to take over a portion of networking without rebuilding a substantial amount of it, so you'll have TLS, a full http stack, plus all supporting logic for connection pooling, etc.
The closest thing to an open-source, drop-in option like this is cronet, the networking core of chromium packaged as a standalone library. Last I looked it was multiple megabytes in size, which is still a substantial cost for iOS apps. They can also be quirky to use because they fight against the system's defaults in some areas and can cause other inefficiencies (typically outweighed by the network improvements).
I believe Uber talked publicly about adopting cronet, and Facebook gave a talk about mobile proxygen (though it is not open-source). If you pop open the Netflix and Youtube apps, you will likely see the same.
I think the small upside (a single 5-star rating contributes very little to app ranking) is outweighed by the potential downsides (it can be a turnoff if the user sees that because it strikes of astroturfing, which seems a hot topic these days; it violates app store guidelines, though there's a close to zero chance of that being enforced).
To me it seems like unnecessary risk for little benefit.
Edit: And product reviews are not the same as voting. :)
I agree, HashMap is unnecessarily hamstrung because the API requirements push it into a bucket chained implementation (C++ also made this mistake and is one of the downsides of std::unordered_map). And you can definitely write a faster implementation with an array based hashtable.
But I still stand by "you can only do so much being a reference heavy language." Unless you stick to purely primitive types, implement the hash table off heap, or Project Valhalla bears fruit, it's hard to get the data layout you'd want for a really good implementation. So I agree it can be better, but it's going to be hard to get to best - hence my comment.
There are cases where you need them, but it's relatively rare, they definitely shouldn't be your first choice.
I'm fuzzy on all the current Linux use cases, but do remember one of the main users of rb trees was CFS. It's a neat scheduling algorithm.
Java 8 specifically: HashMap is implemented with linked list chaining. This is already not very performant, but you can only do so much with Java being a reference heavy language. RB trees are used if the bucket chain grows excessively long - so it's addressing an edge case, speeding up some worst case scenarios.
Dense hash tables based on open addressing outperform bucketed chaining. Look also at abseil's swiss table or folly's f14 if you want to see how they've further advanced to take advantage of the hardware.
In general: flat, dense, linear structures are king for performance.