
Tell HN: Lois - Golang like channels for Java - mrphoebs
http://flipkart-incubator.github.io/Lois/
======
4ad
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.

~~~
eternalban
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.)

~~~
pron
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](https://github.com/puniverse/quasar)

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

------
koevet
The send/receive paradigm is similar to Actors (Erlang, Akka). What is the
main difference between channels and actors?

~~~
rakoo
Channels live at a lower level. Usually when you create a channel you share it
between multiple goroutines: It acts exactly like a pipe, and are transparent
to what's inside. Moreover, goroutines sending to and receiving from a channel
don't know (and don't need to know) what's on the other end.

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.

~~~
rubiquity
> _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._

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.

------
fauigerzigerk
What's the difference to java.util.concurrent.BlockingQueue?

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

~~~
ap22213
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.

~~~
mrphoebs
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.

~~~
eternalban
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...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7628)

------
baruch
I was also inspired by Go channels and am working on a library in C that
marries fibers, mostly blocking channels and a way to select on the channels.

You can find it in
[http://Github.com/Baruch/libwire](http://Github.com/Baruch/libwire)

------
vishal_biyani
Spring integration project has similar concept of channels and you can use
declarative model to connect channels and components & of course can do much
more. What are any differences if you have context of Spring Integration?

~~~
mrphoebs
I had no idea such a thing existed, will check it out ,thanks. Can't comment
on the differences, sorry.

------
enscr
What's flipkart incubator (the url is "flipkart-incubator.github.io"). I know
flipkart is the Amazon of India.

~~~
mrphoebs
It's flipkart's OpenSource software org on github to incubate projects that
developers drive and graduate them to fully sponsered, flipkart opensource
projects.

