4 ms·

I feel like the unsung winner of Project Loom is going to be Clojure. Its already immutable first data structures, it should be relatively straightforward for t

I feel like the unsung winner of Project Loom is going to be Clojure. Its already immutable first data structures, it should be relatively straightforward for the Clojure project to expose the benefits of Project Loom to their ecosystem, as a language its designed to fit well its execution model.

pvorb 5y ago
Why should Clojure benefit more from Loom than other languages? I think it simplifies reactive/concurrent programming in any JVM language.
- no_wizard 5y ago
  Same reason I always felt extremely comfortable with concurrent programming in F#. The immutable first principle makes it easier to reason about what the program is doing during concurrent execution. Of course all projects will benefit from Loom. I am merely positing that Clojure in particular could leverage this both most quickly and to very deep positive effect, due to the nature of the language itself putting immutability first, which if I recall correctly they built up a pattern of concurrent execution around already. Kotlin too will be be able to optimize their concurrency story. I simply wanted to posit an observation I hadn't seen elsewhere on the web about Project Loom yet.
- eyelidlessness 5y ago
  Clojure was explicitly designed to make reasoning about concurrency simpler (most data is immutable and can be referenced in multiple routines without concern; mutable reference types use the same data semantics, wrapped in transactions) with minimal performance impact (immutable data types are implemented as persistent data structures, sharing memory rather than naive strategies like copy-on-write). I don’t know that it’ll necessarily benefit more from Loom than other JVM languages, so much as it’s well positioned to benefit from concurrency improvements generally because its underlying design encourages code well suited for taking advantage of concurrency generally. Edit to add: I hadn’t initially thought to speculate on the language itself taking advantage, but it occurred to me immediately after posting this comment. Another potential benefit is that many of its fundamental abstractions (most collection APIs are declarative) lend really well to making those operations concurrent, which is a common FP/lisp hypothetical but becomes more tangible if coroutines are less expensive. This isn’t dissimilar to how RDBMS query planners can provide wild performance improvements without any semantic changes, because SQL queries express “what” now “how”.
chrisseaton 5y ago
Loom threads have the same basic semantics as normal threads. There's nothing special about them that relates to immutability.
- lgessler 5y ago
  I think GP's point is that immutable objects (which Clojure uses "by default") can be easily used in concurrent settings. Immutable objects can be shared without concern between threads, whereas mutable objects may need to be copied or have their operations synchronized somehow.
  - chrisseaton 5y ago
    > may need to be copied or have their operations synchronized somehow Maybe through some kind of non-preemptive user-space scheduling you mean?
    - opnitro 5y ago
      Right, but you'd still need to synchronize that with some concurrency primitives (like a mutex or semaphore) and that has the potential for bugs. Whereas on an immutable structure can't suffer from that problem, which can make concurrent programming easier to reason about.
      - chrisseaton 5y ago
        > Right, but you'd still need to synchronize that with some concurrency primitives (like a mutex or semaphore) Why? If you know your thread won't be interleaved with any other until you a well-defined point, how's that different to using a mutex or semaphore?
        MobiusHorizons 5y ago
        IIUC, Loom threads can be scheduled across multiple OS threads (much like go-routines), so there is (at least the possibility of) real concurrency going on.
whalesalad 5y ago
I think a Clojure with first class legitimate actor semantics would be unreal. Clojure core will espouse async and tell you why actors are bad but man I love the actor model.
- weatherlight 5y ago
  https://www.clojerl.org https://www.clojerl.org Clojure for the Erlang VM :)
klysm 5y ago
I’d think it would also make a huge difference for Akka.

pvorb 5y ago

Why should Clojure benefit more from Loom than other languages? I think it simplifies reactive/concurrent programming in any JVM language.

no_wizard 5y ago
Same reason I always felt extremely comfortable with concurrent programming in F#. The immutable first principle makes it easier to reason about what the program is doing during concurrent execution. Of course all projects will benefit from Loom. I am merely positing that Clojure in particular could leverage this both most quickly and to very deep positive effect, due to the nature of the language itself putting immutability first, which if I recall correctly they built up a pattern of concurrent execution around already. Kotlin too will be be able to optimize their concurrency story. I simply wanted to posit an observation I hadn't seen elsewhere on the web about Project Loom yet.
eyelidlessness 5y ago
Clojure was explicitly designed to make reasoning about concurrency simpler (most data is immutable and can be referenced in multiple routines without concern; mutable reference types use the same data semantics, wrapped in transactions) with minimal performance impact (immutable data types are implemented as persistent data structures, sharing memory rather than naive strategies like copy-on-write). I don’t know that it’ll necessarily benefit more from Loom than other JVM languages, so much as it’s well positioned to benefit from concurrency improvements generally because its underlying design encourages code well suited for taking advantage of concurrency generally. Edit to add: I hadn’t initially thought to speculate on the language itself taking advantage, but it occurred to me immediately after posting this comment. Another potential benefit is that many of its fundamental abstractions (most collection APIs are declarative) lend really well to making those operations concurrent, which is a common FP/lisp hypothetical but becomes more tangible if coroutines are less expensive. This isn’t dissimilar to how RDBMS query planners can provide wild performance improvements without any semantic changes, because SQL queries express “what” now “how”.

chrisseaton 5y ago

Loom threads have the same basic semantics as normal threads. There's nothing special about them that relates to immutability.

lgessler 5y ago
I think GP's point is that immutable objects (which Clojure uses "by default") can be easily used in concurrent settings. Immutable objects can be shared without concern between threads, whereas mutable objects may need to be copied or have their operations synchronized somehow.
- chrisseaton 5y ago
  > may need to be copied or have their operations synchronized somehow Maybe through some kind of non-preemptive user-space scheduling you mean?
  - opnitro 5y ago
    Right, but you'd still need to synchronize that with some concurrency primitives (like a mutex or semaphore) and that has the potential for bugs. Whereas on an immutable structure can't suffer from that problem, which can make concurrent programming easier to reason about.
    - chrisseaton 5y ago
      > Right, but you'd still need to synchronize that with some concurrency primitives (like a mutex or semaphore) Why? If you know your thread won't be interleaved with any other until you a well-defined point, how's that different to using a mutex or semaphore?
      - MobiusHorizons 5y ago
        IIUC, Loom threads can be scheduled across multiple OS threads (much like go-routines), so there is (at least the possibility of) real concurrency going on.

whalesalad 5y ago

I think a Clojure with first class legitimate actor semantics would be unreal. Clojure core will espouse async and tell you why actors are bad but man I love the actor model.

weatherlight 5y ago
https://www.clojerl.org https://www.clojerl.org Clojure for the Erlang VM :)

klysm 5y ago

I’d think it would also make a huge difference for Akka.