5 ms·

Tell HN: Lois - Golang like channels for Java

24 points by mrphoebs 12y ago

koevet 12y ago
The send/receive paradigm is similar to Actors (Erlang, Akka). What is the main difference between channels and actors?
- cronos 12y ago
  This model is called Communicating sequential processes. Comparison between actor model and CSP can be found here http://en.m.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_Actor_Model http://en.m.wikipedia.org/wiki/Communicating_sequential_proc...
- rakoo 12y ago
  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 12y ago
    > 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.
- mrphoebs 12y ago
  The bounded nature of channels tie the communicating processes together more intimately. As a result channels are very good for coordination between processes. Both do a good job of communication between concurrent processes/threads.
- rubiquity 12y ago
  As described by Carl Hewitt, the inventor of the Actor model: - 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-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-... 1 - https://gist.github.com/rbishop/9082539 https://gist.github.com/rbishop/9082539
4ad 12y ago
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.
- mrphoebs 12y ago
  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?
  - dsymonds 12y ago
    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 http://golang.org/ref/spec#Select_statements
    - mrphoebs 12y ago
      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.
- eternalban 12y ago
  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.)
fauigerzigerk 12y ago
What's the difference to java.util.concurrent.BlockingQueue?
- mrphoebs 12y ago
  It's not pass by reference, it's pass by value. And also I like this abstraction better.
  - scotth 12y ago
    Wow. Sounds like some serious overhead.
  - fauigerzigerk 12y ago
    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.
  - ap22213 12y ago
    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 12y ago
      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.
      - 12y ago
vishal_biyani 12y ago
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 12y ago
  I had no idea such a thing existed, will check it out ,thanks. Can't comment on the differences, sorry.
baruch 12y ago
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
enscr 12y ago
What's flipkart incubator (the url is "flipkart-incubator.github.io"). I know flipkart is the Amazon of India.
- mrphoebs 12y ago
  It's flipkart's OpenSource software org on github to incubate projects that developers drive and graduate them to fully sponsered, flipkart opensource projects.

24 points by mrphoebs 12y ago

koevet 12y ago

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

cronos 12y ago
This model is called Communicating sequential processes. Comparison between actor model and CSP can be found here http://en.m.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_Actor_Model http://en.m.wikipedia.org/wiki/Communicating_sequential_proc...
rakoo 12y ago
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 12y ago
  > 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.
mrphoebs 12y ago
The bounded nature of channels tie the communicating processes together more intimately. As a result channels are very good for coordination between processes. Both do a good job of communication between concurrent processes/threads.
rubiquity 12y ago
As described by Carl Hewitt, the inventor of the Actor model: - 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-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-... 1 - https://gist.github.com/rbishop/9082539 https://gist.github.com/rbishop/9082539

4ad 12y ago

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.

mrphoebs 12y ago
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?
- dsymonds 12y ago
  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 http://golang.org/ref/spec#Select_statements
  - mrphoebs 12y ago
    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.
eternalban 12y ago
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.)

fauigerzigerk 12y ago

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

mrphoebs 12y ago
It's not pass by reference, it's pass by value. And also I like this abstraction better.
- scotth 12y ago
  Wow. Sounds like some serious overhead.
- fauigerzigerk 12y ago
  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.
- ap22213 12y ago
  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 12y ago
    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.
    - 12y ago

vishal_biyani 12y ago

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 12y ago
I had no idea such a thing existed, will check it out ,thanks. Can't comment on the differences, sorry.

baruch 12y ago

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

enscr 12y ago

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

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