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) in Clojure, but for working with the browser this is a whole new world.
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.
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.
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.
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.
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.
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.
