Exactly. The important part isn't that Clojure has implementations of concurrency primitives, but that it has language semantics for defining when/how state may change.

The problem is, those primitives don't work in all cases. Believing otherwise would violate CAP. Avout is extremely impressive and I imagine I'll use it one day, but sooner or later you're probably going to want something like Rust's semantics _in addition_ to STM.

Clojure is brilliant because it even thinks about these problems, but even in the global mutable state arena where it excels there's things like concurrent hash tables where the advice is to use Java's existing solution.

I don't think CAP applies to the proposed scenario (architecture with large number of cores on single chip) unless cores can lose connection and each core needs to accept the update to guarantee consistency. I'm unclear on the whole "incoherent memory" architecture. I think that would be sort of useless, what I think will happen is there will be high latency path to do global atomic operations and low latency for cached/local, ideal for COW/STM architecture.

But it's difficult to know with fictional architectures :)

Well, strictly speaking the future's already here in the form of GPUs. It's just that we don't know what to do with them. But even if you ignore partition problems, synchronizing 1000 cores is a performance problem unlike synchronizing 8. It may be that we need explicit state that never leaves a processor.

But when do you actually need to synchronize all 1000 cores ? It's not like 1000 cores try to update same entity at one time, work will likely be map-reduce style (and there are plenty of things to do with it, speech recognition, voice synthesis, image analysis, etc.)

GPU have different issues, separate memory space, esoteric programming tools, doubles aren't IEEE compatible if available, no ECC. IIRC they aren't even suitable for things like ray-tracing, CPU implementations outperformed GPU based ray-tracers last time I checked. GPU's grew out of special purpose hardware and it shows, I don't think they are necessarily representative of the future architectures.

If you had a x86 or ARM chip with 100 cores and different instructions for atomic operations it would be a different story.

I agree, the most useful parallel implementation is nearly always mapreduce or pipes and filters. At the moment, Clojure's not that great for pipes and filters. The STM solution is brilliant, but atm it's all or nothing. The Rust model of being able to transmit something which ceases to be valid on the sending thread would be a useful addition to the current semantics. I think they're still thinking about the correct abstraction for event streams.