This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-14
Channels
- # announcements (1)
- # beginners (206)
- # calva (2)
- # cider (64)
- # cljs-dev (12)
- # clojars (2)
- # clojure (177)
- # clojure-europe (2)
- # clojure-finland (1)
- # clojure-italy (2)
- # clojure-losangeles (5)
- # clojure-nl (7)
- # clojure-russia (69)
- # clojure-spec (41)
- # clojure-uk (92)
- # clojurescript (60)
- # core-async (16)
- # cursive (48)
- # data-science (6)
- # datomic (73)
- # duct (5)
- # events (2)
- # figwheel-main (5)
- # fulcro (29)
- # hoplon (1)
- # off-topic (52)
- # pathom (11)
- # reagent (4)
- # reitit (5)
- # remote-jobs (1)
- # rum (7)
- # shadow-cljs (58)
- # slack-help (10)
- # spacemacs (3)
- # testing (3)
- # tools-deps (5)
yep! i've already switched my nodejs project to using them and they're working perfectly 🎉
I watched Rich Hickey's talk "maybe not" and I love the idea of s/select
I think it's because go has to do tricky body rewrites, and go-loop can reduce that complexity compared to using loop
go-loop just expands to (go (loop ...))
, I don't see how that could help rewrites https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L458-L461
a loop is usually going to wait on a timeout or a channel, both of which should be things you do in go loops,
That's interesting and makes sense. But if I'm going to do IO for every input message, is it efficient to wrap every IO op in a thread, rather than the whole loop?
use (<! (thread (blocking-op)))
inside go-loop
the pool is small and easy to exhaust / congest
I think which is best is kind of a thorny question, but it is clearly the design core.async pushes you towards
oh - did you mean the core.async/thread
threads? yes those are pooled too, and I think the usage of thread to do one blocking op, letting you park on the result in the thread's channel, is the intended pattern