4 ms·

The JVM offers real threads, and JS not. The JVM offers nanosecond-precision time measurement, and JS not. JS has a single type for representing numbers. And so

by vemv 6y ago

The JVM offers real threads, and JS not. The JVM offers nanosecond-precision time measurement, and JS not. JS has a single type for representing numbers. And so on. How can those possibly be abstracted away and unified? If doing so, what would have the solution have to do with type inference at all? i.e., this is simply a difference in how one approaches platform interop (raw vs abstracted/unified). Clojure occasionally offers cross-platform abstractions (e.g. core.async) but it's not its main philosophy.

wtetzner 6y ago
> The JVM offers real threads, and JS not. How does this make a difference to the Clojure interface to threads? After all, if you're running your JVM on hardware that doesn't support parallelism, you're not getting parallelism anyway. > JS has a single type for representing numbers. The comment you're replying to already covered that: > For example, the reason Scala.js can provide exact semantics for numerics while maintaining high performance is precisely because it knows what exactly types things are, and can use that information to optimize the generated JS in a semantics-preserving way > Clojure occasionally offers cross-platform abstractions (e.g. core.async) but it's not its main philosophy. I can understand providing different libraries for different platforms, but language semantics should remain (as much as is possible), e.g. numerics.
- didibus 6y ago
  > 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.

by vemv 6y ago

wtetzner 6y ago

> The JVM offers real threads, and JS not. How does this make a difference to the Clojure interface to threads? After all, if you're running your JVM on hardware that doesn't support parallelism, you're not getting parallelism anyway. > JS has a single type for representing numbers. The comment you're replying to already covered that: > For example, the reason Scala.js can provide exact semantics for numerics while maintaining high performance is precisely because it knows what exactly types things are, and can use that information to optimize the generated JS in a semantics-preserving way > Clojure occasionally offers cross-platform abstractions (e.g. core.async) but it's not its main philosophy. I can understand providing different libraries for different platforms, but language semantics should remain (as much as is possible), e.g. numerics.

didibus 6y ago
> 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.