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.

FYI, the canonical version (recut slides / video / audio) of this talk can now be found at https://www.youtube.com/watch?v=SxdOUGdseq4

Rich's opening remarks from Clojure/Conj 2025 were just published and might be an interesting complement to this: https://www.youtube.com/watch?v=MLDwbhuNvZo

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.

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).

Fixed, thx.

Virtual thread support in core.async is imminent, should land any day now.

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.

Using (add-lib 'thi.ng/geom) is sufficient here - it uses the newest version by default.

It continues to exist and is in use. Lots of work has been done on a successor, but that is stalled while we consider what we want to do on various things.

The number of parentheses is the same, they're just in a different place. Isn't it tiring to type so many semi-colons and commas all the time?

Generally, custom seqs (rare) are implemented by leveraging something like `lazy-seq`, so library authors are also not using it.

Yes, it would be good if there were javadoc on more of the impl, but this is just not an issue for the vast majority of devs.

You don’t use the ISeq interface directly, you use them through the clojure.core API. The seq abstraction is documented at https://clojure.org/reference/sequences

https://github.com/clj-python/libpython-clj has deep support for leveraging the Python ecosystem and it works great.

Clojure 1.12 (which is nearly done) is going to add a bunch of interop support - method values, array class syntax, Clojure fn -> Java functional interface conversion, stream support, etc.

Maps are unordered, but let bindings are sequential so order matters.

Ed's post when Cognitect joined Nubank is still a great read: https://building.nubank.com.br/welcoming-cognitect-nubank/

Datomic transactions are not “operations to perform”, they are a set of novel facts to incorporate at a point in time.

Just like a git commit describes a set of modifications, do you or should you want to care about which order or how the adds, updates, and deletes occur in a single git commit? OMG no, that sounds awful.

The really unusual thing is that developers expect intra-transaction ordering to be a thing they accept from any other database. OMG, that sounds awful, how do you live like that.