Clojurians Log v2

> The fundamental objective of core.async.flow is to enable a strict separation of your application logic from its topology, execution, communication, lifecycle, monitoring and error handling This goal is the strict opposite of missionary's hypothesis, i.e. all of these concerns should be unified because they're the exact same thing

So the exact same thing in the sense that topology, execution, communication, lifecycle are inherently tied to application logic?

yes

I can see that yes, it feels missionary is more comprehensive, giving more abstractions while keeping intact things like try-catch reasoning on a code-local level all the while giving backpressure strategy gaurantees over complex and dynamic flow topologies. Rich has stated that dynamicity is less of a goal (but still work in progress).

Hickey mentioned it's easy to get into a mutable mess when adding dynamic flows in the mix, but I'm guessing a lot of that mutable mess is things that missionary hides from the user. It does seem to me that the learning curve for core.async.flow is substantially lower than learning to write proper missionary though.

Rich is right - proper specification of dynamic topologies is a tough problem. Everything is simpler in the static case, so it makes sense he decided to focus on that, assuming it fits his problem space (which he's still vague about, but e.g. he clearly didn't mention UI)