I hadn't really thought that bit through properly. Makes some interesting designs easier

core.async is generally intended for CPU-bound tasks whereas vthreads are optimized for I/O-bound tasks.

But, yes, I played with a "variant" of go and the blocking ops where the go macro just set up a vthread context, as I recall. I think I posted the code here at some point...

https://clojurians.slack.com/archives/C8NUSGWG6/p1652487349607519?thread_ts=1652433406.842079&cid=C8NUSGWG6

I had never thought that core.async was intended for CPU-bound tasks… it is useful for anything you want to model as communicating processes

Because of the limited thread pool, that's why it's recommended to use thread for I/O with core.async rather than just go and parking. I/O will block a thread so you can't have much of that going on in regular go blocks before you'll choke the thread pool. That's my understanding of why core.async is primarily focused on CPU-bound tasks, so that channels act as synchronization points.

sure, that’s a good point (and been there, done that… exhausted the thread pool 😉

so vthreads look like a nice complementary thing for those blocking io tasks

I'll be interested to see what comes of https://ask.clojure.org/index.php/13366/virtual-thread-executor-for-core-async

(just switching to a vthread executor is not a good idea -- core.async currently uses real threads for dispatch, on top of the thread pool -- and the use case doesn't map 1:1 anyway)

re: the java 21 requirement - I wonder how things in a library rather than in core affect that decision making

one could imagine a mostly core.async API-compatible vthread using library… but it would be unfortunate if that forks the community, better to wait for the 1st party solution

At one point, we talked about a subset of core.async built on vthreads at work: just the channels and blocking ops with vthreads backing the go machinery -- but when we had to back off JDK 19 + preview due to memory leaks we dropped the idea and haven't circled around to it. At this point, knowing vthreads are on the core team's radar, I doubt we'd invest any time/effort into it even with JDK 21 being available...

So nobody likes core.async concurrent abstractions? Like the CSP model. You know, say using thread + everything else, but don't use go ? Or said another way, would you not use it if it didn't have go doing coroutines?

Cause I feel with vthread that's kind of the question.

concurrent programming is difficult and go ioc macros are a complicated piece of machinery… so I try to use it as little as possible, but when you need to, it is a great thing to have.

I learned CSP at university (early '80s) and one of my early jobs was writing a compiler that targeted the Inmos Transputer. It's a very useful model for communicating sequential processes -- but the current core.async implementation (based on code transformation and aimed at collaborating CPU-bound processes) has its own limitations. Virtual threads also have their own limitations (despite the hype!). I think the CPU-bound vs I/O-bound tension needs to be resolved before we can really figure out whether core.async or some variant of it is the One True Solution covering both spaces. My sense right now is that it isn't and we need two separate things (that could both be built on vthreads, but need slightly different semantics).

So maybe because core.async also tried to build the coroutines machinery, it missed the mark on providing a good CSP abstraction? And introduced to many gotchas? So I think the question is, can you bring about a better CSP library without those gotchas using vthread? If so, there should be value in that. Unless CSP is also just no longer the hype it was, and people much prefer to have async/await and promises, or something more like structured concurrency. Or maybe even executors is a nicer model. Or Rich was wrong, and Actors is the holy grail, etc.

I think it’s more that you want to write simple purely functional code for the most part, and isolate any code needing orchestration machinery to as small as possible… just like with other IO

There’s also https://clojuredocs.org/clojure.core.async/pipeline https://clojuredocs.org/clojure.core.async/pipeline-async https://clojuredocs.org/clojure.core.async/pipeline-blocking (built on top of core.async, mostly) So definitely possible to do IO-bound stuff in core.async… Those are neat little … functions 🙂 I’ve used them in the past for specific use cases, quite powerful!

Even using just (thread ...) I think CSP/core.async is an excellent and super elegant concurrency model. But I think it just takes time to learn it, and use it “properly”, and as with everything that is sufficiently powerful + not simplistic… it can be abused, or used in a wrong way. I’ve found it to be super poweful for building complex UIs and animations in ClojureScript also. It’s beyond anything the JS ecosystem has (again, quite niche and not understood very well I find).

So nobody likes core.async concurrent abstractions?I guess I like them, fwiw 😄

(again, used where appropriate… in the early years I definitely made a mess once (or twice) with core.async (mostly UI-stuff… which is always … complicated) before learning what not to do… so in that sense, it’s almost a different programming paradigm from a certain perspective)

If you want to learn core.async , use it in a ClojureScript app! Learning is guaranteed 😄