This (and pretty much all the other libraries) misses the point of Go/CSP channels completely. The select/alt statement. Channels are just queues. Queues are useful in any language. The power and ease of use of Go concurrency primitives don't come from channels and goroutines, it comes from the select statement.
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).
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
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
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.
Comments
This (and pretty much all the other libraries) misses the point of Go/CSP channels completely. The select/alt statement. Channels are just queues. Queues are useful in any language. The power and ease of use of Go concurrency primitives don't come from channels and goroutines, it comes from the select statement.
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.