i think that if someone is really interested in this topic, they'd do well to read mark s. miller's doctoral dissertation on it, 'robust composition': http://www.erights.org/talks/thesis/

this is relevant because miller explains why he designed promises the way he did, although since he wrote the dissertation in 02006, he couldn't yet explain how he adapted them for incorporation into the javascript standard. following his dissertation, he was on the ecmascript committee for a number of years, which is how we got e-style promises in javascript, although obviously that also involved the committee as a whole being convinced that they were a good idea. (much of the dissertation is actually about object-capability security, but chapters 13–19 are about promises.)

the great benefit of promises is that you eliminate data races, where one procedure is correct only if a particular piece of mutable data remains unchanged, while another concurrently runnable procedure changes it, so the interleaving of their accesses can result in a failure. consequently, you don't need locks or queues to communicate between different concurrent procedures; you can just use a shared data structure with no locking. this is because promises are an alternative to threads. if you're familiar with async rust, you will note three glaring problems with this:

1. rust eliminates data races through the type system, so the great benefit of promises doesn't exist in this context

2. tokio runs multiple tasks concurrently, so if you do have data races, promises won't save you

3. so you do in fact use channels and locks in async rust

so i am puzzled about why you would ever want to use promises in rust, and i guess this post is an attempt to answer that question. it explains why people have this bizarre misconception that promises are just an efficiency hack, because in rust that's all they are, and those people have never used promises in javascript or e or the other children of e such as spritely goblins.

this bears repeating. before reading this post i didn't realize this, but rust async/await is just an efficiency hack. even the section of this post entitled 'i don't want fast threads, i want futures' never brings up, as far as i can tell, any correctness or flexibility advantages for async rust, only efficiency advantages ('to multiplex arbitrarily many perfectly-sized tasks on a single thread', 'much better performance characteristics' etc.) there's brief lip service to concision ('concurrency-related boilerplate about spawning threads', which i don't think actually exists) before returning to the main theme of performance. then it proposes some truly astoundingly terrible ideas about automatically introducing race conditions if you await with a lock held, in the name of being 'even more optimal', at which point we're well into 'mongodb is web scale. if /dev/null is web scale i will use it' territory

a terminological quibble: i wish people wouldn't refer to promises as 'futures'; a future is, or anyway originally was, a different approach to the concurrency problem, one where reading from a perfectly normal variable would block your thread until that variable's value had been computed (allowing other threads to run). this approach does not have the advantages of promises. promises are what async rust implemented, just under the name of 'futures'. really, though, confusing terminology seems to be the least of the problems with rust's implementation of the paradigm