Recuperare Erlang
Erlang è un linguaggio a mio avviso sottostimato, che ha parecchie cose da insegnare ai vari Scala/Rust/Java(Script) out of there... In particolare ci sono un insieme di feature di Erlang che prese singolarmente non sono difficili da comprendere e implementare, ma è l'insieme delle idee fondanti di Erlang che lo rende assai diverso dagli altri.
Erlang ha:
- Una sintassi che prevede che le variabili possano essere assegnate una volta sola. Questo rende side-effect free il suo codice (almeno dal punto di vista formale). Però non è ostico come linguaggi che non prevedono variabili oppure le prevedono mutabilil.
- Poiché le strutture dati (e quindi i messaggi tra processi) sono immutabili, l'invio di un messaggio si traduce nel copiare un messaggio dal chiamante al ricevente, tra aree non-condivise (e quindi senza mutex).
- Poiché i processi sono side effect-free e state-less, e poiché i messaggi sono tutti asincroni, è molto facile gestire un errore che genera il crash di un processo: cioé è sufficiente far ripartire il processo in crash senza bisogno di ricostruitire il suo stato (perché....non lo ha!).
- Ricorsivamente, se un processo che va in crash ne fa morire altri, è facile ricostruirli tutti. Poiché i messaggi sono asincroni, un errore di comunicazione si traduce in un semplice "rallentamento". Un errore che si verifica casualmente (per un bug molto subdolo per esempio) si traduce anch'esso in un "rallentamento".
- Erlang minimizza la latenza di risposta, e questo porta automaticamente a massimizzare l'utilizzo dei pool di risorse ed il throughput. Per esempio in ErZauker (una applicazione che ho scritto e che ha un numero massimo di connessioni a Redis) Erlang finiva per usare sempre il 100% delle connessioni disponibili, e teneva questo valore sempre al massimo.
- Poiché per ogni problema l'approccio è creare processi leggeri, la ErlangVM è facilitata nel minimizzare la latenza poiché può agire su un numero sempre maggiore di message queues per fare il tuning. Se per assurdo tutto fosse fatto da un processo solo, non sarebbe possibile massimizzare la latenza.
- E' banale in Erlang definire le startegie di recovery, tanto che i supervisori "generici" sono codificati e già forniti
- Erlang è uno dei pochi linguaggi full-stack production ready. Potete esporre una applicazione Erlang direttamente su internet, con il web server in Erlang, il db in Erlang ecc Di converso con Python/Ruby/Java ciò non è possibile/consigliabile.
Ognuno delle due visioni del mondo ha pro e contro, tra i punti di debolezza di Erlang rileviamo:
- Erlang per lunghissimo tempo non ha avuto una struttura dati di tipo record "vera" ma tuple indicizzate dal compilatore (l'ultima versione introduce finalmente il tipo "map").
- Benché abbia un compilatore di codice nativo (HiPe), Erlang risulta molto più lento di Java e di altri linguaggi: può compensare girando su più macchine (è banale rilocare un processo!).
Riferimenti
http://www.erlang.org/doc/efficiency_guide/processes.html
Comment by Andrea on 2015-07-22 15:01:47
Un nuovo linguaggio ispirato basato su Erlang ... http://elixir-lang.org/