Hacker News Reader

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.

View on HN

> 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