[yummyfajitas]

The problem is that by doing this, you have made an operation that should be instantaneous - readLineFuture: () => Future[Line] - into something that now has built in lag.

I.e. you've pulled the side effects (blocking) from the future to the present.

[IpV8]

That built in lag is so incredibly miniscule in the grand scheme of programming that 99.9999% of times it will not matter, and if it does you are using C or Assembly anyways.

[tunesmith]

That argument applies to the example of the abstraction, not the abstraction itself.

[yummyfajitas]

No, readLine will block until a line is available.

Consider a command line IM app using pipes to communicate to the server (just to roll with the readLine example). User 1 has not typed anything, so their file is empty. User 2 has typed a bunch of stuff.

    user1line = readLine "user1file.pipe"
    user2line = readLine "user2file.pipe"
    getFirstAvailableFutureAndProcess [user1line, user2line] processorFunc

What you want this to do is handle whichever user types something first. In reality it will only process user1line.

[gpderetta]

Boost.ASIO (and the corresponding C++ network TR proposal) uses HKTs to select the wait strategy (i.e. coroutines, futures, plain callbacks or whatever the user prefers) with minimal overhead.

[teacup50]

No, it matters. Inefficiency adds up, and CPU cycles you waste on useless overhead aren't available to spend on something that actually matters -- like Garbage Collection.

[colanderman]

It matters a lot if you are relying on asynchronous semantics. You risk deadlock if the request blocks.