Phil Derome (48) [Avatar] Offline
#1
Listing 6.7 defines 3 Futures ahead of executing them (ccyPF, eqtPF, fixPF), which is good. The creation of the CustomerPorfolio simply assembles the resulting values (sequences of Balance). The for comprehension uses the monadic property of Futures but it seems that even though execution is done in parallel (prior to the for comprehension), it is a bit poor style in that we could do a Future.sequence instead, which encourages developer to think of combining the results of Futures in no particular order. Using a for comprehension is a potentially risky invitation to code the calls to obtain the Future in the for comprehension rather than prior. The author acknowledges that Future does not separate the description of the computation and execution in side bar on page 194 and that seems to be my issue here with the usage of for comprehension.

The Listing 6.8 that uses Task.gatherUnordered (and later r.run.foldleft) would parallel well with a Future.sequence (for example as Travis Brown mentions in Stackoverflow: https://stackoverflow.com/questions/29344430/scala-waiting-for-sequence-of-futures)

So my takeaway is that it seems better to advocate using Future.sequence than for comprehensions on the Futures.

Same question arises in the discussion of combining Futures outcomes with actors on page 209 where for comprehensions are used over two futures.
Debasish Ghosh (116) [Avatar] Offline
#2
The issue with Future.sequence is that it returns a Failure if any of the futures fail. That may not be what you want in many use cases. For a slightly different technique to start futures in parallel still using for-comprehensions, see this tip (http://viktorklang.com/blog/Futures-in-Scala-proips-2.html) from Viktor.
Phil Derome (48) [Avatar] Offline
#3
Subtle and useful, and thanks for the link (http://viktorklang.com/blog/Futures-in-Scala-protips-2.html)