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.
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.
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.
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).
The absolute number of survey respondents is not a good proxy for community size - the survey runs at different times of the year, for different lengths of time, and with different amounts of marketing. The only goal with the survey is to get a representative sample size. We have other sources of data, both public and private, that are better indicators and indicate the community size is likely growing at this time.
The annual Clojure/conj conference is coming up next month in Alexandria, VA (https://2024.clojure-conj.org) and there will be talks from a variety of companies, both big and small.
If you're interested in learning more about Clojure, check out the Clojure/conj conference Oct 23-25 in Alexandria, VA. https://2024.clojure-conj.org :)
Having done substantial work in both Java and Clojure, my experience with abstraction in both is that in Java, making things more abstract almost always involves making the code larger (adding more interfaces, extending existing types to those interfaces, etc) whereas in Clojure making things more abstract typically means they get smaller.
Over time and at scale, this matters quite a lot. Java code grows and grows at a super linear rate as it handles new and changing requirements. This is ultimately not sustainable. Clojure code typically grows at a more linear rate (accretion of attributes in data or operations on data), but has more tools to create abstraction that can actually (if wielded well), be sub linear instead. This kind of change is not free or easy in any language, but in Clojure it is at least possible.
Generally for streams, the equivalent in Clojure with sequences or transducers is much cleaner and simpler so there was not a lot of reason to want them from Clojure. However, it is important to provide interop paths to work with Java libs that make use of them.
The functional interface coercion is implemented with invokedynamic.