[bradfordcross]

I am not calling concurrency a fad, I am calling the rush to try hot new concurrency primitives without understanding these basic tradeoffs a fad.

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.

[sausagefeet]

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

Your post seemed very light on actually discussing this point, which I think would have been appreciated. There are always a lot of trade-offs to be made in writing concurrent code. The shallowness of your post left me wondering why you made some of your choices, or if you even thought particularly hard about them.

[prospero]

Not using transactions effectively forces anyone who wants to call into your code to also not use transactions, or they'll be bitten by the retry behavior.

This may not apply to your library (it seems like maybe it only calls code, rather than being called by it), but the approach you're suggesting can greatly reduce the utility of a library for other people if you're not careful.