Go's core philosophy for concurrency is: Do not communicate by sharing memory; instead, share memory by communicating [1]. I have not tried to share memory (ex:

Go's core philosophy for concurrency is: Do not communicate by sharing memory; instead, share memory by communicating [1]. I have not tried to share memory (ex: a pointer-to-struct) between two different go threads before, so I can't really comment on what happens when one tries to break out of the language's philosophy. However, I've found that following the philosophy is incredibly liberating as it encourages a certain kind of reasoning that gives me the confidence I can accurately statically analyze the code without having to debug it at run time. Like any other philosophy though, it isn't for everyone. EDIT: I now realize I never addressed your concern of primitives. Go really only has one: the channel. It can send anything (even other channels). The two types are buffered or unbuffered, and deciding which to use can alter the behavior of a program. There are a few language keywords to support the use of channels, such as `for-select-case` loops and `go` to spawn new goroutines. The former is used to help respond to numerous channels, the latter to spawn more goroutines. Nothing in the language prevents listening to a runtime-determined arbitrary number of channels, either. [1] http://blog.golang.org/share-memory-by-communicating http://blog.golang.org/share-memory-by-communicating