Fork me on GitHub
#core-async
<
2020-12-02
>
jjttjj17:12:23

Are there general guidelines to determine if something should be implemented as a transducer or go-loop? It seems like if something has inputs from more than one independent processes, or if the output can be expressed by repeatedly applying a reducing function to inputs, it can not be a transducer. Is that basically it? Is it generally worth avoiding the creation of intermediate go processes and channels just to subject values to transducers? Like, if I have to receive inputs from a few channels in a go-loop and merge them into a shared state, then do some computation on that shared state which can be expressed as a transducer, what factors influence if you should actually put it in a transducer on an output channel vs just coding that logic into the go-loop. I know this might be extremely dependent on the particular situation, but are there any common guidelines/tips?

Alex Miller (Clojure team)17:12:12

if it's on the channel, then it's not connected to the loop - that might be good or bad depending on the situation

Alex Miller (Clojure team)17:12:39

if it's not connected and you take the channel then you're giving your producer/consumer the freedom to do more things

Alex Miller (Clojure team)17:12:19

sometimes doing the transducer thing is "what you do" though and in that case you want it to be internal (whether it's on the channel or in a go loop)

Alex Miller (Clojure team)17:12:54

keep in mind also that transducers on channels may be executed by either the producer or consumer thread of the channel so you have less control about where that's happening

Alex Miller (Clojure team)17:12:17

if it's inside a go-loop, you know it's in the go pool

jjttjj17:12:28

by > if it's on the channel, you mean "in a transducer" in this context right?

Alex Miller (Clojure team)17:12:53

by "it" I meant a transducer

Alex Miller (Clojure team)17:12:45

also consider pipeline[-blocking,-async] as another important option here with parallelism

jjttjj17:12:35

got it, thanks for the tips. Unfortunately the stuff I've been working with lately isn't parallelizable. So I've been bouncing back and forth between using more or fewer transducers