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