Sometimes you know you need to compute a value before you need to actually use the value. In this case, you can potentially start computing the value on another processor and have it ready when you need it. This is the idea behind futures.
Futures are easy to implement via closures and goroutines. The idea is similar to generators, except a future needs only to return one value.
In the above contrived example, it is known initially that the inverse of both 'a' and 'b' must be computed. Why should the program wait for a_inv to be computed before starting b_inv? These Inverse computations can be done in parallel. On the other hand, the call to Product needs to wait for both a_inv and b_inv to finish. This can be implemented as follows:
In this improved version, the InverseFuture function launches a goroutine to perform the inverse computation and immediately returns a channel which will eventually hold the future value:
The Inverse is computed asynchronously and potentially in parallel.
When developing a computationally intensive package, it may make sense to design the entire API around futures. The futures can be used within your package while maintaining a friendly API. In addition, the futures can be exposed through an asynchronous version of the API. This way the parallelism in your package can be lifted into the user's code with minimal effort:
The above package can be used just as before:
Either way, we've added more parallelism behind the scenes without rewriting the underlying algorithms.