Sto imparando Clojure per vedere se è qualcosa che posso sfruttare al mio attuale lavoro, e ancora più importante, come posso convincere i miei capi che Clojure ha un 'killer feature' su java che fa valere l'investimento 1 .
La funzione che presumo che la maggior parte degli evangelisti clojuri sarebbe la gestione dello stato e la concorrenza .
L'esempio che vedo spesso nei blog e nei libri è un saldo dell'account che viene aggiornato da più thread. La gestione dello stato di Clojure può sempre garantire in modo pulito che il saldo sia accurato indipendentemente dal numero di thread che leggono e scrivono quel valore.
In pratica, però, un'applicazione non consentirebbe mai un saldo del conto di vivere solo in memoria, dovrebbe essere persistente al di fuori della JVM (probabilmente in un database) per due ragioni, ovviamene ovvie:
- Se l'app si interrompe, il database dovrà riflettere accuratamente l'ultimo stato di recupero. Per questo motivo, il database non può essere aggiornato in modo asincrono e tutte le letture dovrebbero essere bloccate fino al completamento dell'aggiornamento del database.
- Se altre applicazioni stanno leggendo o manipolare il saldo dell'account (forse perché abbiamo ridimensionato la nostra app su diversi server), tale saldo deve essere tenuto sincronizzato tra tutte le istanze.
La gestione dello stato di Clojure può gestire situazioni come questa in modo elegante? Ad esempio, dato lo scenario 2 sopra, le letture tutte del saldo dell'account dovrebbero prima controllare il database per ottenere il valore, e se il database è bloccato, dovrebbe bloccare fino a quando non è disponibile il valore corretto, no?
È fantastico che Clojure gestisca la concorrenza in-memory in modo molto elegante, ma se quell'eleganza non può essere estesa allo stato esterno, allora guadagno davvero qualcosa?
1 (si noti che cose come espressività, eleganza, ecc. sono raramente considerate caratteristiche killer di mgmt.)