Un articolo per r/italyinformatica

Questo articolo è stato originalmente scritto per il blog di r/italyinformatica.

Negli ultimi anni abbiamo assistito all'ascesa di un gran numero di linguaggi di programmazione, in particolare Go (2009), Rust (2010), Kotlin (2011), Elixir (2011), Crystal (2014), Pony (2014).

Questa esplosione di nuovi linguaggi è dovuta, fra le molte motivazioni, alla necessità di adottare paradigmi di programmazione non immediatamente recenti come cittadini di primo tipo.

Rispetto ai più maturi C, C++ o Java, Python o Ruby questi linguaggi offrono "out of the box" supporto per:

• una visione moderna delle concorrenze (le goroutines di Go o il modello ad attori di Pony ed Elixir)
• Memory safeness, in particolare:
  • assenza di NULL (Pony, Rust, Kotlin)
  • gestione automatica della memoria, il cosiddetto [Garbage Collector](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science) (o Reference Counting per Rust)
  • assenza di puntatori
  • assenza di deadlocks
• Supporto ad HTTP nella standard library
• Management delle dipendenze (ad eccezione di Kotlin)
• Namespaces

Chiaramente nessuno di questi linguaggi è oggettivamente superiore agli altri, sono tutti turing completi e la scelta del programmatore ricade su motivazioni del tutto personali (stile, programmazione ad oggetti, familiarità con altri linguaggi).

Un pò di contesto

Ho scritto la mie prime due righe di codice nel 2013 per il corso di Computer Science del Politecnico di Torino.

Per mia fortuna, al Politecnico le cose si muovono ancora lentamente e ci hanno fatto usare C per tutta la durata della triennale. Si è aggiunto un corso di principi della programmazione ad oggetti al terzo anno, in Java.

Personalmente ho imparato durante l'estate di quel primo anno le basi di C++ e Python poco dopo.

Sono stati con i miei primi progetti che ho capito che non si può avere un buon linguaggio senza un buon tooling ed una community vivace e soprattutto tanta, tanta documentazione. Per questo, per molto tempo C è stata la mia prima scelta, dato che il mio target è sempre Linux.

Gli obbiettivi prima del linguaggio

Questo post vuole essere una raccolta più o meno organizzata delle motivazioni per cui mi sono dovuto muovere oltre la frontiera di C nel mio ultimo progetto, ovvero un backend per la raccolta e presentazione di pubblicazione di ricerca e materiale didattico per più di 80 centri di ricerca.

Per il Centro Nexa del Politecnico di Torino mi sono ritrovato per la prima volta responsabile del codice che dovevo scrivere e dell'uso che se ne sarebbe fatto.

Ho dovuto tenere in considerazione, oltre chiaramente alla funzionalità della piattaforma, in ordine di priorità:

1. Sicurezza
2. Performance e scalabilità
3. Separazione dal frontend
4. Facilità di deploy in un server che non controllo

Fortunatamente non mi è stata imposta nessuna limitazione sulla scelta del linguaggio, altrimenti Python sarebbe stato la scelta più adeguata se avessi dovuto tener conto anche di altri programmatori.

Benvenuto D

La mia scelta è caduta su D.

Voglio provare ad affrontare ad uno ad uno i motivi di questa scelta magari inusuale.

Sicurezza

Nessuno vuole davvero vantarsi di usare un backend scritto in C/C++. Il buffer overflow può essere considerato il bug più comune e ci sono situazioni in cui non appaiono affatto in maniera ovvia.

Inoltre per un applicativo distribuito il Garbage Collector è la scelta più performante, specialmente se coordinato fra le varie istanze.

D offre questo di design, e benchè il suo GC sia frutto di numerose discussioni, offre in maniera del tutto innovativa, robustezza e sicurezza.

In particolare, D presenta:

• Array che sono slices (o ranges) ma non puntatori (e neanche oggetti)
• Bound checking durante la fase di compilazione.
• Inizializzazione automatica delle variabili.
• Safe Casting (chiaramente come eredità di C++).
• Restricted pointers: si può passare una funzione per referenza dichiarandola ref, ma solo quando passata come parametro o di ritorno. Inoltre non c'è nessuna pointer arithmetic.
• RAII, ovvero l'acquisizione delle risorse equivale alla loro assegnazione e Scopes: le variabili hanno una lifetime limitata allo scope di dichiarazione. Nessun dangling pointer come in C.
• Strutture immutabili: come nelle specifiche di molti linguaggi funzionali, si può dichiarare una variabile come immutable e quindi può essere facilmente condivisa fra threads.
• @safe, @trusted: le specifiche del linguaggio permettono di annotare delle funzioni come sicure o affidabili affinchè il compilatore controlli che non gestiscano puntatori (ad esempio interfacciandosi con C) ed utilizzino il subset "sicuro" del linguaggio (maggiori dettagli in seguito).
• funzioni pure: le funzioni inoltre possono essere dichiarate pure, prive di effetti collaterali e sempre rientranti. Questo permette di evitare deadlocks e un controllo totale sul risultato delle funzioni.

Performance

Ci sono moltissime soluzioni per scrivere un applicativo che si interfaccia con il web, ma hanno tutte la loro origine nel famoso C10K problem.

Nel mio caso ho deciso di utilizzare un approccio asincrono con coroutines (anche detti threads leggeri).

Benchè D abbia supporto nativo alle coroutines, ho deciso di appoggiarmi al framework più comune per web dev in D: vibe.d.

Ogni volta che Vibe accetta una richiesta dall'esterno ed esegue una funzione bloccante (che interrompe l'esecuzione del programma fino al ritorno della funzione), questa viene messa in una pool di azioni da eseguire e Vibe controlla periodicamente che almeno una di queste sia pronta a ritornare un risultato e continuare con l'esecuzione di questa.

Inoltre, benchè questo meccanismo funzioni interamente su un solo thread, è elementare coordinare una thread pool che distribuisa il carico fra i vari core che eseguono migliaia di threads leggeri concorrentemente.

Contratti e Tests

Non amo scrivere commenti sui programmi. Penso sia assolutamente necessario commentare il codice di librerie ma al di fuori di queste il codice (buon codice) dovrebbe essere autoesplicativo.

Inoltre, nelle mie recenti esperienze, il comportamento del programma era chiaro a partire dai tests.

In D questo concetto viene portato agli estremi applicando il "Design by Contract programming.

Un contratto è la divisione di una funzione in:

• Precondizione, ovvero le condizioni che devono essersi verificate prima della chiamata della funzione;
• Postcondizione, ovvero le condizioni che devono essere rispettate all'uscita della funzione (solitamente applicate al risultato);
• Invarianti, ovvero le specifiche di una struttura dati che devono rimanere verificate in ogni funzione;
• Corpo della funzione

Un esempio:

struct Clock {

    short time;

    invariant {

    assert (time > 0);

    }

}

short addReturnTime(Clock c, short n) 

    in {
        n > 0;

    }

    body {

        return c->time + t;

    }

    out (result){

        result > c->time;

    }

unittest {

    auto clock = Clock(60);

    assert (addReturnTime(clock, 10) == 70);

}

Come si nota dall'esempio il supporto ai tests è built-in nel linguaggio e distanti solo una flag in fase di compilazione.

Un approccio moderno alle concorrenze

Il modello primitivo delle concorrenze in Posix è discutibilmente datato e prono ad errori per il programmatore.

D di default evita la condivisione di dati fra Threads. Fra le varie motivazioni c'è il fatto che questo rifletta più realisticamente l'hardware, ma sicuramente l'obbiettivo finale è la riduzione di bug.

Non voglio dilungarmi nei dettagli di ogni singolo approccio, ma per completezza D offre out of the box i seguenti modelli:

• Message passing e attori, ovvero tutti i dati che vogliono essere condivisi fra thread sono incapsulati in RPC;
• Green threads, come nel mio caso;
• Multi processing, ovvero man 3 fork
• TaskPools, ovvero future e promises di Python e Javascript;
• SIMD vectorization

Andrei Alexandrescu, uno dei due creatori del linguaggio, dedica un intero capitolo alle concorrenze che potete leggere liberamente qui.

Assenza di dogmatismi

Non potrei mai pensare di scrivere un linguaggio di programmazione senza mettere al secondo posto la semplicità.

Ma chiaramente ancora prima di discutere di semplicità la dobbiamo definire.

Go e Python sono due linguaggi semplici. Lo sono per la ridotta sintassi (Go in particolare) e perchè attraverso il loro dogmatismo costringono il programmatore ad adottare dei paradigmi di programmazione scelti dai designer di quel linguaggio. E` il motivo per cui in python non abbiamo delle vere lambda e per cui Go non ha le eccezioni.

In D il programmatore ha libertà piena di scelta. Oltre ad un paradigma di programmazione si può ridefinire la sintassi e evitare il Garbage Collector. Si può in ultimo disattivare tutte le feature del linguaggio che sono @safe e adottare uno stile molto più vicino al C/C++, con tanto di inline asm.

Dove iniziare

Non posso non concludere un post propagandistico senza indirizzare i più interessati alle prime risorse per imparare D.

Personalmente consiglio il libro di Andrei che offre in particolare moltissimi dettagli sulle motivazioni del design di D. Non ho ancora letto un libro che affrontasse così chiaramente il design di linguaggi di programmazione e i vari compromessi fra performance, semplicità e complessità del compilatore.

Inoltre il sito della community offre due intro per chi proviene da C e C++, oltre al classi tour.

Inoltre la libreria standard, Phobos, è talmente chiara che solitamente mi trovo a mio agio a consultare direttamente il codice piuttosto che la documentazione online.