[erlang-questions] Futures/promises and ability to "call" abstract modules

[Fred Hebert]

On 11/19, Garrett Smith wrote:
> 
> From the presentation, the only motivation for "futures" that I can see is this:
> 
> http://monkey.org/~marius/talks/twittersystems/#26
> 
> Here's what's on that slide, entitled "Futures":
> 
> * A placeholder for for a result that is, usually, being computed concurrently
> -- long computations
> -- network call
> -- reading from disk
> * Computations can fail:
> -- connection failure
> -- timeout
> -- div by zero
> * Futures are how we represent concurrent execution.
> 

Based on these requirements, it sounds like a sequence of calls to the
`rpc` module would solve the problem:

    5> MaxTime = rpc:async_call(node(), timer, sleep, [30000]).
    <0.48.0>
    6> lists:sort([a,c,b]).
    [a,b,c]
    7> rpc:yield(MaxTime).
    ... [long wait] ...
    ok

or:

    8> Key2 = rpc:async_call(node(), timer, sleep, [30000]).
    <0.52.0>
    9> rpc:nb_yield(Key2).
    timeout
    12> rpc:nb_yield(Key2, 1000).
    timeout
    13> rpc:nb_yield(Key2, 100000).
    ... [long wait] ...
    {value,ok}

The only part missing is the caching of results for something more or
less read-only. If anything, wrapping around `rpc` calls doesn't sound
all bad for an implementation, especially given it supports multinode
calls and whatnot already.

Regards,
Fred.