Go is not really CSP anymore. The scheduler pre-empts.

You're right regarding this (pointless?) wrapper around Doug Lea's queues. If the OP really wants the kudos for doing CSP on Java, s/he'll need to tame the NIO selectors and no doubt sprinkle a little ASM magic dust on it as well.

Closest thing we have is Kilim (which is just simply awesome.)

Actually, the closest we've got is Quasar[1] (I'm the main author). It's got true lightweight threads (goroutines), as well as selectable channels. On top, it's got actors, complete with selective receives and hot code-swapping.

It is much more actively maintained than Kilim, more general, and has better performance to boot. Also, Quasar fibers interoperate very nicely with plain threads. Blocking operations (such as channel receive) block the thread if you're running in a plain thread, and the fiber if you're running in a fiber.

In fact, we've even had time-sliced preemptive scheduling, which we've taken out because it didn't give performance benefits to fibers that block a lot, and for computations that don't, there's full blown threads (which Go doesn't have).

[1]: https://github.com/puniverse/quasar

Thanks, I remember reading the pulsar blog post a while ago. Couldn't recall the name.

I found Kilim to be an overkill for the most of my use cases. Instead I recommend checking out jetlang, https://code.google.com/p/jetlang/.) ( This implements message based concurrency, similar to Scala. I am using this in production code without any issues.I found this easier to implement than Kilim and delivers equivalent functionality

Didn't know about this one. Will definitely check out it.

For those who haven't seen Kilim:

http://www.malhar.net/sriram/kilim/

https://github.com/kilim/kilim

I'm not an expert at Go but what is the power that select gives. Don't higher order channel structures like multiplexing achieve something similar. Can you throw more light on this?

The 'select' statement does more than just multiplex (and it doesn't really multiplex since you can't do it over a slice of channels). It allows blocking on any one of a set of send or receive operations. This is similar to the select(2) system call in BSD

Spec: http://golang.org/ref/spec#Select_statements

Thanks, the analogy to the system call helps heaps in my understanding of the intent. It's value wasn't clear to me when I was debating it's inclusion in the library. I'll have a deeper look and see how best I can include something similar in the library. Sadly, I doubt the interface for it would be as elegant as the one Go has.