The phrase "concurrency patterns" tells me we are not yet talking about the concurrency-oriented language of the future. This is in the sense that patterns usua

The phrase "concurrency patterns" tells me we are not yet talking about the concurrency-oriented language of the future. This is in the sense that patterns usually deal with the weak spots of the language, and lo, we must build weird constructs like doing fanout (not relevant to the original problem.) Go isn't alone here, in fact I see it every time someone thinks: "Erlang is nice, but gee, PIDs are so darn crude." In my mind, a language that makes concurrency the real priority (and I don't mean to say Go, Rust, et al. shouldn't be tempered by other concerns) will not require intermediate patterns to map the problem to the code. In other words, something close to a 1:1 correspondence should exist between problem concurrency and language support, including the nature of communications. I'd like to draw a comparison to memory management in C. It's a far simpler problem, but it's easy to illustrate that we don't (normally) need "allocation patterns" that go beyond the problem of memory needs. You can sum it up: "If you need memory, allocate it. Free it when you are done." The rules are simple and the advanced memory allocation techniques aren't required to map to the problem.