Let's break this down a bit. It's pretty clear to me that there are 3 reasons why you'd want to use CSP channels or actors.
1) Reliability. This is mostly going to be of the subscribing to other actors to make decisions when they die type. This is a complete replacement for try/catch, and probably isn't possible or desirable on the JVM due to mutability concerns. If you need and want this, Erlang is your bet.
2) Performance. This is probably the most common reason, and a true fiber system can hit this just fine on the JVM. So what if touching old code might cause degraded performance due to blocks, it's not unreasonable at all to say that high performance code will require some care. And if the fiber system warns you, the more the better. Quasar is your bet here.
3) Architectural niceness. Callbacks suck, and we all know it. CSP channels can be seen as a nicer way to structure the flow of a large asynchronous system. In this context I think core.async tends to be the best, because of it's support for transducers and Javascript support. Although Quasar/Pulsar would not be a bad second choice for this because they work outside of a go macro, assuming you only need them on the backend.
1) Reliability. This is mostly going to be of the subscribing to other actors to make decisions when they die type. This is a complete replacement for try/catch, and probably isn't possible or desirable on the JVM due to mutability concerns. If you need and want this, Erlang is your bet.
2) Performance. This is probably the most common reason, and a true fiber system can hit this just fine on the JVM. So what if touching old code might cause degraded performance due to blocks, it's not unreasonable at all to say that high performance code will require some care. And if the fiber system warns you, the more the better. Quasar is your bet here.
3) Architectural niceness. Callbacks suck, and we all know it. CSP channels can be seen as a nicer way to structure the flow of a large asynchronous system. In this context I think core.async tends to be the best, because of it's support for transducers and Javascript support. Although Quasar/Pulsar would not be a bad second choice for this because they work outside of a go macro, assuming you only need them on the backend.