It's not pass by reference, it's pass by value. And also I like this abstraction better.

What is a case in which you'd want pass by value in a queue? I mean sometimes you're forced to pass by value, but if you have the option of pass by reference, why would you choose by value?

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.

While I agree it's not hard to make an object safe for concurrency, knowing how to do it effectively is another matter. In an organization or team where there are engineers at all levels of familiarity with java, getting concurrency right is a PITA.

Additionally in this context, the very basis of the channel mechanism is "share state by communicating, don't communicate by sharing state". Also pass by value lends itself well to remoting if I choose to go in that direction.

There is /no/ silver bullet for the complexity of concurrency. If in a large team of uneven experience every developer is expected to address concurrency issues, then the problem is architectural.

> "share state by communicating, don't communicate by sharing state"

The elegance of this approach is very clear. But note that even in Go, when performance is critical, traditional mechanisms of locks and shared memory objects are used. (The fact that such constructs are even provided in the language should be informative to you.)

> [transparent] remoting

I recommend you read this: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7...

Wow. Sounds like some serious overhead.

I see. I'm afraid in a mutable world that causes all kinds of serialization issues and unpredictable performance. Java developers are not used to knowing their object graphs very well.