Hello @U02SPB5Q6A3 Lets try to answert your questions: 1. Yep, the vthread is not hard requirement, but is a nice-to-have, the standard platform threads are used as fallback. 2. core.async right now has more patterns and helpers than promesa, and promesa does not intends to have solution for all the user cases of core.async. 2b: i gues noup, I mean, the promesa csp module is pretty usable in real world without vthreads. I have tested (and greatly surprised) that I have been able have 15k real platform threads running without blowing the memory; so there are cases where the absence of vthreads is not real problem. Obviously if you want to have 1M of them, or is latency sensitive on spawning a huge amount of short living real platform threads, probably you will need to stick with core async.. 3. cljs is not supported because of two main reasons: cljs does not benefit of using blocking operations so you will be limited to the already existing syntax helping macros that promesa provide for working with asyncronous code; and the second reason is because I don't really need it, personally I think channel implementation is not very usefull on frontend code (i will explain and put better references on the upcoming blogpost). It can be implemeted, but depends in the real interest on having it, and with the obvious first limitation that I have comented... I have developed it with initial target on using it on backend (my own first use case is replace all the websocket realted core.async code with more simpler approach using vthreads on penpot project where core.async is used right now extensivelly on the background tasks and websockets code)

In any case, just for redundancy, the promesa csp impl is very experimental and is still not very hard tested in real environments, it will change over time and we will test it on real production environments, and some missing features will be added.

And yes, promesa csp impl intend to be less error prone, removing the need to have thinking on differentiation on parking and blocking, unifying all under blocking operation and leaving the JVM to handle it for us.