[obstinate]

I'm totally on board with futures, IF your application needs to scale to the point that blocking, threaded computation is infeasible. However, I honestly don't think that's the case for most folk. Blocking, direct-call computation is way simpler than futures.

[pron]

Or use fibers (lightweight threads) and enjoy the best of both worlds: simple, blocking code with the scalable performance of async.

[obstinate]

Fibers are fine as an idea. But all the C++ implementations I'm aware of require the programmer to mark up their code for cooperative scheduling. That's a non-starter for me.

[pron]

So writing their code completely differently is a less-costly alternative?

[obstinate]

If I compare the three alternatives:

    - Standard blocking code in OS threads.
    - Future-based code.
    - Coroutines with explicit annotation.

The latter is probably only viable for very large organizations in terms of engineering cost. The other two are doable for smaller organizations.

[pron]

Can you explain why? Futures seem to be much more intrusive than the other two.

[obstinate]

They are intrusive in the sense that the code looks much different. On the other hand, I'd guess they are less error prone. Marking up syscalls would be a constant cognitive load, since you have to remember to do it each time (or else maintain an abstraction layer). But once you've decided to use futures, that's just how you do async.

[dbattaglia]

I think the language and framework are also important in deciding to use them or now. In modern C# with MVC/WebAPI it feels wrong to me to NOT use async/await/Task (the .Net version of Futures and Promises). For fairly little change in coding style you can get some big performance wins on IO code.

[obstinate]

Unless you're writing pretty perf intensive code, part of me doubts you're going to see huge wins on something like async/await.

[wcummings]

Futures model async tasks, there's no reason you couldn't write an executor which uses OS threads using this framework (as they say in the post...)

>we provide a flexible mechanism for explicitly controlling the execution context of callbacks, using a simple Executor interface