6 ms·

The ClojureScript support needs work but you can already express some incredible things, those familiar with channels in Go should be dropping their jaws that y

The ClojureScript support needs work but you can already express some incredible things, those familiar with channels in Go should be dropping their jaws that you can do this in the browser: http://gist.github.com/swannodette/5886048 http://gist.github.com/swannodette/5886048 With timeout channels, the throttler is a beautiful 7 lines of clear code - compare to the Underscore.js imperative mess: http://underscorejs.org/docs/underscore.html#section-64 http://underscorejs.org/docs/underscore.html#section-64 I've been doing sophisticated JS UIs for 8 years now and had largely given up on ever being able to really manage async complexity - neither JavaScript Promises nor ES6 generators provide this level of process coordination and clarity. Very exciting times. EDIT: Oh and don't forget you can pattern match on the result of a select (alt!) with core.match to get Erlang style matching http://github.com/clojure/core.match http://github.com/clojure/core.match :) All this from libraries

adambard 13y ago
This has me super excited to build something cool with ClojureScript in the near future. I'm used to using lamina (https://github.com/ztellman/lamina https://github.com/ztellman/lamina) in Clojure, but for working with the browser this is a whole new world.
- jamii 13y ago
  I would be interested in seeing a comparison to lamina. I haven't had a chance yet to think about it properly but my first impression is that core.async is strictly more expressive but it couldn't implement something like lamina's flow diagrams.
  - puredanger 13y ago
    Do you mean in constructing networks or visualizing them? I see no reason why you couldn't do either with core.async.
    - prospero 13y ago
      Can you walk the chain of consumers and where they're forwarding the messages? I didn't see anything like that in the code, but you're far more familiar with it than I am.
      - puredanger 13y ago
        No, that's not there. I just mean conceptually there is no reason we won't have those kinds of debugging, visualization, etc tools eventually. This is a work in progress. Zach has done a phenomenal job with that stuff in Lamina.
        prospero 13y ago
        It seems to me that there are real obstacles to that; since the propagation of messages from one channel to another requires a separate 'take' and 'put', there's some halting problem-style obstacles to figuring out the causality of how messages are propagated. You can maybe create propagation operators that make these relationships explicit, but that would require either eschewing the bare take/put methods, or making sure the take/put behavior is in sync with whatever metadata you use to describe it.
        jamii 13y ago
        That's the kind of thing I was thinking about. The topology in lamina is described by data whereas in core.async it's described by code. I'll have to experiment more with both and see where the tradeoffs lie.
        puredanger 13y ago
        It seems possible to me to build the lamina style topologies on top of core.async.
        snprbob86 13y ago
  - prospero 13y ago
    CSP is message-oriented, Lamina is more stream-oriented. One implication of this is that in Lamina multiple threads can traverse the stream topology without any contention, but in core.async this isn't possible. Another is that the topology is explicitly described in Lamina, but it's implicit in core.async. That being said, I'm not clear if any of these differences are important to most people's use cases. I suspect that Lamina channels can behave like a core.async channel without much trouble, so it wouldn't bother me much if core.async became the primary interface for these sorts of things. If someone cares a lot about throughput or other distinguishing factors, they can just look under the covers. I am, however, a little curious how well the goroutine mechanism works in terms of being able to sample the state of the various tasks. Without some equivalent for "jstack", they become something of a black box.
bkirkbri 13y ago
Using core.match with core.async does sound promising! Am I correct that Erlang-style selective receive would NOT be possible? I don't see this as much of a downside though, considering the issues one can have with selective receives.
- swannodette 13y ago
  Yes I'm pretty sure selective receive is not supported.
  - pron 13y ago
    It is in Pulsar: * http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar http://blog.paralleluniverse.co/post/49445260575/quasar-puls... * http://puniverse.github.io/pulsar/ http://puniverse.github.io/pulsar/
  - snprbob86 13y ago
    You can mimic selective receive using a router process. Essentially, you could generate one channel for every branch of the pattern match, then generate a process which reads from the input channel and deals the message to the appropriate branching channel.
swannodette 13y ago
I've made a debounce example and compare to an Angular.js promises encoding: http://gist.github.com/swannodette/5888989 http://gist.github.com/swannodette/5888989

adambard 13y ago

This has me super excited to build something cool with ClojureScript in the near future. I'm used to using lamina (https://github.com/ztellman/lamina https://github.com/ztellman/lamina) in Clojure, but for working with the browser this is a whole new world.

jamii 13y ago
I would be interested in seeing a comparison to lamina. I haven't had a chance yet to think about it properly but my first impression is that core.async is strictly more expressive but it couldn't implement something like lamina's flow diagrams.
- puredanger 13y ago
  Do you mean in constructing networks or visualizing them? I see no reason why you couldn't do either with core.async.
  - prospero 13y ago
    Can you walk the chain of consumers and where they're forwarding the messages? I didn't see anything like that in the code, but you're far more familiar with it than I am.
    - puredanger 13y ago
      No, that's not there. I just mean conceptually there is no reason we won't have those kinds of debugging, visualization, etc tools eventually. This is a work in progress. Zach has done a phenomenal job with that stuff in Lamina.
      - prospero 13y ago
        It seems to me that there are real obstacles to that; since the propagation of messages from one channel to another requires a separate 'take' and 'put', there's some halting problem-style obstacles to figuring out the causality of how messages are propagated. You can maybe create propagation operators that make these relationships explicit, but that would require either eschewing the bare take/put methods, or making sure the take/put behavior is in sync with whatever metadata you use to describe it.
        jamii 13y ago
        That's the kind of thing I was thinking about. The topology in lamina is described by data whereas in core.async it's described by code. I'll have to experiment more with both and see where the tradeoffs lie.
        puredanger 13y ago
        It seems possible to me to build the lamina style topologies on top of core.async.
        snprbob86 13y ago
- prospero 13y ago
  CSP is message-oriented, Lamina is more stream-oriented. One implication of this is that in Lamina multiple threads can traverse the stream topology without any contention, but in core.async this isn't possible. Another is that the topology is explicitly described in Lamina, but it's implicit in core.async. That being said, I'm not clear if any of these differences are important to most people's use cases. I suspect that Lamina channels can behave like a core.async channel without much trouble, so it wouldn't bother me much if core.async became the primary interface for these sorts of things. If someone cares a lot about throughput or other distinguishing factors, they can just look under the covers. I am, however, a little curious how well the goroutine mechanism works in terms of being able to sample the state of the various tasks. Without some equivalent for "jstack", they become something of a black box.

bkirkbri 13y ago

Using core.match with core.async does sound promising! Am I correct that Erlang-style selective receive would NOT be possible? I don't see this as much of a downside though, considering the issues one can have with selective receives.

swannodette 13y ago
Yes I'm pretty sure selective receive is not supported.
- pron 13y ago
  It is in Pulsar: * http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar http://blog.paralleluniverse.co/post/49445260575/quasar-puls... * http://puniverse.github.io/pulsar/ http://puniverse.github.io/pulsar/
- snprbob86 13y ago
  You can mimic selective receive using a router process. Essentially, you could generate one channel for every branch of the pattern match, then generate a process which reads from the input channel and deals the message to the appropriate branching channel.

swannodette 13y ago

I've made a debounce example and compare to an Angular.js promises encoding: http://gist.github.com/swannodette/5888989 http://gist.github.com/swannodette/5888989