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.
I agree with your critiques, but I still don't think it negates the overall picture I see.
When I was a scientist, we were trained to look at the overall body of evidence when trying to assess a claim. Any individual study has flaws, but when we survey the literature as a whole, do we see many studies confirming a finding? Independent studies presumably don't share the same set of flaws (usually), and the more studies demonstrating something, the more likely it is to be true.
And I just haven't heard any counter-evidence. Are job postings increasing or decreasing? What's the change in MAU for Clojurians? Etc.
I looked for job/social media numbers, but it's hard to get those numbers. If you have better data, I'd love to see it.
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.
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.
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.
The trickiest problems with VT aren't due to mutability. Mutability is problematic with any kind of concurrent programs.
The difficult problems are execution problems like pinning. There are plenty of existing concurrency libraries on the JVM (Cats Effect, clojure async, Kotlin coroutines, RxJava, quarkus, etc etc). The promise of VT is that you will no longer need those for scheduling and execution of work (whether that's tasks, fibers, coroutines, actors etc.) This only works if you use VTs throughout, not just on IO pools.
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).
