Brian Marick <mar...@exampler.com> writes: > Which raises the question: *is* concurrency actually a strong selling > point for functional languages?
It definitely was/is for me. I'd avoided threads for most of my career-to-date because in imperative languages any thread could mutate any value to be anything at any point. This is difficult to reason about when the code is written correctly, and then in C you have the added fun that an error could lead to that malevolent thread writing to absolutely any address in memory. Complete undebuggable madness! So I'd generally reached for processes in order to achieve concurrency. Using processes doesn't get rid of deadlocks etc, and introduces additional copying overhead if e.g. communicating over pipes, but does shrink the problem one needs to think about down to just the set of mechanisms explicitly used to communicate between the processes. IMHO, FP in general and Clojure in particular does two big things regarding concurrency: (1) By using immutable values, provides the same "conceptual shrinking" as using processes does in imperative languages, only without (well, with reduced) copying overhead. The concurrency problem is limited to just the interactions over the relatively small number of explicit concurrency points. (2) The ability to build higher-order concurrency abstractions which completely encapsulate recurring patterns. When using pure functions on immutable data, e.g. `pmap` and `reducers/fold` really do give you auto-concurrency for certain patterns of concurrent operations. Just my 2 cents, -Marshall -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en