|
|
|
|
|
by gshayban
5763 days ago
|
|
Agreed. The author supports going outside of Clojure for larger scale processing, e.g. Hadoop. This is sensible, but it's some leap to call concurrency a fad. It's likely that Clojure will target some other runtime (in the future). Concurrency primitives in Clojure (var, ref, atom, agent, future, promise etc.) are practical, elegant, and focused tools. Why work around them? |
|
Clojure's concurrency primitives are just wrappers around the same java libs I mention in the post.
For locking, it just matters which code you depend on based on your need. If you need to deal with it yourself, using Clojure's STM is good, since Rich has done the work to wrap the locking. But if you just need a data structure with synchronized access, then you don't even need Clojure's STM. Similar arguments hold for Agents vs Executors.
I am not saying Clojure's concurrency primitives are bad, I am saying we need to understand the basics, and Clojure's primitves are not always necessary or the right solution.