Do you know an example of such case in the Rust ecosystem?
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.