On 17 October 2016 at 12:31, Sokolov Yura <funny.fal...@gmail.com> wrote:
> понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь
> adon...@google.com написал:
>> Go does not take a strong Erlang-like stance against concurrency with
>> shared variables, so mutexes really are critical to Go's concurrency.
> Am I mistaken? Golang authors said mutexes are second class citizens.
> They'd prefer not to expose them, but unfortunately, channels are not fast
> enough for some use-cases.
Well, it's true that mutexes can be implemented in terms of channels,
albeit with some loss of efficiency in practice, so in that sense I suppose
you could describe them as second class. But it doesn't change the
fundamentals: unlike Erlang, Go has always supported mutable variables
concurrently accessible by multiple goroutines, and I've never heard anyone
in the Go community wish it were otherwise.
Your code also misses the case when concurrently running goroutines wish to
> fill same future.
That is true, but it's an advanced feature not needed by most users of
Futures. You can of course add it at the cost of a few extra lines of
code. Recall my stack analogy: for most users, it's not worth defining a
new Stack type; a slice will do. But some may want more advanced stack
features and then using a library package might be worth the cost (of
> Most uses of reflect package doesn't bother with synchronization
> primitives. They only detects structs, strings, maps and slices, and
> ignores rest.
> Most of such code will not be broken.
A great many programs have a "switch v.Kind()" and a case for every
reflect.Kind. All such programs would be broken by your change. If for no
other reason, this means we cannot add Futures to the language because we
have guaranteed not to break any valid Go 1.x program.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.