Intervista a Francesco Cesarini di Erlang Solutions

A language that doesn’t affect the way you think about programming, is not worth knowing.
Yale Professor Alan Perlis

In occasione dell’Elixir Conf siamo lieti di pubblicare una intervista con Francesco Cesarini.  Nel 2009 abbiamo già recensito Erlang Programming A Concurrent Approach to Software Development” scritto a quattro mani con Simon Thompson. Ora siamo lieti di ospitare una intervista ad ampio respiro con una delle colonne portati di Erlang Solutions.

D: Quale è stato il tuo percorso professionale e formativo? Come sei approdato ad Erlang?
Francesco: Nel ’94, mentre ero studente di informatica presso l’Università di Uppsala, il professore e’ entrato in aula e ha detto: “Questo e’ il libro, leggetelo! Questi sono gli esercizi, fateli!”. Poi ha incominciato a parlarci degli orrori della programmazione parallela: deadlocks, shared memory, critical sections, etc. Il libro in question era la prima edizione di “Concurrent Programming in Erlang” e gli esercizi si basavano su un mondo virtuale fatto di carote, conigli e lupi. Le carote crescevano, e venivano mangiate dai conigli. I lupi mangiavano i conigli. Se i lupi e i conigli mangiavano tanto, si moltiplicavano. Se non mangiavano, morivano. I conigli comunicavano con altri conigli entro un certo raggio ogni qualvolta trovavano carote o avvistavano lupi. I lupi facevano lo stesso con gli altri lupi, avvertendoli della presenza dei conigli. Lo scopo dell’esercizio era quello di bilanciare la simulazione, giocando con i parametri a disposizione. Ho impiegato 40 ore a risolvere il problema. Ogni lupo e coniglio corrispondeva ad un processo e ricordo ancora la meraviglia di quando, avendo fatto un “ps -ef”, mi son ritrovato davanti un solo thread, quello della macchina virtuale, e non un thread per ogni animale.
Qualche mese dopo, studiando programmazione OO, mi hanno dato lo stesso problema da risolvere. Questa volta eravamo in due a lavorare insieme usando Eiffel, un linguaggio OO molto interessante. Pur avendo riutilizzato molti degli algoritmi, abbiamo impiegato 60 ore a completate il lavoro, 120 in totale. Il triplo del tempo! E’ stato allora che mi sono reso conto di come la scelta di un linguaggio di programmazione adatto al problema che si deve risolvere possa aumentare la produttività di un team di sviluppatori. Ho preso il telefono e chiamato Joe Armstrong – l’inventore di Erlang – chiedendo se c’era la possibilità di un tirocino presso il laboratorio di ricerca software della Ericsson. Da li, sappiamo come e’ andata a finire.
D:Una domanda su Erlang Solutions. Chi siete e di cosa vi occupate al momento?  Ho conosciuto un ragazzo siciliano che dopo la laurea specialistica (e un erasums in finlandia) era venuto a fare un colloquio di lavoro presso do voi, e la sua impressione era che foste una realtà dinamica ed in espansione. 

Noi ci occupiamo di servizi professionali attorno ad Erlang. Offriamo attraverso un contratto esclusivo con la Ericsson suopporto sul linguaggio, le librerie e la macchina virtuale, formazione tecnica (incluso e-learning e certificazione), consulenze e sviluppo software. Ci occupiamo di conferenze, le piu grandi essendo CodeMesh a Londra, una conferenza sulla programmazione distribuita e funzionale, Erlang User Conference a Stoccolma e Erlang Factory a San Francisco. Come prodotti, rivendiamo la database NoSQL Riak e abbiamo MongooseIM, un server XMPP usato per servizi messaging.

Inoltre, abbiamo recentemente lanciato WombatOAM, un sistema che si occupa di operation, administration e maintainence di sistemi Erlang, facilitandone l’integrazione con sistemi di monitoraggio tipo Graphite, Zabbix or Nagios. Risolviamo una volta per tutte la parte generica del codice per mantenere e monitorare sistemi.
In fine, siamo attivi in diversi progetti di ricerca, da multi-core e parallelismo ed embedded assieme ad Università Europee. Erlang Solutions consiste di 80 impiegati con sede a Londra ed uffici a Stoccolma, Cracovia e Budapest. Ci stiamo allargando negli Stati Uniti, dove prevediamo di aprire un ufficio nei prossimi mesi. Stiamo assumendo, quindi se siete appassionati di linguaggi funzionali e distribuiti, fatevi vivi.

D: Dal mio punto di vista la tua esperienza è simile a persone come Massimo Banzi (il co-creatore di Arduino): figure professionali riconosciute in tutto il mondo che hanno creato qualcosa di innovativo. Il tuo esempio dovrebbe essere d’ispirazione a chi cerca di creare nuove startup in Italia perché avete creato cose concrete che non rischiano di passare di moda. Ti riconosci in questo profilo? E che consigli puoi dare ai giovani italiani sempre più spesso disoccupati o sottopagati?
R:Ti ringrazio, ma chiamandomi una “figura internazionale riconosciuta in tutto il mondo” mi metti in imbarazzo. Non ho ancora avuto l’opportunità di conoscere Massimo, ma suppongo che, come me, sia una delle tante persone cui piace condividere la propria conoscenza con gli altri, insegnando e scrivendo libri, con passione per il proprio lavoro e per tutto cio’ che si fa. Questo e’ il profilo in cui mi riconosco e spero possa dare ispirazione ad altri.
La situazione in Italia e’ tragica. Il consiglio migliore che posso dare e’ quello di imparare una seconda e, se possibile, persino una terza lingua per poter interagire e facilitare i contatti con altri Paesi dove l’economia e piu’ attiva ed il sistema meno corrotto. E da li, innovazione, imprenditoria e passione. Lamentarsi o dare la colpa a terzi non crea lavoro. Bisogna cambiare il modo di fare e trovare modi alternativi per  uscire da questo buco.
D:Se dovessi citare i software scritti in Erlang al momento più importanti chi includeresti nella lista (Riak, CouchDB, RabbitMQ, Kai…) e in che ordine di importanza?
Come software open source, io direi RabbitMQ, Riak, MongooseIM (riscrittura di Ejabberd) e CouchDB sono i progetti più usati. Prodotti non open source ma più conosciuti includono WhatsApp, Chef e il sistema di fatturazione di Klarna. Erlang e’ il motore di GitHub Pages e di software di aziende come OpenX, AdRoll e AdTech (AOL) che ogni giorno servono miliardi di annunci su siti web. O di sistemi SMS. In Inghilterra, la maggior parte delle votazioni televisive passano tramite sistemi Erlang. Il 40% del traffico dati degli smartphones e’ controllato da Erlang, visto che nell’infrastruttura Ericsson (che ha il 40% del mercato mondiale) il GGSN, il SGSN ed il MME che controllano sistemi GPRS, 3G ed LTE sono tutti implementati in Erlang.
D:Ora una domanda scomoda. La mia esperienza con Erlang si è arenata per un paio di ragioni: la prima è la sintassi del linguaggio sembra progettata per “remarare contro” ogni tanto, per esempio richiede due fine linea diversi a seconda che l’istruzione sia l’ultima di un blocco oppure no.
Per cui nel classico ciclo, edito, commento, provo & riprovo si sente parecchia scomodità.
Non sei il primo a dirlo. Credo che molto dipenda dagli altri linguaggi di programmazione cui uno sviluppatore e’ stato esposto ed e abituato ad usare. Quando ho imparato Erlang conoscevo LISP, Prolog, ML e C e non ho avuto alcun problema con la sintassi. La sintassi di un linguaggio e’ un modo di “impacchettare” il prodotto. Qualcuno preferisce una confezione semplice, altri la preferiscono colorata, variopinta. C’e’ poi chi preferisce una confezione con una foto.
Quello che e’ importante non e’ tanto la confezione di un linguaggio (la sintassi), ma il contenuto (la semantica). Erlang ha come contenuto processi light-weight, assenza di memoria condivisa, passaggio di messaggi asincrono, canali d’errore dedicati ed asincroni, supporto nativo per la distribuzione. Senza la semantica, la sintassi non ha nessuna importanza. Tuttavia, capisco che per molti, la confezione del prodotto sia importante, specialmente se il contenuto e tra i migliori. Facilita la scelta e la transizione. Per questo sono molto contento per cio’ che sta succedendo con Elixir, una lingua influenzata da Erlang e Ruby.
 D:Le ragioni secondarie sono ben delineate in questo articolo  in cui mi sono riconosciuto:
Per esempio
“Another problem is records often feel like a tacked-on hack. […]
Records are a compile time feature — not a VM feature — and are statically compiled down to regular tuples, with the first slot holding the record name atom, and each slot N + 1 corresponding to the Nth entry in record declaration.”
La conseguenza è che i record così come sono sono strutture dati anonime e un po’ deboli.
Hai perfettamente ragione, e per quanto riguarda i record mi trovi completamente d’accordo con Damien. I record sono stati aggiunti nel 1995 e, se c’e’ qualcosa di orrendo, sono proprio loro. Il problema e’ di origine storica. Nel 1995, non potevano aggiungere datatypes nuovi, visto che i bits nella variabile che denotavano il datatypes nella macchina virtuale erano stati tutti usati. L’unica soluzione era di convertire i records in tuple. Quando poi il problema dei bits e’ stato risolto, i record non sono mai stati ripuliti. La buona notizia e’ che a partite dalla release R17 sono stati aggiunti i records “dinamici”, chiamati maps. L’altra cosa orribile, ma incredibilmente potente, sono le match specifications. Per fortuna, sono in pochi ad usarle.
D:Il tipo di ragionamento che devi impiegare in Erlang è abbastanza diverso sia dalla programmazione imperativa che…impera con linguaggi come Ruby,Python,JavaScript, Java sia da linguaggi funzionali vecchia maniera come Lisp. Richiede quindi uno sforzo mentale passare da Java a Erlang che non puoi fare nelle pause pranzo, mentre magari fai consulenza(…ogni riferimento al sottoscritto è puramente voluto…!).
Il problema dello sforzo mentale non e’ tanto quello di come uno ragiona in Erlang. Se negli ultimi 10 anni hai lavorato con una metodologia OO, avrai problemi a cambiare il modo in cui ragioni. Io avrei lo stesso problema se domani dovessi incominciare ad usare Java. Studi effettuati dalla Ericsson dimostrano che uno studente appena laureato in informatica che di recente ha usato molti linguaggi diventa produttivo in un mese. Un impiegato che ha circa 10 anni di esperienza ma ha usato un solo linguaggio ci mette tre mesi.
Non solo, se ci pensi bene, il modo di ragionare in Erlang e’ naturale. Le regole di Joe Armstrong sono le seguenti: Il mondo e parallelo. Le persone nel mondo comunicano mediante messaggi asincroni. Le persone non condividono la memoria. E le cose falliscono. Adesso prova a modellare un linguaggio di programmazione attorno a queste regole. Il risultato e Erlang!
Il secondo problema e’ nell’educazione che uno riceve nelle università. Programmazione OO, funzionale, logica, imperativa, parallela e distribuita creano le fondamenta di tutti i linguaggi di programmazione. Se non ti hanno insegnato *tutti* questi modi di architetturare il tuo codice e di ragionare e – ancora più importante – se non ti hanno insegnato a saltare da un modo di ragionare all’altro, non hanno fatto bene il proprio lavoro.
D:La mancanza di una tipizzazione statica forte può essere considerato l’ultimo “neo” di Erlang, ma a mio avviso non è tanto grave: Lisp ha sempre avuto questa caratteristica e tentativi in direzione opposta (per esempio Scala ma anche Haskell) hanno portato a linguaggi che a mio avviso sono complessi da comprendere a fondo (purtroppo). Le curve di apprendimento di Scala e Haskell sono ripide.
E’ considerato un neo da quelli che non usano Erlang o altri linguaggi dinamici. Il type system esiste, ma e’ opzionale. Kostis Sagonas e i suoi ricercatori hanno fatto un lavoro stupendo con Dialyzer e Typer. Secondo, una tipizzazione dinamica fornisce vantaggi come il software upgrade in tempo reale (cosa che nessu altro linguaggio di programmazione mainstream offre). I bugs che risultano da una tipizzazione dinamica sono molto rari. Usando approcci TDD e programmando in maniera bottom-up, quando il codice va in produzione, la maggior parte dei bachi sono stati risolti. Studi hanno dimostrato che il numero di bugs con linguaggi con tipizzazzione statica per righe di codice sono piu o meno gli stessi. Sono tipi bugs diversi, ma sono sempre li.
D:Elixir rappresenta una ventata di “aria fresca” dal punto di vista sintattico e “lower the bar”, abbassa le difficoltà che i neofiti possono incontrare approcciando l’Erlang Universe. Cosa ne pensi?
Per chi conosceva C, dicevano che imparare C++ sarebbe stato facile. Per chi conosceva C++, imparare Java sarebbe stato facile. Oggi, dicono che per chi conosce Java, imparare Scala sia facile. Quindi, se conosci Ruby, imparare Elixir e’ facile. Non sono d’accordo. Per capire Elixir, devi capire la semantica dei programmi paralleli. Capire come strutturare i processi , gli alberi di supervisione e il recupero dagli errori. Pensare che sia piu facile è un sbagliato, anche se aiuta psicologicamente. Ma sono d’accordo sulla ventata d’aria fresca. Erlang aveva bisogno di essere riconfezionato per attirare una nuova generazione di programmatori. Jose Valim ha fatto un ottimo lavoro… Anche se devo dire che la sintassi e’ un po strana :-)
D: Di Erlang apprezzo l’uso dei simboli che consente di scrivere codice funzionale esplicito, anche più di Lisp. Unito alla focalizzazione sul “processo” questo consente un approccio molto snello, almeno per risolvere problemi di natura algoritmica (implementazioni di stack, liste ecc).
Erlang e’ adatto a risolvere problemi concorrenti. Pensiamo per un momento ad un sistema per contare voti televisivi inviati via SMS. Per ogni SMS crei un processo. O ad un sistema di chat tipo quello di Skype o WhatsApp. Per ogni messaggio, crei un processo. Pensiamo ad un web server, dove per ogni richiesta o websocket aperto crei un processo. Questi non sono problemi algoritmici, ma concorrenti.
Erlang ti semplifica il modo di ragionare, perché devi pensare solo ad un’istanza del processo. E se il processo fallisce, tutte le altre richieste continuano ad eseguire.
D:Elixir è costruito intorno all’uso di macro “hygenic” che consentono di estendere il linguaggio creando costrutti atti a emulare LINQ (vedi le librerie come ecto). Questo da ad Elixir una marcia in più perché gli consente di aere quella “synatx sugar” che tanto manca ad Erlang?Oppure ritieni altre le caratteristiche salienti di Elixir?
Estendere Elixir (o qualsiasi altro linguaggio) e’ una proposizione potente, ma molto pericolosa. Persino Jose Valim consiglia di utilizzare questa funzionalità solo per la creazione di frameworks tipo OTP, ma non messo in mano agli sviluppatori e usato come stile di programmazione. C’e’ il rischio che il codice diventi cosi astratto che nemmeno la persona che lo ha scritto riesce a capire cosa stia succedendo. Tutto cio’ potrebbe diventare uno dei peggiori incubi di chi mantiene il codice. Ma se usato con attenzione, e’ un costruttore molto potente. Con Erlang, non c’e’ mai mancato. Nei frameworks, abbiamo risolto questi problemi usando parse transforms e librerie software.
D: Una domanda sulle performance di Erlang. Al momento là ErlangVM è interpretata  o dispone di un Just in time compiler? Mi è sembrato di capire che fosse stato scritto un JIT tempo fa (HiPE) ma non ho mai capito se è stato poi integrato di default oppure vada attivato in qualche modo.
HiPE (High Performance Erlang) e stato sviluppato dal’ Università di Uppsala e fa parte della distribuzione Erlang mantenuta dalla Ericsson. Ti da’ vantaggi su i tempi di esecuzione del codice sequenziale. Va attivato attraverso parametri di configurazione della macchina virtuale e compilando il codice. I risultati generici del progetto di ricerca sono stati integrati nella macchina virtuale, spesso pure prima che gli accademici riuscissero a pubblicarne i risultati. SICS (The Swedish Institute of Computer Science) sta tuttora sviluppando un compilatore JIT che è stato presentato in diverse conferenze. Speriamo che lo integrino presto.

Per premiare  chi ci ha seguito fino in fondo,  con il codice promozionale authd potete accedere alla Early Release di ‘Designing for Scalabillity with Erlang/OTP‘ con uno sconto del 50% sulla edizione elettronica e del 40% su quella cartacea.