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.

 

 

Code Zauker 0.1.0: Code Young

I hear your heart beat to the beat of the drums
Oh what a shame that you came here with someone
So while you’re here in my arms
Let’s make the most of the night like we’re gonna Code young

 We’re gonna code young
We’re gonna code young

 Let’s make the most of the night like we’re gonna die young

Hi everyone! After months of complex stuff in other projects, I am happy to announce you CodeZauker 0.1.0, you code-based indexing system with redis backend for stunning performance.

This version of code zauker spots an auto-reindexing system & a new command, czlist.

CodeZauker will store a MD5 checksum for every file and reindex automatically changed files, greatly improving the indexing workflow.

czlist simplify integration with unix tool-chain. czlist access directly to code zauker core to show the filename which could contains the searchstring. czlist is ideal for IDE integration, or for simple inspection.

As usual, the new version is avaible as ruby gem, for your pleasure.

Version 0.1.0 is also easily deployable under ms-windows: I have removed C-based modules you can live without.
Tests with 64bit verison of redis looks great under ms-windows, but we keep suggesting Linux for production environments.

Tool Command Language: il papa’ di Java

E’ notizia fresca di stampa il rilascio di Tcl 8.6, che introduce parecchie novità a dispetto del fatto che sia una “minor” release.

 

In particolatre Tcl 8.6 introduce un motore “stackless”, integra nel linguaggio le estensioni OOP, ed aggiunge le coroutine.

Parliamo quindi diffusamente di Tcl, un linuaggio che ho sempre trascurato perché mi sembrava macchinoso e un po’ brutto/fatto  male…ma mi sono dovuto ricredere.

Continue reading “Tool Command Language: il papa’ di Java”

Cod Zauker Revenge: Code me maybe

Code Me Mabye

Hey, I just met you, and this is crazy 
But here’s my number, so call me maybe
And all the other boys, try to chase me, 
But here’s my number, so call me maybe

Code Zauker 0.0.9 is OUT

This release spot a optimized index (case sensitive search was stripped down to gain more space), and compatibility with er_zauker indexer (so you can span millions of server using Erlang ;)

Tips:

Erlang vs Ruby: Er Zauker

Negli ultimi mesi ho sviluppato un motore di ricerca per il codice, chiamato code zauker.

Lo ho scritto in Ruby e Redis. Ruby è un linguagio che conosco da tempo, ma housato molto poco. In questeultime settimane ho voluto riprendere in mano Erlang, e per esercizio ho provato a riscrivere il kernel del motore di indicizzazione in Erlang, creando ErZauker

In Erlang mi ritengo un neofita, anche se ho avuto la fortuna di leggermi (e recensire) uno dei due migliori manuali in circolazione. Non toccavo Erlang dal 2009, circa tre anni.

Anche Ruby era parecchio tempo che non lo maneggiavo (da prima del 2009). Per cui il confronto che sto per fare è abbstanza obiettivo, anche perché non uso attivamente nessuno dei due linguaggi: non ho “preferenze”. Di Ruby mi piace l’immediatezza (leggermente maggiore rispetto a Python) mentre di Erlang apprezzo l’approccio funzionale ma anche pragmatico (per contro scala/haskell sembrano un po’ più fini a se stessi, persi nell’intermundia della teoria separata dalla pratica).

Ecco la mia impressione durante  la conversione in Erlang del core di Code Zauker:

  1. La gestione delle stringhe in Erlang si dice sia debole, poiché basata sull’uso di liste, ma l’API di supporto consente ugualmente di operare in modo confortevole. Ad ogni modo il core di Er Zauker non sembra aver risentito di queste limitazioni
  2. Il prototipo di ErZauker, è altamente sequenziale ma si è dimostrato all’altezza delle aspettative. In pratica viene reso paralello solo il processamento dei file, mentre la pipeline che da un file porta ad una serie di trigrammi su redis è completamente sequenziale (almeno per ora!).
    La velocità del prototipo sembra leggermente superiore a quella del core scritto in Ruby.
  3. La sintassi di Erlang è un po’ astrusa: vi sono tre separatori distinti per le istruzioni (“;”, “.” e “,”) usati in contesti diversi. Durante lo sviluppo,il ciclo compila e prova in Erlang è un po’ difficoltoso.
  4. Rebar è il build tool più diffuso: anche se funzionale, la documentazione che ho trovato è poco chiara e il tool di per sé è avaro di spiegazioni su cosa fa (e perché lo fa…). Di default ogni azione è eseguita ricorsvamente anche sui progetti da cui si dipende, e questo normalmente non è gradevolissimo durante i test.
  5. Erlang è un linguaggio usato in produzione da molto tempo, e la sua affidabilità è notevole. I commenti su stack overflow sono generalmente lusinghieri. Da questo punto di vista, Ruby non ha un “proven track record” di tale forza.