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

[Garrett Smith]

On Mon, Nov 19, 2012 at 4:32 AM, Gleb Peregud <gleber.p@REDACTED> wrote:
> Hello
>
> Last evening I was trying to implement futures/promise mechanism in Erlang
> (mostly for fun, since I am still unsure if it is useful). I got inspired
> with the presentation [1], which mentioned using futures as a foundation of
> building services, where things like timeouts, tracing, authentication, etc.
> is built by composing futures (see slide 41).
>
> Do you think that such composition of futures could be useful as a tool to
> improve code reuse of communication patterns in Erlang (as described in the
> presentation)?

>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.

I don't see anywhere a problem here, unless you're unhappy with
threads and want to use some "async" library that requires the use of
callbacks, or this futures thing.

Of course that's why you'd use Erlang.

As it turns out, all of this is handled rather elegantly by Erlang's
concurrency model, which uses processes and message passing.

It might be an interesting exercise to figure out how GC works in
under a particular use case, but from the list above, it's unclear
what problems you're trying to solve in Erlang.

Garrett