7 ms·

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

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 11y ago
Or use fibers (lightweight threads) and enjoy the best of both worlds: simple, blocking code with the scalable performance of async.
- obstinate 11y ago
  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 11y ago
    So writing their code completely differently is a less-costly alternative?
    - obstinate 11y ago
      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 11y ago
        Can you explain why? Futures seem to be much more intrusive than the other two.
        obstinate 11y ago
        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 11y ago
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 11y ago
  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 11y ago
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

pron 11y ago

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

obstinate 11y ago
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 11y ago
  So writing their code completely differently is a less-costly alternative?
  - obstinate 11y ago
    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 11y ago
      Can you explain why? Futures seem to be much more intrusive than the other two.
      - obstinate 11y ago
        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 11y ago

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 11y ago
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 11y ago

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