Futures in Go

Futures are not necessary in Go, since they are a hack around not having the concurrency that Go supports natively. This is why the Go community never talks about "futures"... as in this example, they are a regression vs. the already-supported primitives, not progress. Channels are already a more general, more powerful, and most importantly, more composable version of the "futures" idea that is what most people consider "futures". (I caveat this just because there are many such ideas which have different characteristics, but it's not exactly what the JS community means by the term, for instance.)

You should return a chan. In this case, all crawlers should be returning along the same chan, errors or results, rather than creating one per request. Then you A: don't have a problem where you could be processing result #5 but result #3 is blocking right now, increasing the total latency, B: having multiple consumers using the same channel is trivial and at the user's discretion, and C: the resulting chan can participate in a "select" of the user's choosing, unlike a function call. There is no way in which using this approach is superior to using a chan.

If you look at the wikipedia page for "futures", which has a lot more than just any one community's idea of "futures" in it, you can see that a channel that you expect to read one value from is, if not necessarily exactly any one of the given definitions, certainly a family member. It isn't in the type system, but it is still the case that if you have a need for a "future" in Go you're better off with a chan with that constraint documented, rather than returning a function that can be called, because of the inability to select on such a function. http://en.wikipedia.org/wiki/Futures_and_promises

This isn't a Future. A real Future would allow multiple goroutines to block waiting for the value to arrive. When it arrives, all the goroutines wake up.

In Go, each value on a channel goes to a single reader and it's rare to need multiple readers. One way to do it might be to return a channel that receives an infinite stream of the same value.

I haven't looked closely at the original post, but there are a few semantics that are useful for promises that current channels don't have (I'm more familiar with core.async than go). Clojure is working on promise channels: https://t.co/Z3TQbQMnRb

I'm not sure that's the case. Erlang has public-addressable processes: you can pass a process's handle around, and then anything with that handle can direct messages to that process—including messages containing their own process handles, allowing for responses; built on top of this, there's a global service registry, allowing anything to direct messages to a given process. Despite this, Erlang still doesn't need futures/promises.

Generally, futures/promises just solve the problem of how to simulate blocking within an event-loop-driven (i.e. cooperatively-scheduled) platform, e.g. Node. When actor-processes are cheap, your consumer can be an actor which just actually blocks on a result—and then continues execution in the same linear block of code when that result arrives.

To put it another way: in non-actor languages, you'd see a block of code like this...

    do_random_other_work();
    bfn_args = some_setup();
    blocking_fn(bfn_args).then(function(result) {
      console.log(result);
    });
    more_random_other_work();
      

...while in actor-modelled languages, it'd go more like this:

    do_random_other_work();
    spawn(function() {
      bfn_args = some_setup();
      result = blocking_fn(bfn_args);
      console.log(result);
    });
    more_random_other_work();

Note how you have a closure in both cases, but they contain different parts of the code. The actor-modelled closure contains the setup work of sending the message, as well as the work of dealing with the reply—which must be linear with respect to one-another, but which can all happen concurrently to the random other work.

As well, notice that the actor-modelled version of blocking_fn is actually a plain old blocking function—a synchronous-IO read, for example. The blocking_fn in the promise-modelled code, on the other hand, is a special function which must be defined using a promises library, and must do the work of ensuring its asynchronicity at definition-time, whether or not a given consumer wants to call the function in an async way relative to its own thread of execution.

In short, idiomatic actor-modelled code puts the consuming programmer in control of which tasks are linear and which are concurrent, which usually makes for succinct, reusable plainly-synchronous functions that Get Things Done, and higher-level glue code that represents all the policy of what concurrency happens where. Promises throw out all these advantages and mix policy with mechanism in a way that increases verbosity and decreases reusability.