Looks like @amontalenti managed to find a talk by the author about the book in the comments.

I’m about halfway through right now. I’d recommend it to anyone writing software; it’s like a shorter, more concise version of “Code Complete” but with better examples and with some unconventional wisdom (such as long methods aren’t bad if they encapsulate complex logic from start to finish)

Hey, If you look closely we are using the deferred not as a using mechanism but as a grouping mechanism. The best part about this approach is the late comers. So if your reads are expensive the readers coming towards the end (when Deferred is about to be fulfilled); see lesser latency. To answer your question:

1. The above mentioned scenario is just used as an example, of-course one can use CDN to prevent for this scenario. We have done something similar at places where it was applicable. We use this techniques at various places including identity systems, where putting up such information will be a bad idea.
2. Other coroutines just wait for winning coroutine to complete it’s read. You can have all sort of variations on top of it, e.g. have some sort of timeout and return stale data if scenario permits or start your own DB read. The gist resides in using promises to avoid repeated reads.

Hm, that’s a possibility we haven’t explored yet, thanks for the idea!

However, accessing your voice mail while on roaming costs money, doesn’t it?

Maildir is certainly better than mbox (which is an abomination), but it is still susceptible to the problems outlined in the OP.

Doesn’t thunderbird store messages in a SQLite DB?

Two counter-arguments:

1. When reading commands you’ve written (in a shell script, for example), long opts are much more self-explanatory.
2. Sometimes you need more than 26 flags

Edit with a third: when two common ops occupy the same alphabetical space, such as --version and --verbose.