I would assume however that threading concerns have not been taken into account for the "Clojure-in-Clojure" on display in ClojureScript however, based on https

I would assume however that threading concerns have not been taken into account for the "Clojure-in-Clojure" on display in ClojureScript however, based on https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure https://github.com/clojure/clojurescript/wiki/Differences-fr... That suggests to me that concerns over thread safety that are taken into account in the Java implementation, say of the core data structures, STM, etc, are not taken into account in the std. lib. of ClojureScript. That would make it unlikely for this code to be a useful origin or starting point for, say, an LLVM backend. Rich is a very clever fellow and makes fascinating trade offs between pragmatism and idealism in his language design. He continues to build languages quite tied to some existing runtimes which embrace their advantages and drawbacks. Consequentially, it will be very important to keep the rationale in mind while evaluating the real impact of ClojureScript. https://github.com/clojure/clojurescript/wiki/Rationale https://github.com/clojure/clojurescript/wiki/Rationale As neat as it would be to see, it will be a long time before an x86 or ARM backend emerges. As far as I know, the G1 Garbage Collector in the JVM is still the top of the crop of production GCs and even Haskell with GHC7 is still working towards something of similar potency. See http://hackage.haskell.org/trac/ghc/blog/new-gc-preview http://hackage.haskell.org/trac/ghc/blog/new-gc-preview Concurrent GCs and other aspects of runtimes geared towards heavy concurrency are insanely hard. Just something to keep in mind.