Fork me on GitHub

I'm still experimenting with core.async and trying to build a small system with it. I've never used in-process queues much before (when I used queues it was mostly for inter-process communication, e.g. RabbitMQ). What would you say are the benefits of using core.async channels vs. something like built-in JDK queue implementations? Is there anything in particular that stands out? On the other hand, something you miss? (I mentioned monitoring above, but maybe things like durability, etc.)


as far as I know the only real advantage that the channels have over the builtin queues is that the channels are integrated into core async.


some potentially interesting videos if you haven't seen them: this is before core.async this is talking about core.async


I don't remember which of those talks it is but I'm pretty sure in one of those talks, Rich Hickey says that the builtin java queues are great


I guess another advantage of channels is that they support transducers


channels are also a more useful abstraction for "I want to block this thread while waiting to receive on this channel" when you're doing async work. some of the Go (language) channel talks by Rob Pike are relevant here as well, since the design and intent core.async is close to Go's goroutines and channels (though the underlying runtime and language are obviously very different)


there's also built-in flow control for it. in Go this would be the select {} statement and in core.async this would be alts! or alts!!


if you want to do flow control over popping multiple queues, you need to write that yourself.


channels can also be used for synchronization between go blocks with blocking puts and blocking takes


ah, yeah alts is really nice