Fork me on GitHub

Anyone able to contrast the use of Observables (as implemented in RxJS/RxJava/React Extensions/etc) with that of core.async in the construction of “event streams” that can be composed (for lack of a better term)?


I take it, core.async is a lower level abstraction than that of the API provided by Observables, so one can theoretically reproduce the API with core.asyc?


@gurdas: sounds about right. I guess the conceptual difference is much about CSP having chan being an object, while Rx has the Observable as a 'thing'. So you'd have to translate between those concepts, but that's totally doable .


Is any of those models preferable when doing concurrency? Have very little experience with Rx. Enjoying CSP but sometimes wishing it was an Erlang style actor model


@gurdas: one small addition to that - with core.async and transducers you can reuse function easily. With RxJS representing something like (def p (comp (filter f1) (map f2)) so it can be reused across all the app is not that… elegant I say


I’ve been a big fan of RxJS (and still use it for all JS related work - much better than Promises), but core.async is on a lower level and I like that I have more control on that


Good comment btw A lot of things depends on a task


Doesn’t RxJS have a function to let you lift normal functions up into observable streams?


(I don’t have any firsthand RxJS experience, but ReactiveCocoa has that)


if i'm dealing with core.async mults, is it more idiomatic to mass around a mult to various functions that need it and tap it within the function, or should i just tap a new chan at a higher level and only deal with actual chans in the lower level functions, or am i just worrying too much about this


not a ton of example code i can find and im trying to get a sense of how i should be structuring these things


Generally I would tap the mult outside the function so the function doesn’t have to know anything about the bigger architecture.


ok cool thanks!