Clojurians Log v2

@ben.borders ztellman/manifold also provides the tools you need for that type of system with its Deferred https://github.com/ztellman/manifold/blob/master/docs/deferred.md#future-vs-manifolddeferredfuture and Stream https://github.com/ztellman/manifold/blob/master/docs/stream.md concepts, and a future impl which behaves like a Deferred (i.e. is also composable in chains of Deferreds)

if you need it there is also control of executor / thread-pool - https://github.com/ztellman/manifold/blob/master/docs/execution.md

Is there a built in core.async function that can make the following code easier to read?

(let [x-chan (async-function)
      y (<! (async-function))
      z (<! (async-function y))
      x (<! x-chan)]
  ...

Hi @dehli you can use async/map

(let [x-chan (async-fn)]
  (<! (async/map vec [(async-function) (async-function y) x-chan])))

It will return a vector of results [y z x]

thanks @bertofer! wouldn't they all execute in parallel then?

Ah, yes, sorry I’ve just seen that z needs y

no worries! I had investigated using map b/c it does seem like a much cleaner way to do it but I'm not sure how I can get that with dependencies between channels

manifold has the issue that taking from a stream returns a deferred, and you can choose from some deferreds, but the unchosen deferreds don't get "untaken" from the streams, which means it can't do the same things as core.async's alts! (which I use all the time). I haven't spoken to zach about it but I suspect this is due to manifold starting from netty and the existing abstractions (futures, etc) instead of starting from some formalism (csp, cml, reagents, etc)

implementing choice (select, alts, etc) correctly over io is trickier then it is over some in memory thing

for sure core.async is neater for select-like ops

if you find yourself writing code like the above, where you are using core.async as of an improved version of futures or promises, where you use go and not go-loop, you are not getting the most you can out of core.async. my suggestion is to view parts of your program as micro services that communicate via channels, so you write things as go-loop's that consume messages from a channel

https://www.youtube.com/watch?v=ROor6_NGIWU is maybe a good talk by rich that predates the first public core.async commits by some number of months (I think that talk was at the conj, so late in 2012, and the first core.async commit in the repo is may 15th 2013), where he talks about machines and queues and services