[skybrian]

I think that explains why languages like JavaScript will have many functions that return Promises and Go doesn't need that kind of API. Often in JavaScript, there will only be one reader for the result of a function call, but you'll use a Promise anyway since there are no threads.

But there are cases where you really want multiple readers. For example, on a cache miss, you want a single goroutine to do the work to fill the cache, but there may be multiple goroutines waiting on the result. In this case it might seem natural to model the cache internally as a map from keys to futures, even if it's not exposed?