On Mon, Oct 17, 2016 at 5:08 PM adonovan via golang-nuts < golang-nuts@googlegroups.com> wrote:
> > Go does not take a strong Erlang-like stance against concurrency with > shared variables, so mutexes really are critical to Go's concurrency. > > > Even Erlang took a more loose stance towards concurrency with shared variables. You have ETS tables, which acts as tables of M-Vars (in the setting of how such vars work in Id or Haskell). In turn, they act as a way to share data between processes without resorting to message passing. The primary reason is efficiency. An ETS table has sub-microsecond lookup time (because you still need at least two locks in the runtime to grab a value, and then you have to copy it into your own memory space). But it avoids a context switch when you look up. They are used as an in-memory backing store for the mnesia database, among other things, but finds broad use in most Erlang applications. As for the concept of future, I feel it is a crutch. If you have channels, mailboxes or some other concurrency pattern, I've often preferred tailoring a solution to the problem space, rather than trying to get things to work with futures. I'm also skeptic towards its need to be efficient. A long-running computation in the background is often measured in milli-seconds and a channel operates under the 1ms barrier in practice. I'd much rather see some uses of a future primitive where it is applicable and not solvable with a bit of simple channel code, while also being necessary for efficiency reasons. Also note that most broadcast-like patterns are more efficient if the subscribers pull their data. See, for instance, the Disruptor pattern in Java, which would be a nice construction to implement rather than implementing something such as futures (which I feel is a special case of a one-slotted disruptor). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
