3 ms·

> sometimes it is necessary in high performance multi—threaded/multi-processor environments to use side effects judiciously The short answer is: Clojure (and o

by _bxg1 7y ago

> sometimes it is necessary in high performance multi—threaded/multi-processor environments to use side effects judiciously The short answer is: Clojure (and other languages/frameworks that emphasize immutability) is not intended for those use-cases. The long answer is, Clojure added something called "transient data structures" as a trap-door for cases where you really absolutely need mutability for performance: https://clojure.org/reference/transients https://clojure.org/reference/transients But they are really intended to be the exception, not the rule. Enforced immutability is a conscious choice you make to trade some performance for increased robustness. Also, compared to "immutability by convention", enforced immutability allows certain optimizations to be made that greatly decrease the wasted memory and allocation/deallocation that would occur if you naively cloned everything.

abrax3141 7y ago
I haven’t really thought this through, but at the OS level we used to have the concept of reentrancy, which separated code from variables for multi-tasking. I haven’t seen this exact concept in a programming language level, although I don’t know every language, and it may exist by another name. I didn’t really think about this until now, but I naturally write reentrantly, separating the hash tables and globals For cross thread data, and writing everything else functionally, and/or using the thread system to manage all other mutables as locals (like the transient construct, I guess).
- _bxg1 7y ago
  I think the idiom in Clojure is for threads to be functional, so they aren't running persistently and mutating shared state: they spin off to do nonblocking work and then return their result. While doing so they share memory so as to avoid serialization/cloning overhead, but that shared memory is an immutable data structure, so you don't really have to worry about race conditions because threads can't step on each other's toes.

by _bxg1 7y ago

abrax3141 7y ago

I haven’t really thought this through, but at the OS level we used to have the concept of reentrancy, which separated code from variables for multi-tasking. I haven’t seen this exact concept in a programming language level, although I don’t know every language, and it may exist by another name. I didn’t really think about this until now, but I naturally write reentrantly, separating the hash tables and globals For cross thread data, and writing everything else functionally, and/or using the thread system to manage all other mutables as locals (like the transient construct, I guess).

_bxg1 7y ago
I think the idiom in Clojure is for threads to be functional, so they aren't running persistently and mutating shared state: they spin off to do nonblocking work and then return their result. While doing so they share memory so as to avoid serialization/cloning overhead, but that shared memory is an immutable data structure, so you don't really have to worry about race conditions because threads can't step on each other's toes.