> How does this make a difference to the Clojure interface to threads? Clojure futures, promises, and some of its other concurrency primitives have synchronous

> How does this make a difference to the Clojure interface to threads? Clojure futures, promises, and some of its other concurrency primitives have synchronous semantics. So they don't take callbacks, instead the calling thread blocks on the result when it's at the point where it needs to wait for it. So that interface doesn't work with JavaScript's concurrency model. On the other hand, Scala futures have a asynchronous interface, and you specify a callback for success and error, and cannot block waiting for them, which happen to be 1:1 with the JavaScript promise interface. That's why on ClojureScript you don't have access to those concurrency construct, since they just don't work within the JavaScript model. The compiler maybe could have gone through amazing lengths to rewrite all use to an async one, but it just so happens there is already in Clojure something that does so, but it rewrites a CSP interface to an async concurrent model (not futures and promises). It's called core.async and this one exist in both Clojure and ClojureScript. > I can understand providing different libraries for different platforms, but language semantics should remain (as much as is possible), e.g. numerics Even Scala.js has some differences in numeric types they list in their page. There's always the possibility of mismatch of a language over some runtime. In ClojureScript I think it was planned to eventually bring the same numeric semantics over, but they started without, and it seems no one minded and then never bothered.