Clojurians Log v2

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?

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

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

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)

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

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

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

by "it" I meant a transducer

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

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