Perché il frontend per Rust in GCC è un passo importante per il free software
Da qualche anno c’è un gran parlare di Rust, il linguaggio di programmazione realizzato da Mozilla per accelerare lo sviluppo di Firefox e che è “intrinsecamente sicuro”, grazie all’uso di policy molto severe a livello di linguaggio che permettono di determinare possibili situazioni pericolose in fase di compilazione.
Rust è sta veramente arrivando dappertutto: nel mondo embedded, per lo sviluppo di web application, programmi di sistema (anche rimpiazzi di Core Utils, come abbiamo parlato qualche tempo fa) e persino nel kernel Linux, cosa che nemmeno C++ è riuscito a fare.
Circa un mese fa, il team di sviluppo di GCC ha annunciato di aver aggiunto circa 100 nuove patch al front-end a GCC per questo nuovo linguaggio. Oggi parleremo del perché non si tratta solo di un esercizio di stile, ma di un importante progresso.
Rust è libero: chiunque può scaricare i suoi componenti e i suoi binari e iniziare a programmare utilizzando questo linguaggio. Rust, tuttavia, non è standardizzato come C o C++, con documenti precisi rilasciati dall’ANSI e cui tutti i produttori di compilatori devono attenersi. Dal 2021, la gestione del progetto è assegnata alla Rust Foundation, fondata da Amazon Web Services, Huawei, Google, Microsoft e la stessa Mozilla cui si sono aggiunti altri membri. Sotto la loro direzione ci sono vari Rust Team, responsabili per quanto riguarda la direzione che prenderà il linguaggio in futuro.
GCC, invece, è la GNU Compilers Collection (anticamente, GNU C Compiler), un set di compilatori per i linguaggi C, C++, Objective-C, Fortran e tanti altri. Si tratta di uno dei primi e più famosi programmi creati per il progetto GNU (di cui “Linux” è solo il kernel, lo sappiamo tutti, no? ).
GCC è composto da un backend capace di trasformare in binario la cosiddetta “forma intermedia” di un programma. Altri componenti, i front-end, trasformano un sorgente, scritto in un linguaggio come il C++, nella forma intermedia (che poi il backend trasformerà appunto in binario).
Questo struttura consente di avere un compilatore molto più modulare, in cui le ottimizzazioni e i bugfix fatti al backend si rifletteranno su tutti gli altri linguaggi; significa anche che è possibile scrivere un compilatore per un nuovo linguaggio semplicemente (si fa per dire!) scrivendone il front-end.
LLVM (Low Level Virtual Machine) è il backend su cui è basato il compilatore ufficiale di Rust. LLVM è rilasciato sotto licenza BSD e questo ha permesso al frontend per C e C++ (chiamato CLANG) di rimpiazzare GCC su Mac OS e i vari BSD.
Se questo compilatore funziona, è libero e non crea problemi, dove starebbe l’utilità di avere un compilatore alternativo? Un compilatore Rust alternativo potrà proteggere gli sviluppatori da strategie Embrace-Extends-Estinguish per rendere “il suo Rust” l’unico sulla piazza.
Difficile?
La recente re-implementazione di Core Utils in Rust rende disponibili ls, cp, mv e gli altri comandi shell normalmente disponibili su GNU anche su Windows. Certo, un gran bel passo in avanti per l’interoperabilità. Ma anni di brutte esperienze fanno riflettere, specialmente quando si vede che Rust Coreutils è sotto licenza MIT anziché GPL, che ne permette l’inclusione in progetti commerciali.
Qualcuno potrebbe obiettare: “cosa importa se l’implementazione ufficiale di Rust aggiunge funzionalità? Dopotutto è quella che uso!”.
Cambia. Se alcune funzionalità diventano prerogativa degli utenti premium, per esempio: gli utenti di un ipotetico Rust++ potrebbero avere a disposizione accesso alle API di Windows, mentre quelli della versione free, solo di funzionalità base. O potrebbero essere introdotte lievi incompatibilità, come la gestione delle stringhe in UTF-16 per Rust ++ e in UTF-8 per altri standard.
Impossibile?
Con Microsoft accadde qualcosa di estremamente simile quando uscì Java. Negli anni novanta e per buona parte dei duemila ci trovammo con siti ottimizzati per Internet Explorer o con tag che funzionavano solo su Netscape. La Sun Microsystems introdusse la Java-Trap: il JDK ufficiale di Sun aveva a disposizione funzionalità estremamente comode (e.g. la libreria GUI Swing o RMI) che altre implementazioni non avevano. Usare Swing significava legarsi per sempre a SUN.
E che dire di quando Microsoft introdusse .NET e il linguaggio C#? Sicuro, ci fu subito l’implementazione delle parti open nel progetto Mono; ma le GUI scritte su Windows rimanevano incompatibili su GNU/Linux, a meno di usare le GTK.
In conclusione, ben venga Rust su GCC, perché, specialmente in questo caso, non si tratta di frammentazione, ma di libertà di scelta.
Jacopo Prendin
Appassionato di GNU/Linux dal 2000, tento disperatamente di tenermi distante dalla programmazione web e di sviluppare in C/C++ e Python i software che mi vengono commissionati.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
