Futures as a concept are orthogonal to async, they can totally work in explicit threading model.
I disagree with you, my code looks safe and simple with explicit blocking threading, and at the same time is much simpler to reason about what is going on and tune in contrast to async frameworks which hide most of the details under the hood.
You can argue about performance, that async/epoll/etc allows to avoid spawning thousands of threads and remove some overhead, but there is no much benchmarks in internet (per my research) which would say that this performance overhead is large.
Having data affinity to cores is also great for cache hit rates.
Here is part of the C++ runtime this is based on: https://github.com/goto-opensource/asyncly. I was the principal author of it when it was created (before it was open sourced).
it doesn't sound they really sharing data with each other, it looks like your logic is well lineralizable and data localized, and you can't implement access to some global hashmap in that way for example.
> Try that with tens of thousands of actual OS threads and the associated scheduling overhead.
I run this(10k threads blocked by DB access) in prod and it works fine for my needs. There are lots of statements in internet about overhead, but not much benchmarks how large this overhead is.
> Here is part of the C++ runtime this is based on
yeah, I need one runtime on top of another runtime, with unknown quality, support, longevity and number of gotchas.
Yes, because data can have thread affinity. Data doesn't need to be shared by _all _ connections, just by a few hundred/thousand. This enables connections to be scheduled to run on the same thread so that they can share data without synchronization.
> I run this(10k threads blocked by DB access) in prod and it works fine for my needs. There are lots of statements in internet about overhead, but not much benchmarks how large this overhead is.
The underlying problem is old and well researched: https://en.wikipedia.org/wiki/C10k_problem
data doesn't need to be shared in your specific case, not in general.
> The underlying problem is old and well researched: https://en.wikipedia.org/wiki/C10k_problem
wiki page doesn't mean it is well researched, where can I see results of overhead measurements on modern hardware?
Here is how this works: at the bottom of the wiki page, there are referenced papers. They contain measurements in modern hardware. You read those, then perhaps go to Google and see if there is any newer research that cites those papers.
If you don't feel like reading papers, HN has a search bar at the bottom that yields a wealth of results: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Maybe you should just take a college computer architecture course along the lines of Hennessy/Patterson. This is nothing new, I learned much of this in college 15 years ago. The problem has only gotten worse since then, computers have not become more single threaded.
> The problem has only gotten worse since then, computers have not become more single threaded.
Computers are now can handle 10k blocking connections with ease.
It's a library. It solved our problems at the time, years ago. It's still used in production and piping billions of audio minutes per month through it. You don't have to use it, I merely referred to it as an example. A similar library is proposed to be included in C++23: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p23...
there are tons of overengineered unmaintainable code in prod, it doesn't mean I need to follow them as example without much justification.
> A similar library is proposed to be included in C++23
hm, I went through the code example, and would prefer my current approach as a much simpler and readable.
I've (ab)used them that way, without any async runtime, just to easily write stateful iterators.
In Java, Future.get() blocks current thread, and it is trivially integrated into explicit threading programming. In Rust, Future.poll() is not blocking, and one would need to rely on some async framework, or build own event loop which can potentially block thread.
You can spawn your tasks, store the JoinHandle "futures", and wait for completion whenever you need the result.
A difference being that Futures do nothing until polled, while threads start on their own, but that's arguably a helpful simplification for this purpose.
but instead I start a future, and then to run it at all I need to wait for the result. I understand the there are tools to effect this, but it really leaves you wondering - what did I just do? start an async task and then .. block on it in order to get it to execute?
In JavaScript terms Futures are more like sugar around callbacks, they don't do anything until you call/poll them. Tasks are independent entities like Promises which are being run by the executor, though they may currently be blocked on other tasks.
> the model I often want is I want to start some work, and then join at some later point - or even chain directly into the next task.
Rust wants you to do this the other way around. First chain together your futures so that when you start the top level one as a task there is a single state machine for it to run.