Lungo le varie tappe evolutive del kernel Linux, Linus Torvalds non ha mai esitato a criticare scelte tecniche, metodologiche o semplicemente stilistiche che ritiene dannose per la chiarezza e la manutenibilità del codice. Dopo aver escluso il supporto Big Endian per l’architettura RISC-V, il creatore di Linux ha spostato l’attenzione su un tema marginale soltanto all’apparenza, che invece risulta centrale per lo sviluppo a lungo termine: la formattazione del codice Rust e la qualità della documentazione testuale nelle patch.
Rust nel kernel Linux
Il linguaggio Rust entra nel kernel dalla “porta di servizio”, a partire dalla release 6.1, con l’obiettivo di migliorare la sicurezza della memoria.
Rust offre garanzie di sicurezza della memoria a livello di compilazione che riducono drasticamente classi di errori che in C possono portare a vulnerabilità critiche: use-after-free, buffer overflow e puntatori dangling. Tutti problemi che Rust, grazie al suo sistema di ownership e borrowing, aiuta a prevenire prima ancora che il codice sia eseguito.
L’introduzione di Rust nel kernel Linux non è stata priva di tensioni. Gran parte della comunità kernel proviene da decenni di sviluppo in C e vive una naturale riluttanza ad aggiungere una nuova superficie linguistica, con toolchain differenti e nuovi flussi di lavoro. L’integrazione del toolchain Rust nel sistema di build del kernel, la necessità di definire policy su quali librerie e idiomi siano accettabili e il timore che un uso improprio delle astrazioni introduca overhead o comportamenti inattesi in contesti dove la prevedibilità è essenziale, hanno alimentato dibattiti intensi.
Tuttavia, Torvalds ha concluso che il codice Rust deve essere incluso nel kernel Linux, anche al di là delle posizioni contrarie di alcuni maintainer.
La nuova critica di Linus Torvalds: lo stile di programmazione per il codice Rust non va bene!
L’introduzione di Rust rappresenta una grande opportunità tecnica per migliorare la qualità del codice del kernel, ma richiede responsabilità: regole ben definite, tooling prevedibile e capitale umano formato. Torvalds ne è convinto spiegando che l’adozione di Rust implica anche la definizione di regole chiare per lo stile del codice, in modo da garantire uniformità e coerenza con le decadi di tradizione C del kernel.
Il problema sollevato dal “re pinguino” non riguarda quindi, affatto, la validità del linguaggio Rust, quanto piuttosto le convenzioni di formattazione automatica applicate dal tool rustfmt
e dal relativo controllo rustfmtcheck
.
Analizzando una serie di modifiche al sottosistema DRM (Direct Rendering Manager) in vista di Linux 6.18, Torvalds ha puntato il dito contro due aspetti distinti.
In primo luogo, alcune descrizioni del codice Rust implementato risultavano praticamente illeggibili, con indentazioni perse o disallineate. Il problema, a suo dire, denota l’uso di editor inadeguati o configurati in maniera errata. Una cattiva presentazione del testo può sembrare un dettaglio, ma complica la revisione del codice e la comprensione delle motivazioni dietro le modifiche.
Ancora, Torvalds preferisce un approccio multi-linea per i blocchi di importazione: lo spiega in questo intervento nella mailing list del kernel. Questo schema consente di aggiungere facilmente nuove voci senza modificare le righe esistenti, riducendo il rischio di conflitti durante i merge. Un tool come rustfmtcheck
, invece, tende a comprimere il tutto in un’unica riga. Esempio:
use crate::{xyz, abc};
Per Torvalds, questo comportamento rappresenta un ostacolo alla manutenibilità: sebbene conforme alle regole di stile di Rust, complica il lavoro di chi deve risolvere conflitti o integrare nuove importazioni in futuro.
Oltre la forma: la sostanza della critica
Quella di Torvalds non è una guerra estetica per lo sviluppo di codice Rust. La vera questione è la possibilità di assicurare vera manutenzione al codice nel tempo.
Un progetto come il kernel Linux vive di patch, merge, branch e revisioni continue: la prevedibilità e la consistenza delle modifiche minori sono fondamentali per evitare conflitti e rendere la revisione meno onerosa.
In questo senso, il confronto tra lo stile “accademico” di Rust e le esigenze pragmatiche del kernel diventa un caso emblematico: ciò che può sembrare elegante in un contesto di sviluppo applicativo può rivelarsi controproducente in un progetto di dimensioni e complessità uniche come Linux.
Torvalds spiega ancora che il punto non è tanto il formato scelto, ma la mancanza di prevedibilità. Le regole di rustfmt
sono applicate secondo euristiche che non sempre riflettono l’intento del programmatore o le necessità di manutenzione del kernel. In altre parole, lo strumento “decide” quando usare la forma compatta o multilinea, introducendo una variabilità indesiderata.
Ancora una volta, l’ideatore del kernel Linux si preoccupa prima di tutto dell’effettiva sostenibilità della manutenzione del codice nel tempo.
L’immagine in apertura è generata in digitale e non raffigura Linus Torvalds in persona.