[bad_user]

I think people are seriously underestimating the protocol involved and understanding that protocol is required if you want to build your own transducers compatible streaming, which is always useful. There's also the issue that the protocol in question may not be generic enough. From the presentations I've seen it claims that it might work with Rx streams as well, however I don't think it can deal with back-pressure. This is just a personal opinion and I'd like to be proven wrong.

That said the concept is pretty cool and we shouldn't fear learning new things. After all, the whole point of learning a new programming language is to be exposed to new ways of solving problems, otherwise why bother?

[sindux]

Adding to weavejester comment, back-pressure is to be handled with core.async channels [1]. I guess in Rich's terms, RX/FRP "complects" the communication of messages with flow of control [2]. Although this last statement may not be true anymore given that RX now has many functions to control the scheduler (eg. observeOn/buffer/delay, etc).

[1] http://clojure.com/blog/2013/06/28/clojure-core-async-channe... [2] http://stackoverflow.com/questions/20632512/comparing-core-a...

[weavejester]

Transducers are, I believe, largely orthogonal to back-pressure concerns. They describe only how transform the data at each step.

[bad_user]

That's not correct, because if they described only how to transform the data at each step, then you couldn't describe `take` or `flatMap`.

[weavejester]

Because Clojure isn't a pure functional language, transducers may be stateful. `take` uses a volatile (i.e. a fast, mutable variable) to retain state. I don't believe a `flatMap` transducer exists in Clojure yet.