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.)
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).
- CSP uses named channels (coincidentally called channels in Go) with anonymous processes (goroutines in Go)
- Actors are anonymous channels (mailbox addresses) with named processes (actors).
Carl Hewitt states that CSP was created to create a concurrency model around algebra and having named channels was the only way to accomplish that due to the constraints of algebra.
The Actor model's foundation is in physics. Here's an excellent video of Carl Hewitt giving an off the cuff explanation of the Actor Model[0], and some notes I took while watching it[1] (please add more notes if you can, I get confused about this topic constantly).
Another important note is that there are many different implementations of CSP but only one implementation of the Actor model.
0 - http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-...
Actors are more like a combination of a channel and a goroutine: when you send something to the actor, you know what the other end is and you know what it does with messages.
Actors induce a certain paradigm for your application, and I believe Go just wants to give you the tool to build whatever you want. Having channels allows using the Actor paradigm, the other way is not as easy/lightweight.
I don't think this is the case at all. When sending a message to an address you don't know how many actors are behind that address, and even further you don't know how many addresses an actor has. Actors and addresses have a many-to-many relationship.
I think the power of the Actor model is essentially putting your faith in the system and not caring about when messages get handled, or what order they get handled in - it's just knowing that the message will get handled.
Maybe I've been doing this stuff too long, but it's not all that hard to make an object safe for concurrency. But, I am probably missing some context.
You can find it in http://Github.com/Baruch/libwire
