Hello all, I have a function that use clj-http to do this (http-client/get "" {:socket-timeout 3000 :conn-timeout 3000}). I don´t know why, sometimes the get don´t get response. Is there any way to do timeout to handle this?

I don't think that's core.async related at all?

I use loop all the time in go blocks, often to manage state.

@tanzoniteblack was thinking about the recent presentation by @tbaldridge where he would like to see less core.async in 'normal' code

I'm happy with it, just wanted to see if I am breaking some new idioms

But, given the responses so far, I guess not

Is there an equivalent of doseq for reducibles usable in go blocks?

Or maybe doseq is actually optimized that way already

No, doseq uses a sequence

Is into with a map transducer not equivalent?

and additionally, not sure what go blocks have to do with this

Well sometimes you use doseq in go blocks with a >! in the body for instance

oh, something like run! maybe

Will not work

Run! takes a fn

oh, right

so no blocking put possible

You think it might be a worthy addition?

I’m trying to bend my head around what it would be and whether it’s possible

I think I would not even use doseq, I’d use loop

but I don’t see how it would be possible to give a parkable procedure to a reducible and have that work with go

yes, reducibles are push-based, so they require their own dedicated thread to spin results onto a channel

@raymcdermott your post was yesterday but it’s an interesting topic — I think your intent is clear; either way, I’d make one fundamental change: instead of forcing core.async on your caller, requiring him/her to create a channel and pass it in, create one yourself, and return a function which, when called, terminates the loop — here is a gist which shows a few different ways to do that

https://gist.github.com/joshjones/cec1b154d50888203bd9a399645b256e