!Support Ukraine!

Posted in English Content, Italian Content | Leave a comment

Erlang & la resilienza con pattern matching e processi

Cosa ci insegna Erlang sulla resilienza, in un periodo in cui ce ne è molto bisogno?

Erlang è un linguaggio open source nato nel 1986 alla Ericsson, di tipo funzionale, concorrente,  dinamicamente tipato, general purpose e soprattutto costruito per essere “resiliente” sia dai primi giorni della sua nascita.

E’ il motore dietro RabbitMQ e CouchDB, e nell’ultima versione ha un nuovo Just In Time Compiler (JIT) che migliora le performance.

Continue reading

Posted in Erlang, Italian Content | Tagged | Comments Off on Erlang & la resilienza con pattern matching e processi

IoT Async

Qualche mese fa avevo sviluppato una applicazione IoT per misurare la temperatura e spedire i dati ad una coda mqtt.
Poi c’era uns server che collezionava i dati.
Totale: tre server, con tre punti di fallimento ma architettura molto “cool”

In effetti però la potenza dei moderni chip embedded è tale che è possibile implementare una soluzione completamente asincrona “alla Erlang”.
Con meno di 8 euro, potete procuravi il chip esp8266 su Amazon

con relativo sensore

e poi sviluppare un servizio micropython che vi notifichi il cambio di temperatura in modo asincrono.

L’idea è che chi è interessato alla temperatura si “registri” sul disposivo IoT con qualcosa come

curl http://esp8266/subTemp/$callerHostname/$desideredPort/$callerRef
# Esempio attualizzato
curl http://esp8266/subTemp/mypc/7001/pushTemp

Dopodiché sarà il dispositivo IoT con i suoi tempi (per esempio dettati dalla funzionalità del sensore, ecc) a fare una chiamata all’ indietro  (callback) del tipo

http://callerHostname:desideredPort/callerRef/$temperature/$humidity
# Esempio attualizzato
http://mypc:7001/pushTemp/23/84

Per semplicità le chiamate sono in GET (benché dovrebbero essere delle POST).

L’agente interessato a tale misure può essere un server scritto in nodejs, python o ruby e può anche richiedere la notifica ad un server terzo (per es esposto su Internet), per es sottoscrivendolo con qualcosa come

curl http://esp8266/subTemp/serverPippo/80/sendTemperatureAndHumidity
Posted in English Content, Erlang, Esp8266 | Comments Off on IoT Async

Il saggio progetto svedese, rinato: Elixir e Phoenix

This entry is part 1 of 18 in the series Programming Languages

Negli ultimi 20 anni sono successe tante cose imprevedibili. Nel 1995 nasce Java. Nello stesso periodo nasce Erlang. Java inizialmente segue la strada culturale tracciata da Sun, e si configura come un linguaggio estremamente verboso, con API specifiche per la gestione della concorrenza (es keyword synchronized per gestire nativamente le zone critiche che necessitano di mutex). Inzialmente Java è per far girare applet, poi Sun presenta un chip ad hoc (picoJava) poi IBM ci mette del suo e il linguaggio si trasforma in una ottima piattaforma per lo sviluppo server side.

Nel corso di questi 20 anni Java ha cambiato pelle almeno tre volte (applet, enterprise e ora macchina virtuale come base per linguaggi come Scala e Clojure). Le sue ultime evoluzioni hanno tradito un po’ le sue origini: sono stati introdotti i template (considerati “troppo complessi” nei tutorial del 1995!) e le “default implementation” nelle interfacce (una idea orripilante, ma tant’é….).

Mantenere tutta la retro compatibilità sta portando Java a diventare un linguaggio bizzarro: il codice scritto 6/10 anni fa ora si può riscrivere in modo completamente diverso.

Erlang ha scelto una strada diversa, è pensato per essere completamente asicrono e funzionale. Forse è stata solo fortuna, ma il piccolo linguaggio svedese ha retto bene alla prova del tempo, viene aggiornato circa una volta l’anno e anche se ha beneficiato di una frazione degli investimenti miliardari di Java, si dimostra efficace.

Al giorno d’oggi, dove anche un cellulare ha almeno un paio di processori, sviluppare sistemi che possano performare il meglio possibile su più processori è un must. E’ notizia di questi mesi che la Intel ha smesso di spingere la legge di moore (che consentiva un raddoppio della potenza dei processori ogni 18 mesi) a causa dei costi eccessivi che il processo di mignaturizzazione porta con sé. Si badi bene che ancora non abbiamo toccato il limite fisco teorico, è un problema di strategia e di costi.

In tutto questo scenario c’è Elixir, una evoluzione sintattica di Erlang con qualche buona freccia al suo arco, e un buon numero di librerie disponibili

Elixir svecchia la sintassi di Erlang lo rende più amichevole, è retro compatibile con le liberie Erlang e ha consentito la creazione di framework alla ruby on ralis chiamato Phoenix che sostiene di essere molto efficente.

C’è un aspetto critico che mi porta a insistere ogni anno su Erlang.

Quando facevamo l’università c’era un problema noto a tutti nello sviluppo di applicazioni client server (non necessariamente web).

C’erano due tipi sostanziali di tecniche:

  1. server multi richiesta multi processo
    Più semplici da programmare prevedevano la creazione di un nuovo thread per ogni richiesta in arrivo.
    Vantaggi: scala se hai tante richieste contemporanee, ma il costo associato alla creazione di un thread è molto alto.
    Ideale per task CPU Bound.
  2. server multi richiesta mono processo
    Più complessi e intricati da sviluppare, prevedevano un server che non si bloccava in attesa dei dati ma processava la prima socket client con dati pronti
    Vantaggi: scala bene se hai moltissime connessioni con parecchie latenze
    Ideal per sistemi I/O bound che non riescano a saturare il mono-processo.

Ora nessuna di queste due tecniche in realtà è migliore dell’altra, e in OOP non è banale bilanciare tra questi due approcci.
Per come è pensato Erlang però, è possibile avere i vantaggi di entrambe le teniche in un colpo solo!

Difatti l’architettura a processi stateless (anziché a istanze di classi su cui si “montano” thread) consente di sviluppare una macchina virtuale supervisore (un application server, per gli amanti di Java) che possa di volta in volta bilanciare tra l’esigenza (1) e (2).

Non è possibile ottenere questi vantaggi con un framework, come ha evidenziato il creatore di Erlang in un’email che ho ripreso tempo fa: si devono avere primitive di invio e ricezione di messaggi asincroni, innervate nella semantica del linguaggio.

Il fatto poi che Erlang sia funzionale e senza stato è stata la sinergia vincente. In caso di errore è banale far ripertire la parte di processi Erlang in errore; poiché sono privi di stato, l’anomalia viene limitata al caso critico.

Processi separati e senza stato consentono un Garbge Collector più semplice; in Java siamo dovuti arrivare al G1, la nuova implementazione a bassa latenza per risolvere alcuni problemi che i gestori di memoria automatici si portano dietro.

 

 

Posted in Erlang, IT Featured, Italian Content | Tagged , , , | Comments Off on Il saggio progetto svedese, rinato: Elixir e Phoenix

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:

  1. 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.
  2. 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).
  3. 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!).
  4. 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”.
  5. 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.
  6. 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.
  7. E’ banale in Erlang definire le startegie di recovery, tanto che i supervisori “generici” sono codificati e già forniti
  8. 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:

  1. 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”).
  2. 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

Posted in Erlang, Italian Content | Tagged , , | 1 Comment

Erlang: a lesson to learn…again!

Erlang is a great language.

[2019-UPDATE] Erlang 22 is OUT, so I wanna to come to the party!

On April 2015, Erlang father’s Joe Armstrong give us a very interesting lesson I want to tell about.

There was a long thread titled “Erlang and Akka, The Sequel” on the erlang mailing list, reasoning about the need of some standard pattern on Promises and Future. A lot of JavaScript libraries deal about that (also jQuery has its implementation). I want to report the Joe Amstrong reply because it give us a very clear understanding on the reason Erlang is different and you should at least try it once.

Continue reading

Posted in English Content, Erlang, Evergreen, IT Featured, Knowledgebase, Programming languages | Tagged , , | Comments Off on Erlang: a lesson to learn…again!

Rebar poor proxy git fixer

Sometimes you are behind a http proxy, and the git:// protocol is not accessible.

For instance on erlang rebar, all developers  prefer the git:// protocol when listing dependency.
But how to fix it if you are behind a http proxy?

Ask help to git…
[bash]
git config –global url.https://github.com/.insteadOf git://github.com/
[/bash]

Credits: http://erlang.org/pipermail/erlang-questions/2014-March/078402.html

Posted in English Content, Erlang, Knowledgebase | Tagged , , , , | Comments Off on Rebar poor proxy git fixer

Er Zauker v0.0.5: Let it go

Let it go, let it go!
Can’t hold it back any more.
Let it go, let it go!
Turn away and slam the door.

Let it go, let it go.
I am one with the wind and sky.
Let it go, let it go.
You’ll never see me cry.

(by Demi Lovato, “Frozen”)

I am very pleased to announce a revamped version of ErZauker, the code search engine based on Redis and Erlang. This version spots a lot of improvements over the last month, and hopefully squash a bunch of bugs.

This version should be able to rescan files faster and  consume much less redis space.

As usual comments and improvements suggestions are wellcome!

Posted in English Content, Erlang | Tagged , , | Comments Off on Er Zauker v0.0.5: Let it go