This sounds like running an event loop per thread instead of 1 event loop with a backing thread pool. Or am I misunderstanding you?
It works great for small tasks but larger tasks block local events and you can get weird latency issues, that was the major tradeoff I ran into when I used it. Works great if your tasks are tiny though, not having the event loop handoff to the worker thread is a good throughput boost. But then we started having latency issues and we introduced larger tasks which would hang the local event loop from getting those events.
I think Scylladb works somewhat like this but does message passing to put certain data on certain threads so any thread can handle incoming events but it still moves the request to the pinned thread the data lives on. One thread can get overwhelmed if your data isn't well distributed.
Been using valkey streams recently and loving it. Took a bit to understand how to to properly use it but now that I've figured it out I'd highly recommend trying it. It's very easy to setup and get going and just works.
Note that items declared as `static` in Rust are already globals that require synchronization (in Rust terms, static items must implement `Sync`), although they're located in static memory rather than on the stack or heap.
reminds me of the classic https://xkcd.com/927/ not exactly identical to Bjarne's quote but similar.
I'm quite familiar with C++ as well and this just jives so much, each standard is just almost exponentially more complicated than the last, and while there are good changes they don't necessarily fit well with the prior version and its just a mess, I still maintain two OSS libs but I don't use the language anymore.. so its a question of how long I put up with it at this point.
Rust is such a breathe of fresh air coming from c++11/14/17/20 but its still a behemoth if you don't know the entire thing, I think this article is pretty spot on with that.
Everything is silly, and consensus reality on these kind of things is just a glorified Reddit thread IRL. There's at least four plausible metrics. Everest is tallest from the local mean sea level (the smoothed gravitational equipotential—what a stationary water surface hugs); McKinley-Denali from its local terrain base; Mauna Kea from the local terrain base inclusive of underwater terrain; and Chimborazo, in equatorial Ecuador (it's Ecuador because it's equatorial), as measured from this planet's center-of-mass (the planet bulges out approaching the equator because of its spinning—"oblateness").
Like a Reddit thread, it's best not to argue too much with what the hive-mind decides. People literally died climbing what they believed to be the correct answer. Let them have their thing. :)
Following up on your pedantism: Chimborazo isn't in Ecuador because it's equatorial, but rather, it's equatorial because it's in Ecuador.
(Or, perhaps, because it lies near or on the equator.)
There are non-Ecuadorian equatorial locations.
:-)
(I do like, appreciate, and was previously aware of the various claims to "highest mountain". Interesting also to contemplate that the early Rockies, and perhaps Appalachian mountains (themselves older than dirt, literally), may once have exceeded thirty thousand feet (approaching 10,000 m). Though the Rockies figure might be an ambitious reading of the Teton Fault having experienced 20,000 -- 30,000 feet of vertical displacement. This is possible without peaks reaching such heights, given erosion. Estimates of the original height of the Appalachians is even more tenuous and indirect.)
Enjoyed your clear description but I don't know that framing it as some kind of hive mind group think issue is that accurate. It's just taxonomy and ontology, it's ok to have different taxonomies for different contexts. The same issue exists for everything. planets, temperature, oceans, species..
What is being called hive mind, that used to be called cargo cult, is a real thing on HN, though.
There’s this fantasy that there are a bunch of geniuses that can adequately cover any topic here and that discussion will be inclusive and enlightening, but, no, it’s just a frustrating cauldron of wannabes and bad info that periodically hit upon things.
Hive mind, cargo cult, and a third phenomena, groupthink, are somewhat related but probably more usefully considered as distinct.
A hive mind in its original form is a form of emergent intelligence most especially associated with social insects (e.g., ants, bees, and termites), where collective behavioural patterns emerge which are independent of, and not fully explained by, any individual behaviours or intelligence. The term is of course also applied to humans, perhaps most famously as "the madness of crowds", as popularised by the book of the same title.
Groupthink, to skip over cargo cults for a moment, is a case where individual beliefs and/or behaviours are influenced by a group, often as an otherwise poorly-substantiated set of beliefs or actions, usually in agreement with some leader. Why groupthink emerges and what possible social/psychological evolutionary advantages it might convey (compensating for the cost of beliefs at odds with reality and empirical evidence) are hotly debated. Unlike the hive mind, groupthink isn't emergent, in the sense that individuals express specific beliefs or exhibit specific behaviours, though generally associated with the group context.
Cargo-cults are a form of groupthink. My own view is that cargo cults emerge in response to highly complex phenomena, either entirely beyond the grasp of individuals, or pushing the limits of scientific or technical knowledge. The original form, emerging on Pacific islands during and following WWII were a case of a non-technological culture (the native island inhabitants) trying to attain the benefits of a technological society (the various military belligerants of WWII) by emulating airstrips and the hope of the cargo (goods and services) these apparently brought the advanced society. Air-borne transport is knowable by humans, but only in a given social-technological context, which the islanders lacked.
In other instances, cargo culting tends to resemble fads and fashions where indicia or characteristics of some complex concept are adhered to, sometimes to achieve their ends, sometimes to indicate adherence to or alignment with a group. Fashion, language, dress, management trends, and software development practices (3GL, structured code, Agile, ML, and the like may all be examples in at least some cases). Often the foundations are more than purely technical, e.g., management or investors may feel a need to follow the crowd / leaders, often to avoid scapegoating or accountability in the event of failure.
All of which of course is distinct from the false-competence delusion of an expert within one domain presuming expertise in others, e.g., Nobel Disease <https://en.wikipedia.org/wiki/Nobel_disease>.
Shout out to Chimborazo, where the summit is (likely) furthest from the center of the Earth. (I understand Huascarán is in contention, and don't know the latest details.)
It feels like it makes a bit more sense with Mauna Kea, since Big Island is just five shield volcanoes in a trenchcoat, and the point where the land meets the ocean is basically just the foothills of the mountains. You cannot say that of Everest, which is over 400 miles from the nearest ocean.
It's an interesting idea, but reactive, and could cause big delays due to bisecting and testing on those regressions. There's the 'old' saying that the sooner the bug is found the cheaper it is to fix, seems weird to intentionally push finding side effect bugs later in the process because faster CI runs. Maybe AI will get there but it seems too aggressive right now to me. But yeah, put the automation slider where you're comfortable.
It's a decent idea, but it's weird reviewing code you wrote in saying GitHub, it looks totally different. Imo not a show stopper but a side effect you have to get used to.
We interestingly ran into issues with actix and the AWS lb. The lb takes some liberty with how it handled connections and actix seems to be "to the spec" so we were seeing a lot of dropped connections. Placing nginx between the two resolved the issue but it's fairly disappointing that we need that layer when it should be unnecessary overhead. I'd love to give axum a try if we could find time and see if it behaves better.
> Interesting, I'm curious about the details here. Does the lb reuse connections for multiple requests or something?
I'm curious too. There must be more to it than that because LBs reusing backhaul connections is standard practice. It's not only an optimization but in many cases you'll quickly hit ephemeral port exhaustion if you don't. TCP connections are distinguished by (src_ip, src_port, dst_ip, dst_port) tuple. For this leg you're probably only varying the src_port portion, and all of the valid options are cooling in time_wait state.
It works great for small tasks but larger tasks block local events and you can get weird latency issues, that was the major tradeoff I ran into when I used it. Works great if your tasks are tiny though, not having the event loop handoff to the worker thread is a good throughput boost. But then we started having latency issues and we introduced larger tasks which would hang the local event loop from getting those events.
I think Scylladb works somewhat like this but does message passing to put certain data on certain threads so any thread can handle incoming events but it still moves the request to the pinned thread the data lives on. One thread can get overwhelmed if your data isn't well distributed.
reply