Che il linguaggio Rust stesse guadagnando terreno dentro il kernel Linux non è più una novità. Ma quando a dirlo ad alta voce è Greg Kroah-Hartman, maintainer del ramo stabile e di fatto il numero due operativo dell’intero progetto, la faccenda assume un peso completamente diverso. Durante la Rust Week 2026, Kroah-Hartman ha lanciato un appello piuttosto chiaro: servono più sviluppatori Rust disposti a lavorare sul kernel. Non solo per scrivere codice nuovo, ma anche per occuparsi di binding, documentazione, review e integrazione con i sottosistemi già esistenti.
Il dettaglio che rende tutto più interessante è che Kroah-Hartman non è mai stato un entusiasta a prescindere. È una persona che osserva il problema dalla prospettiva di chi deve gestire milioni di righe di codice nel lungo periodo. Vede direttamente quanto tempo venga assorbito ancora oggi da bug di memoria, race condition e crash provocati da errori tipici del C. E quando una figura del genere dice pubblicamente che Rust rende la manutenzione “più divertente” e il kernel “più sicuro”, non è facile liquidare il tutto come semplice entusiasmo tecnologico.
Negli ultimi anni, va ricordato, l’integrazione di Rust nel kernel Linux ha generato tensioni piuttosto forti. Diversi sviluppatori storici hanno criticato apertamente l’introduzione di una seconda toolchain, l’aumento della complessità nella manutenzione e il rischio di frammentare il lavoro di revisione. Alcuni maintainer ritenevano che il C restasse più che sufficiente. Altri contestavano l’idea di affidarsi a un linguaggio più moderno senza avere ancora API complete per componenti delicati come DMA, interrupt e gestione avanzata della memoria. Alla fine Linus Torvalds ha messo un punto fermo, dichiarando che il codice Rust si merita assolutamente spazio nel kernel. E a fine dicembre 2025, Rust è stato ufficialmente dichiarato un progetto non più “sperimentale”.
Il kernel Linux non diventerà un progetto Rust, e nessuno lo vuole
Una delle interpretazioni più superficiali di tutta la vicenda è descrivere Rust come il successore del C dentro il kernel Linux. In realtà nessuno, tanto meno Torvalds e Kroah-Hartman, sostiene un’idea del genere. Il kernel resta e resterà prevalentemente scritto in C. Le dimensioni del codice esistente rendono impraticabile qualsiasi riscrittura massiva: parliamo di milioni di righe sviluppate in oltre trent’anni, con interazioni hardware estremamente delicate.
Rust entra soprattutto nei nuovi driver e nei nuovi componenti, in particolare dove la sicurezza della memoria pesa di più. Dal punto di vista tecnico, il supporto Rust nel kernel richiede una toolchain dedicata, con versioni moderne del compilatore rustc e binding specifici per le API kernel.
Chi sviluppa driver o componenti del kernel deve gestire la memoria in modo manuale, sincronizzare l’accesso alle risorse condivise tramite meccanismi di locking, controllare con attenzione il conteggio dei riferimenti agli oggetti in memoria e affrontare percorsi di errore spesso complessi. In C basta dimenticare una free (il rilascio della memoria allocata), utilizzare un puntatore non più valido oppure gestire male una race condition per introdurre bug molto difficili da individuare e correggere.
Rust prova a spostare una parte enorme di quel lavoro direttamente nel compilatore, che impedisce, salvo uso esplicito di blocchi unsafe, l’accesso concorrente non sincronizzato ai dati e l’utilizzo di memoria non valida. Va detto che il kernel Linux non può usare Rust “puro” come farebbe un’applicazione in userspace: serve comunque codice unsafe per interagire con hardware, DMA, interrupt e strutture interne del kernel. Rust non elimina automaticamente ogni vulnerabilità, però riduce enormemente la superficie di errore nel codice ordinario, confinando le operazioni realmente rischiose in sezioni molto più isolate e verificabili.
Perché la Rust Week 2026 segna un passaggio importante
Ed è proprio su questo che insiste Kroah-Hartman: un driver con meno bug di memoria significa meno patch urgenti, meno regressioni nei rami stable e meno ore spese a fare debugging su crash riproducibili solo con determinate configurazioni hardware. La presenza di Kroah-Hartman alla Rust Week 2026 assume un valore che va oltre la singola conferenza. Non capita spesso che uno dei responsabili principali della stabilità del kernel Linux partecipi come relatore a un evento interamente dedicato a un linguaggio nato fuori dal mondo Unix classico.
Il messaggio del suo intervento è diretto: servono più sviluppatori Rust interessati al kernel Linux. Non soltanto per scrivere codice, ma anche per mantenere binding, documentazione, condurre review e abilitare l’integrazione con i sottosistemi esistenti. Linux sta entrando in una fase ibrida dove il C resta dominante, ma Rust inizia a occupare posizioni considerate troppo delicate per continuare a tollerare certe categorie di errori storici.
