понедельник, 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.

> This is really a special case of the argument for generics in Go.
> Futures are to channels and stacks are to slices.  With generics, you 
> could provide first-class Future<T> and Stack<T>, but without generics it's 
> simply not worth the effort for most users to bother with the abstraction 
> since it can be written in little more than a dozen lines of code:  
> https://play.golang.org/p/Obqag2hgZe  It's just easier to implement the 
> underlying operations directly.

Your code also misses the case when concurrently running goroutines wish to 
fill same future.
That is why I think it should be at least in standard library, but better 
in a language: it should be reliable, and not error-prone.

> Adding a new data type is not a small change to the language.  It requires 
> changes to the spec, the compiler, the reflect package, every program that 
> uses the reflect package, every tool that manipulates Go source code, and 
> many other things too.  The only types that currently enjoy special status 
> in the type system are slice, map, channel and a small number of others, 
> all of which are very widely used.

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.

But I agree with you (or better said: you caught me): I cheated a bit when 
were talking about amount of changes.
That is bonus point for you, cause you first who said about it.

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.

Reply via email to