3 ms·

More importantly, you can use the mature ecosystem around Java (tools, libraries and so on).

by pvorb 5y ago

Nullabillity 5y ago
Then again, considering the JVM's disastrous recent trajectory (Loom, JPMS, renewed wasted focus on Java-the-language, and so on) that doesn't seem like such a great upside anymore.
- kaba0 5y ago
  Wat? How is the recent trajectory disastrous?
  - Nullabillity 5y ago
    To take Loom as an example.. The primary problem with threads isn't their performance, but the way that they encourage bugs and race conditions by decoupling data access from flow control. They're fine as a low-level API for implementing a more usable API, but not as the primary API that you expect application developers to use.
    - valenterry 5y ago
      This seems to be more of a Java problem, not a JVM problem.
    - kaba0 5y ago
      Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism? And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking. Abstraction built on top of them will be easier to reason about, no callback hell, etc.
      - Nullabillity 5y ago
        > Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism? As I already wrote? But doing M:N scheduling at the JVM level (which is ultimately what Loom is) won't help your future (/promise) runtime which already implements a thread pool internally. > And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking. If you like the blocking model and don't care about performance then you can go and use native OS threads in the same way right now. M:N scheduling (including Loom) is ultimately about making threads cheaper to create, which means that theoretically you can have the "best" of both worlds (performance of futures, API of threads). My point is that this is a nonsensical goal, because the API of threads is awful. > Abstraction built on top of them will be easier to reason about, no callback hell, etc. Until you try to introduce concurrency, at which point you're back to the hellscape that is manual multithreading.

More importantly, you can use the mature ecosystem around Java (tools, libraries and so on).

by pvorb 5y ago

More importantly, you can use the mature ecosystem around Java (tools, libraries and so on).

Then again, considering the JVM's disastrous recent trajectory (Loom, JPMS, renewed wasted focus on Java-the-language, and so on) that doesn't seem like such a great upside anymore.

kaba0 5y ago
Wat? How is the recent trajectory disastrous?
- Nullabillity 5y ago
  To take Loom as an example.. The primary problem with threads isn't their performance, but the way that they encourage bugs and race conditions by decoupling data access from flow control. They're fine as a low-level API for implementing a more usable API, but not as the primary API that you expect application developers to use.
  - valenterry 5y ago
    This seems to be more of a Java problem, not a JVM problem.
  - kaba0 5y ago
    Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism? And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking. Abstraction built on top of them will be easier to reason about, no callback hell, etc.
    - Nullabillity 5y ago
      > Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism? As I already wrote? But doing M:N scheduling at the JVM level (which is ultimately what Loom is) won't help your future (/promise) runtime which already implements a thread pool internally. > And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking. If you like the blocking model and don't care about performance then you can go and use native OS threads in the same way right now. M:N scheduling (including Loom) is ultimately about making threads cheaper to create, which means that theoretically you can have the "best" of both worlds (performance of futures, API of threads). My point is that this is a nonsensical goal, because the API of threads is awful. > Abstraction built on top of them will be easier to reason about, no callback hell, etc. Until you try to introduce concurrency, at which point you're back to the hellscape that is manual multithreading.