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.

It is also common ground, however, that the First Amendment does not guarantee the right to communicate one's views at all times and places or in any manner that may be desired.

Tempo fa rimasi colpito nel leggere questo orientamento della corte degli Stati Uniti dal quale ho tratto la precedente citazione.

La libertà di espressione è un diritto molto potente che ha storicamente molteplici interpretazioni. Benchè ingenuamente potrebbe essere inteso come la possibilità di manifestare qualsiasi idea, ci sono delle situazioni in cui si deve intendere come il diritto di un individuo minoritario nel poter esprimersi liberamente e senza ritorsioni.

Con questa premessa posso inquadrare più facilmente il motivo per cui ritengo che il ban del 2015 da parte degli amministratori di Reddit nei confronti di /r/FatPeopleHate e altri subreddit di minor dimensioni non sia stata un'azione ipocrita rispetto agli ideali della piattaforma.

Angela Nagle ci ricorda che quegli spazi online senza leader roccaforte di ideali minoritari di sinistra, hanno permesso di esprimere non un'idea, ma qualsiasi idea, anche di estrema destra. Diventa quindi inevitabile che una piattaforma delle dimensioni di Reddit, che nello specifico raccoglie una moltitudine di argomenti e discussioni grazie ai quali è stata ritenuta un bastione della eterogeneità, prima o poi debba adottare una linea di moderazione più definita.

Il recente ban invece non riguarda la libertà di espressione, e mi colpisce personalmente, nonostante io non abbia mai visitato alcuno dei subreddit recentementi banditi e le mie uniche transazioni si siano limitate agli utenti di r/MechanicalKeyboards.

Sono approdato a Reddit inizialmente a causa del mio hobby per le tastiere meccaniche. Da lì mi sono mosso verso r/italy e altri subreddit di indirizzo informatico. Ho interessi di nicchia e Reddit mi permetteva di riunirmi con persone dall'altra parte del globo che mi fornivano informazioni che non avrei potuto ottenere altrimenti.

Ora questo rimane valido solo per le persone i quali interessi sono allineati con quelle comunità che riflettono una buona immagine per Reddit e gli investitori. Benchè i miei subreddit di riferimento non siano stati banditi, riconosco che nel recente ban ci sono degli intenti politici o misteriosamente economici.

Con questo post dico addio a Reddit. Da spazio di discussione a spazio di intolleranza e divisione politica, dove delle comunità che non rientrano nei canoni di buona reputazione per delle agenzie pubblicitarie devono essere eliminate.

Non voglio che ogni mia parola sia pesata oltre i valori della comunità a cui sottoscrivo, non voglio fare esercizi di autocensura nei post che scrivo.

Aderivo a delle regole ben definite e delle quali gli amministratori si assumevano la responsabilità. Con il ban di marzo 2018 il sito che conoscevo ha cambiato faccia ed il post di un utente anonimo sarà l'ultimo post che downvoterò.