11–15 of 15 posts
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.This error pops up for me: 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.
Earlier quoted context omitted.
I don't think I've ever heard it clearly explained why you rarely need futures in Go. (The blog article doesn't explain it either.) It seems to be because each goroutine has a single parent (which launched it), so there is typically a single reader for its return value.
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 fut…
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?
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 consi…
Earlier quoted context omitted.
I don't think I've ever heard it clearly explained why you rarely need futures in Go. (The blog article doesn't explain it either.) It seems to be because each goroutine has a single parent (which launched it), so there is typically a single reader for its return value.
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 fut…
The way to do it would be closer to something like that:
do_random_other_work();
actor = spawn(function() {
bfn_args = some_setup();
result = blocking_fn(bfn_args);
emit(result);
});
result = wait_for_result(actor)
more_random_other_work(result);