Hacker News Reader

Comment by chrisseaton | Hacker News Reader

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

View on HN

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.

> may need to be copied or have their operations synchronized somehow

Maybe through some kind of non-preemptive user-space scheduling you mean?

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.

> 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?

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.

That doesn’t solve the problem in parallel contexts, only for concurrent ones. But chances are you are not interested in running everything single-threaded.

Reply on news.ycombinator.com