Il saggio progetto svedese, rinato: Elixir e Phoenix

This entry is part 1 of 19 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.

 

 

Finding the good one: mithril

I have just read this insightful statement on this blog article about congitive load in Javascript

jQuery is undoubtedly useful when dealing with browser quirks, but once an application grows over a few thousand lines of code, unstructured jQuery code simply becomes too difficult to maintain, and you start needing the discipline of a framework to organize code. But when you’re at tens of thousands of lines of code, you start to run out of entity types to CRUD, and your application growth starts to build on top of existing concepts. This is when you need the mental shift from being a library consumer to being a reusable component author,

This clever guy is the creator of Mithril, a very small, well crafted javascript library a friend of mine pointed to (via github…):

Mithril is a client-side MVC framework – a tool to organize code in a way that is easy to think about and to maintain.

From my huble point of view Mithril is a all-javascript library, focused on MVC and minimal AJAX. In Mithril even the html part is built in Javascript. It seems a bad route, but I must admit it rocks a lot when you give it a try.

The second generation (jQuery) and third generation javascript library (ReactJS, AngularJS, knockout, etc) all suffers from a big dichotomy between the html template and the event code. It seems all clear on small use cases. Some library also “compile” templates. Sometime I think: “wait a moment, I am fighting with the GUI, or the GUI is part of my code?”.

It easy to think jQuery is unusable when your interface grows: you need some MVC system. So you pass to AngularJS. But The concept below angular a lot, and the reward seems always a bit less. I have no time and re-learning angular or KnockoutJS every time is a big deal.

Mithril is very easy to remember: a recursive, solid, functional-filter based approach.

I cannot stop to suggest you to give it a try.

RaspberryPi 2: The perfect box for your backpack

After my two children grow a little, I have some spare time to play with RaspberryPi. I have bought a Raspberry Pi 2 Model B, a very neat and compact machine with 1GB of RAM, and a quad-core ARM chip on it.

I was looking for an easy-to-carry unix box, and I was wrong: raspberry pi can be a lot more than that.nippon-gio

Continue reading “RaspberryPi 2: The perfect box for your backpack”

RaspberryPi 2 Model B SD Life Extender

I am a very happy owner of a RaspberryPi Model B 2, a quad core ARMv7  computation unit for a price between 45 and 35 €.

If you plug only a network cable it can be powered by a USB port of your router (!avoid putting on it other USB stuff, because the energy drain can be too much).

RaspberryPI  is a perfect all-time-running machine, just follow this smart guide…

Continue reading “RaspberryPi 2 Model B SD Life Extender”