3 ms·
Just so people don't get the wrong idea, AFAICT STM isn't used that much in production Clojure (unlike say Haskell). This I chalk up to the lack of a couple cru
by dwohnitmok 7y ago
Just so people don't get the wrong idea, AFAICT STM isn't used that much in production Clojure (unlike say Haskell). This I chalk up to the lack of a couple crucial operators in Clojure's STM. Instead the usual method for dealing with concurrency is atoms. Note that once you get familiar with how to use atoms to structure concurrency, this is a lesson that is widely applicable. You can, for example, write essentially the same code in Java with an AtomicReference (how atoms are implemented anyways) as long as you take care to only put immutable data structures in the ref.
I would personally sum up Clojure's main impact on my own programming in two ways.
1. 90% of the time you just need immutable maps, sets, vectors, and primitives. Fancy custom classes and custom higher order functions usually aren't needed.
2. Wishing more things had on-the-fly editing of a running program.
- arohner 7y agoIn my experience, STM isn't used because it's very rare to have situations where you need STM but don't need durability. In most production situations, you need to record state changes in a DB or an event log. In that case, the source of truth is now the DB, and your in-memory values are immutable snapshots. The other reason is that Clojure code is usually well-factored, and most clojurians have listened to Rich and simplified their programs. Not many problems require STM transactions across multiple refs. If you don't have multiple refs changing transactionally, you can use atoms instead for a performance benefit.