c is an unbuffered channel and it will forever block at (a/>!! c "Blocking - not in go-block") since it's impossible for anyone else to read from the channel

I'm not sure what makes it look like it's returning nil. Maybe your repl is timing out and just returning nil?

changing the buffer size to 1 will return "Blocking - not in go-block"

(let [c (a/chan 1)]
  (a/>!! c "Blocking - not in go-block")
  (a/<!! c))
;; "Blocking - not in go-block"

It actually seems like it's not the issue. Your snippet also returns nil.

not in my repl

I'm on clojurescript though, and I've got an error in the repl which says that >!! is undeclared

oh

blocking operations are not supported in clojurescript

That makes sense

I'm not entirely sure how I'm supposed to take the value out of a go block then?

I'm less familiar with cljs core.async at this point, but there at least 3 options: • take! • poll! • wrap your <! in another go block

You don't really. One way to communicate some value out of a go block would be to modify an atom, but because of how JS works once you're in async code (like a go block) there isn't really a good way out of it.

I think I remember seeing some integration with promises/await, but I don't have link handy at the moment

Yeah I see

right, but await et al are still just right back in async code since you can only await in an async function.

unless I'm remembering my js wrong.

I can only pass values around, but not evaluate some async code in the repl and get a result

That makes sense since browser js is single threaded

> right, but await et al are still just right back in async code It is core.async after all

even on the jvm, <!! is blocking, but it's still asynchronous. It's just a matter of whether you want to use the OS scheduler or the scheduler that core.async's go macro uses (there are some other resource differences too).