At this stage, you might be wondering when you should choose one approach over the other. After all, as demonstrated at the beginning of this chapter, we could use core.async to do everything we have done using respondent.

It all comes down to using the right level of abstraction for the task at hand.

core.async gives us many low level primitives that are extremely useful when working with processes, which need to talk to each other. The core.async channels work as concurrent blocking queues and are an excellent synchronization mechanism in these scenarios.

However, it makes other solutions harder to implement: for instance, channels are single-take by default, so if we have multiple consumers interested in the values put inside a channel, we have to implement the distribution ourselves using tools such as mult and tap.

CES frameworks, on the other hand, operate at a higher level of abstraction and work with multiple subscribers by default.

Additionally, core.async relies on side effects, as can be seen by the use of functions such as >! inside go blocks. Frameworks such as RxClojure promote stream transformations by the use of pure functions.

This is not to say there aren't side effects in CES frameworks. There most definitely are. However, as a consumer of the library, this is mostly hidden from our eyes, allowing us to think of most of our code as simple sequence transformations.

In conclusion, different application domains will benefit more or less from either approach—sometimes they can benefit from both. We should think hard about our application domain and analyze the types of solutions and idioms developers are most likely to design. This will point us in the direction of better abstraction for whatever application we are developing at a given time.