I agree that immutability is central to Clojure and the resulting code definitely reflects that. But managing state, as the OP put it, truly is what Clojure is

I agree that immutability is central to Clojure and the resulting code definitely reflects that. But managing state, as the OP put it, truly is what Clojure is all about - and immutability falls out of that very deliberate design decision. Let's not confuse the lack of significant STM transactions with refs and its irk with representing the totality of Clojure's concurrency story. Many Clojure libraries make use of atoms, agents, and dynamic scope (which is arguably a concurrency primitive, given the thread locality of the bindings, but not unique to Clojure). While "concurrency is not parallelism", parallelism is a special case of concurrent programs that is often challenging. Clojure's offerings here too are compelling - we have the amazing Reducers library which allows you to write higher order functions for collections that, as Rich Hickey put it, "know how to reduce themselves" - and get parallelism (without locks, without even thinking about it really) on top of that. And then there's the lazy parallel functions - pmap, pcalls, pvalues. Check them out if you haven't. I use Clojure often in a machine learning context with Hadoop/Storm, these abstractions are highly valuable in crafting solutions. Futures/promises are also widely used in Clojure. I'm confused as to why you think data structure literals are part of Clojure's core thesis. Perhaps I just don't understand what mean - are you saying that the fact that the Lisp reader can read strings as data structures as being part of what Clojure is about? If so, that statement would apply to all Lisps, not just Clojure.