For me, the real 'click' moment with core.async wasn't just about replacing callbacks. It was realizing I could model entire business processes as a system of communicating channels. It completely changed how I think about system design.

▲

blackbear_ 3 days ago | parent | next [-]

Curious if you have found any resources to learn more about this way of thinking?

	▲	puredanger 3 days ago \| parent \| next [-]
		Rich Hickey actually did a talk called "Language of the System" https://www.youtube.com/watch?v=ROor6_NGIWU way back in 2013 before core.async was even created that lays out a lot of the ideas. It even has a big section explicitly about "flow" which contains the germs of core.async.flow.
	▲	wvdlaan 3 days ago \| parent \| prev [-]
		Perhaps this is a good place to start reading: https://en.wikipedia.org/wiki/Communicating_sequential_proce...

▲

akkad33 3 days ago | parent | prev [-]

Is it like elixir actors

▲

lgrapenthin 3 days ago | parent [-]

No. Those have unbounded message queues.

▲

akkad33 3 days ago | parent [-]

Thanks. Is that the only difference

	▲	didibus 2 days ago \| parent [-]
		It's quite different, the way you model things, it's entirely different. Even though both are able to deliver highly concurrent computation. A process in Elixir has an id, state, and is sent messages to its address. The message are queued inside the process, and handled one at a time. One process can spawn another, and so on. It's more like white collar workers sending emails to each other. In core.async, a Process is anonymous, it doesn't have an id and doesn't have an address. You cannot send messages to it. Instead a process is more like a worker on an assembly line with conveyor belts. What matters are the conveyor belts and what's on them. Where things go from one belt to the next and what happens to the things as they flow through. You can have multiple workers working a belt and if something jams dependent belts stop. The belts are called Channels.