Trying to understand the motivation of core.async better, I re-watched Rich’s original talk introducing the library, where he lays out the purpose behind it.
Early in the talk (04m55s), he discusses problems with other ways of writing programs that need to use a lot of asynchrony because they need to be highly reactive to external events (like network traffic or user inputs).
His slide has these bullet points:
- Listenable Futures/promises
- a web of direct-connect relationships
- difficult to reason about or control flow
- fragmented logic - callback hell
- handler list visibility, monitoring, control difficult
- Observabls/Rx etc only mitigate certain cases.
I would LOVE to understand this slide completely. I think I only understand it partially at the moment.
One that interests me in particular is the last item, “Observables/Rx etc only mitigate certain cases”. Could you say a word about this? In what way are they more limited than core.async-style channels? Rich says the following:
And there have been, you know, various approaches to try to mitigate some of this with observables and Rx and things like that, but they only handle a very narrow set of cases, mostly, you know, filtering or making a stream like kind of approach to composable transformations on a single event chain. But if you really are trying to make a state machine that has multiple sources and sinks of events, you can’t just get it out of something like, you know, filter and map composition primitives.
So Rich is saying that “observables and Rx and things like that” don’t provide primitives for making a state machine, because they don’t easily handle multiple sources and sinks of events.
What puzzles me about this, is the the implementation of Rx-like ideas that I am most familiar with is ReactiveCocoa, a reasonably popular translation of Rx into Cocoa for UI development. I have never seen ReactiveCocoa discussed in the same breath as golang channels or core.async. I am dying to understand if that’s because they are fundamentally different in some way (which is what Rich seems to be implying) or if it is just accident that no one has pointed out they are the same thing.
If you look at this page summarizing the ReactiveCocoa operators, it sure seems like there are facilities for handling multiple streams.
Was Rich discussing narrower implementations than ReactivceCocoa? Or am I missing something basic here?