There is no "Go Concurrency Pattern" (singular). The article demonstrates some ways to use Go's concurrency primitives.

Obviously there is a massive syntactic difference between your Java example and the equivalent Go code, but the other major difference that jumps out at me is that cancellation is baked into the Java library, whereas in Go the programmer determines how each of their pipeline stages should be shut down.

> Obviously there is a massive syntactic difference between your Java example and the equivalent Go code

With Java 8 and lambdas, syntax will be much cleaner, i.e. you can write something like: executor.execute(() -> "step1");

To me, the major difference is that the Java solution gives you one solution. The Go solutions gives you the building blocks.

The latter has the advantage you get to recompose the system in new ways, yielding greater flexibility.

In Java, a better compositional framework is probably Erik Meijer's et.al's RxJava. Haskell also provides better compositionality due to it's functional structure and lazy evaluation semantics.

I guess an obvious difference is that Go has these stuff built into runtime and syntax, which makes those light-weight threads / tasks a first class thing.

Furthermore, is there a way in "Java SingleThreadExecutor" and its related components that allow automatic scheduling tasks on different threads? For example, you are on a quad-core and you want to have 4 threads running together, with millions of tasks mapped to 4 threads and dynamically balanced.

I believe that's what the ForkJoinPool is for.

http://docs.oracle.com/javase/7/docs/api/java/util/concurren...

Sure, you can replace SingleThreadExecutor by Executors.newFixedThreadPool(4)

I think one huge difference is that a channel in Go is a stream of data, in which each element can cause the consuming code to wait for new responses. In your example, the future can only return one bit of data.

Afaik, what Go does is just an implementation of http://en.wikipedia.org/wiki/Communicating_sequential_proces... which is also available in some other languages (Clojure is the one that comes to mind for me). In Java, I think a closer analogy is a http://docs.oracle.com/javase/7/docs/api/java/util/concurren... which lets the producer and consumer threads automatically work in lock step as well.

> I think one huge difference is that a channel in Go is a stream of data, in which each element can cause the consuming code to wait for new responses. In your example, the future can only return one bit of data.

In java you also can do something like:

List<Future<Long>> futures = new ArrayList<>();

for(int i = 0; i < n; i ++) futures.add(some parallel execution logic);

long count = 0;

for(Future<Long> f: futures) count += f.get();

I think the main difference is the way the language and runtime collaborate to schedule multiple events. Note the use of the 'select...case' in the example code.

These slides go into some more examples: http://talks.golang.org/2013/advconc.slide

You end up with a really nice "actor model", where you have a goro which owns some state responding to incoming messages over channels and sending replies.

Slide 24 gives the general structure, but it's a good read.