puredanger

This is very cool, glad to see it! I couldn’t figure out which version of the JVM you used for the core.async tests? Also, you are using old versions of both Clojure and core.async which have both had optimizations in the last year that should help all of these. Some of these tests may also be helped by using io-thread (with JVM virtual threads) instead of go in latest core.async.

It was hand drawn by an artist. Indiana Jones (the obvious inspiration) wore two belts, one for his pants, one for his whip/holster. The code was provided by Rich.

Many people use it in ways that have no ties to the JVM - ClojureScript on the web, Babashka for scripting, ClojureDart for Dart apps, etc.

Correct, it will be on the CultRepo channel.

Thanks for the feedback! Flow monitor does now support filters on the process state (and more on that it is coming to flow itself soon). If you were able to use monitor, it shows the channel buffer states, I guess that was not sufficient to guess why values weren't flowing?

Note that newer things are always downloaded less because they have been around less time (lots of people continue using old versions).

Maven stats are available to artifact deployers, but they are useless for estimating users or community size as downloads are largely from CI servers constantly downloading artifacts for testing. Download numbers are large and seesaw erratically. Unique IP counts are a little more stable but also inflated beyond relevance by CI.

When you deploy a flow, you choose the workload type (:compute, :io, or :mixed) and the process will be deployed with the appropriate thread type.

Flow is intended for processes with long-running stable topologies. Rich has been thinking about options to "patch" the running topology but it is quite tricky due to the concurrency issues and I'm not sure that will ever be added.

Even though the flow topology is fixed, it's perfectly acceptable for a flow component to use other variable resources and act merely as a coordinator. So you could for example have a process that send data out to an external dynamic thread pool and gets callbacks via a channel.

Clojure's focus on immutable data and pure functions side-step a lot of the trickiest issues with virtual threads. It's often not hard to isolate the I/O parts of your program into flow processes at the edges that can be mapped to the :io pool using virtual threads.

I don't think it would be feasible or wise to structure core.async to use Structured Concurrency, although Structured Concurrency is trying to tackle some of the same problems as flow but in a different way (more akin to data flow style concurrency).