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 <i>regression</i> 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.)<p>You <i>should</i> 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.<p>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. <a href="http://en.wikipedia.org/wiki/Futures_and_promises" rel="nofollow">http://en.wikipedia.org/wiki/Futures_and_promises</a>
Note that when designing servers at Google in Go, we strongly discourage the use of concepts like futures and promises. They exist as abstractions that work around heavyweight threads. In Go, you have lightweight threads which remove the need for futures.<p>Create a new goroutine and block on the action. You can continue working in another goroutine and communicate between them using channels.<p>The advantage of this programming model over futures/promises is straight-line code that is easier to read and reason about. For example, when bugs appear you get a nice stack trace that reveals the state of the call. Future leave you in a callback-like mess.<p>See <a href="http://blog.golang.org/pipelines" rel="nofollow">http://blog.golang.org/pipelines</a> for more details.
This error pops up for me:<p><pre><code> This site or app is sending too much traffic to
rawgit.com. Please contact its owner and ask them to use
cdn.rawgit.com instead, which has no traffic limit.</code></pre>
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.<p>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.
This is terrible. Each result blocks in the first example (e.g. if the first url in the array returns in 3s and the second url returns in 3ms - the routine will wait 3s then deal with both instead of dealing with the 3ms result immediately it returns).
The second example blocks until all the results are in. This might be want you want, but if so then you might as well run them serially. The advantage of concurrency is that it can deal with the results as they come in.<p>The correct way to do this is to return results on a chan of (error, response) regardless of how much you "don't like it" for unspecified reasons.
<p><pre><code> var (
ch = make(chan *http.Response)
err error
)
....
return func() (*http.Response, error) {
return <-ch, err
}
</code></pre>
It seems to me like calling that returned function is destructive -- if you block on it more than one, it would block forever. Is that right? It seems like a different contract than the usual Future / Promise shtick.