[hdevalence]

A lot of discussion about async Rust assumes that the reason one would want to use async/Futures is for performance and scalability reasons.

Personally, though, I would strongly prefer to use async rather than explicit threading even for cases where performance wasn’t the highest priority. The conceptual model is just better. Futures allow you to cleanly express composition of sub-tasks in a way that explicit threading doesn’t:

https://monkey.org/~marius/futures-arent-ersatz-threads.html

[ori_b]

Futures are nicely equivalent to one shot channels with threads.

[pornel]

Not quite: Rust futures also have immediate cancellation and easy timeouts that can be imposed externally on any future.

In threads that perform blocking I/O you don't get that, and need to support timeouts and cancellation explicitly in every blocking call.

[littlestymaar]

With a nice syntax sugar on top, but yeah pretty much.

[riku_iki]

Futures as a concept are orthogonal to async, they can totally work in explicit threading model.

[jupp0r]

They can be used that way, but you end up with exactly the same problems that async programming aims to avoid (performance, deadlocks, your business logic being cluttered with low level implementation details).

[riku_iki]

> that async programming aims to avoid (performance, deadlocks, your business logic being cluttered with low level implementation details).

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.

[jupp0r]

If you are using explicit blocking, share data between threads and have not run into deadlocks then your application is trivial (which is great if it solves your problem).

[riku_iki]

Could you explain how sharing data between threads is different in async programming and blocking programming?

[jupp0r]

You can minimize sharing data between threads because it's easier to have data affinity with threads (ie only thread A will read or write to a piece of data). You can still access that data from multiple modules because the whole thread is never blocked waiting for IO (because of async). An extreme example is nodejs, where you only have one thread, can concurrently do thousands of things and never have to coordinate (ie via mutexes) data access.

[pornel]

At the lowest level Rust's async is a syntax for generators (yield).

I've (ab)used them that way, without any async runtime, just to easily write stateful iterators.

[_ahxg]

Do you know an example of such case in the Rust ecosystem?

[riku_iki]

No, I don't know, I am talking about general concept.

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.

[tux3]

It's worth noting that a thread's JoinHandle provides a similar interface.

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.

[convolvatron]

this I really found disconcerting - 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.

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?

[laurencerowe]

I'm not an expert, but my understanding is that Rust makes a distinction between Futures and Tasks, the top level Futures that are run by the executor.

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.