Recensione del linguaggio di programmazione Rust: vale la pena impararlo?

Chiedi a due sviluppatori Rust esperti se imparare Rust è valso lo sforzo e puoi ottenere risposte completamente opposte. Uno potrebbe dirti che non ha fatto nulla per la sua carriera; l'altro potrebbe definirla una delle migliori decisioni tecniche che abbia mai preso. Possono avere ragione entrambi.

È in questa contraddizione che sta davvero la domanda «vale la pena imparare Rust?», ed è per questo che un sì generico non ti serve a niente. Rust è un linguaggio compilato il cui sottoinsieme sicuro impone regole di sicurezza della memoria in fase di compilazione, senza richiedere un garbage collector a runtime.

Quindi mi sbilancerò con una risposta, dirò da quale condizione dipende e ti mostrerò quanto costa quella condizione.

La versione breve

Vale la pena imparare Rust se stai costruendo qualcosa di longevo in cui avere un compilatore che intercetta un'intera classe di bug vale il prezzo. È la scelta sbagliata se devi rilasciare un'app CRUD questo mese, se stai imparando a programmare o se conti gli annunci di lavoro. 4 su 5, con un punto in meno per quello che costa prima di ripagare.

• Cosa compri: in Rust sicuro, le regole di ownership e borrowing trasformano i bug di use-after-free, double-free, riferimenti non validi e data race in errori di compilazione invece che in incidenti in produzione. Questo è tutto l'argomento, ed è valido.
• Cosa paghi: il compilatore ti costringe a mettere per iscritto decisioni sulla memoria che il tuo linguaggio attuale prende in silenzio, e all'inizio sembra che lo strumento stia facendo il difficile.
• La questione della durata è risolta. I maintainer del kernel hanno concluso l'esperimento Rust al Maintainers Summit di dicembre 2025, e l'etichetta «sperimentale» è stata tolta in Linux 7.0.
• La questione della moda non è risolta, ed è un'altra domanda. Rust è al #10 dell'indice TIOBE di settembre 2026, in salita dal #18 di un anno prima.
• Il mio servizio Rust di prova ha richiesto molta più memoria per compilare che per girare: ha toccato un picco vicino a 1 GB durante la build ed era a circa 3,5 MB a riposo in esecuzione.
• Fa per te se rilasci già software in un altro linguaggio e stai costruendo qualcosa in cui un bug di memoria costerebbe caro, oppure lavori vicino al software di sistema. Non fa per te se hai una scadenza, parti da zero o cerchi il linguaggio con più offerte di lavoro.

Come è stata fatta questa recensione: i numeri di build e di runtime qui sono miei. Ho installato Rust 1.98.1, scritto un piccolo servizio web con Axum e misurato cosa serviva per compilarlo e cosa per eseguirlo. Il tutto è girato in un container isolato, non su hardware dedicato, ed è un solo progetto, quindi considera le cifre un dato e non una legge. Tutto il resto viene da fonti primarie o autorevoli: la patch del kernel e il resoconto di LWN su di essa, i post sulla sicurezza di Android di Google, l'indice di TIOBE stesso (con il commento di aprile riportato da Slashdot), Phoronix sulla merge window di Linux 7.0, i record CVE del kernel Linux per la vulnerabilità di Binder, la dichiarazione di Canonical stessa e il sondaggio Stack Overflow 2025. Ho letto la patch del kernel. Non ho fatto un audit del codice Rust del kernel. E non scrivo Rust da anni, quindi dove questa recensione giudica il linguaggio in sé, si basa su chi lo scrive da anni, e li cita per nome.

Cosa ti dà il compilatore

Dai a due thread un riferimento mutabile allo stesso vettore in Rust e il codice non compila. Non un warning. Non un lint che puoi zittire quando sei di corsa. Non compila. Quel rifiuto è ciò che compri con Rust sicuro: i bug di use-after-free, double-free, riferimenti non validi e data race diventano errori di compilazione invece che incidenti in produzione. La via di fuga di Rust (unsafe) può aggirare alcune di queste garanzie, quindi non è una promessa assoluta su qualsiasi codebase Rust.

Ownership significa che ogni valore ha esattamente un proprietario responsabile di liberarlo. Borrowing significa che puoi prestare riferimenti, ma il compilatore ne traccia i lifetime e non lascia che uno sopravviva a ciò a cui punta, né che un prestito mutabile coesista con un altro. In Rust sicuro, i bug di use-after-free, double-free, riferimenti non validi e data race vengono intercettati dal sistema di ownership e dei tipi prima che il programma giri.

Non c'è un garbage collector, ed è l'altra metà dell'accordo. Visto che l'ownership dice già chi libera cosa e quando, niente deve scandire il tuo heap a runtime. Rilasci un binario senza collector dentro, e non hai tempi di pausa su cui fare tuning.

Il prezzo si presenta nello stesso punto della garanzia. Ogni decisione sulla memoria che il tuo linguaggio attuale prende in silenzio al posto tuo è una che Rust ti chiede di scrivere: chi possiede questo, quanto vive quel riferimento, se qualcos'altro può vederlo e se attraversa il confine di un thread. Il compilatore non sta facendo il difficile. Si rifiuta di indovinare.

Quindi: questo è il motivo per cui qualcuno paga quello che Rust chiede, e secondo me regge. Se la classe di bug che elimina non ti preoccupa, il resto di questa recensione probabilmente non ti farà cambiare idea.

Rust è ancora sperimentale o ormai è infrastruttura di produzione?

Ha smesso di essere sperimentale a dicembre 2025, e a chiudere l'esperimento sono stati i maintainer del kernel stessi. Al Maintainers Summit 2025 hanno concluso che Rust si era guadagnato il suo posto nel kernel, sul piano tecnico e su quello umano. Jonathan Corbet di LWN ha riportato il consenso il 10 dicembre 2025: Rust nel kernel non è più sperimentale.

Rust è entrato in Linux mainline con la v6.1 nel 2022 proprio per condurre quell'esperimento. La patch di Miguel Ojeda che toglieva l'etichetta è arrivata tre giorni dopo il Summit, ed è entrata nella merge window di Linux 7.0.

«Ma l'esperimento è finito, cioè Rust è qui per restare.»

Miguel Ojeda, «rust: conclude the Rust experiment», LKML, 13 dicembre 2025

Separatamente, e prima: la riscrittura in Rust fatta da Google del driver Binder di Android, lo strato IPC attraverso cui comunicano i processi di Android (di continuo), è arrivata in Linux 6.18, uscito il 30 novembre 2025. Tieni questa tappa separata dal consenso del Summit. È quella in cui un'azienda ha scommesso un prodotto in commercio sul Rust nel kernel, non un gruppo di maintainer che benedice l'idea. Da allora il Rust nel kernel ha prodotto la sua prima CVE: CVE-2025-68260, una race condition in quello stesso driver Binder che Greg Kroah-Hartman ha annunciato il 16 dicembre 2025, introdotta nella 6.18 e corretta nella 6.18.1. Le prime segnalazioni si concentravano sui crash, ma la valutazione successiva del team CVE del kernel Linux assegna a CVE-2025-68260 un punteggio di 7,8 (gravità alta) e descrive un percorso di escalation locale dei privilegi tramite corruzione della memoria del kernel. Lo stesso driver (rust_binder) ha poi accumulato altre CVE.

Android è dove le prove diventano numeri. Il blog di sicurezza di Google ha dichiarato a dicembre 2022 che erano state scoperte zero vulnerabilità di sicurezza della memoria nel codice Rust di Android, a fronte di circa 1,5 milioni di righe di Rust in AOSP e circa il 21% di tutto il nuovo codice nativo in Android 13. È un'affermazione del 2022 con un perimetro del 2022. I post successivi di Google danno la tendenza più lunga: i problemi di sicurezza della memoria rappresentavano il 76% delle vulnerabilità di Android nel 2019 e il 24% nel 2024, con il numero assoluto sceso da oltre 220 a un previsto 36. Quelle cifre hanno senso solo rispetto alla base che hanno sostituito, cioè C e C++ scritti da ingegneri bravissimi con strumenti ottimi.

Due segnali più piccoli vanno nella stessa direzione. Il driver GPU Apple AGX di Asahi Linux è in Rust, scritto dal progetto Asahi Linux come lavoro di reverse engineering e non da Apple. L'aggiornamento di Canonical su rust-coreutils dice che Ubuntu 26.04 LTS include rust-coreutils 0.8.0 per la maggior parte delle utility. Tre restano su GNU coreutils (cp, mv, rm) perché il 22 aprile 2026 erano ancora aperti otto problemi TOCTOU; Canonical punta alla 26.10 per le utility rimanenti.

Questo è l'asse a cui darei il voto più alto, e il motivo è il tipo di impegno in gioco. I maintainer del kernel non «de-concludono» gli esperimenti, Google non smonta una riscrittura di quelle dimensioni e Canonical non mette dei coreutils riscritti in una LTS per vedere come va. Qualunque cosa succeda alla popolarità di Rust, qualcuno dovrà mantenere quel codice per anni.

Rust è morto o si sta solo stabilizzando?

No. Rust ha eguagliato la sua miglior posizione di sempre su TIOBE, la #13, a gennaio 2026. Tre mesi dopo era sceso di nuovo alla #16, e il CEO di TIOBE Paul Jansen scriveva ad aprile 2026, in un commento citato all'epoca da Slashdot, che la crescita di popolarità di Rust «sembra stabilizzarsi» e che un posto nella top 10 «ora sembra più lontano di prima».

Stava descrivendo Rust che raggiungeva la sua posizione più alta di sempre nel suo stesso indice, un posto che aveva occupato per la prima volta a luglio 2024, per poi perderlo.

L'indice TIOBE di settembre 2026 mette Rust al #10, in salita dal #18 di un anno prima, e oltre quel #13 che a gennaio TIOBE aveva definito la sua posizione più alta di sempre.

La mia lettura: il plateau era reale. Era un vuoto d'aria, non un soffitto. Batte la versione di entrambi i fronti, perché «Rust si è fermato» ora è sbagliato e «Rust sale e basta» non è mai stato vero.

L'avvertenza vale in entrambe le direzioni, e l'articolo di Slashdot la sollevava già all'epoca: le classifiche potrebbero semplicemente oscillare con il rumore mese per mese nei risultati dei motori di ricerca, che è ciò che l'indice conta. Se un calo di tre posizioni in un trimestre era una prova debole che Rust stava rallentando, una salita di sei posizioni è una prova debole che sta vincendo. Prendila come il meteo, non come il clima.

Il segnale più forte sul sentiment è il sondaggio di Stack Overflow, dove Rust è ancora una volta il linguaggio di programmazione più ammirato nel 2025, con il 72%: persone che lo hanno usato nell'ultimo anno e vogliono continuare a usarlo. È intenzione di continuare, non adozione, e qui è un segnale più utile della popolarità grezza se stai decidendo se ti piacerà restare con il linguaggio.

Lo slancio è ambiguo, e gli do meno peso della durata vista sopra, perché non stai investendo in una classifica.

Quanto ti costa imparare Rust

Il costo arriva presto e tutto insieme. Codice che Python, Java o C# eseguirebbero senza problemi viene rifiutato, ripetutamente, per motivi che sembrano arbitrari finché il modello di ownership non ti entra in testa, e non c'è modo di rimandarlo. Non puoi superare il borrow checker a forza di rilasciare, come invece puoi fare quando non capisci del tutto il tuo ORM.

Ecco la parte che mi ha sorpreso, e va al contrario di quello che ti aspetteresti. Nel thread di r/rust «Struggling to learn Rust», la risposta che ha avuto più seguito riformula il problema come mancanza di familiarità, non difficoltà, e il thread indica gli sviluppatori esperti che arrivano da linguaggi con garbage collector come quelli che fanno più fatica. u/Voxelman lo dice chiaramente: «Rust non è difficile. È diverso.» Nello stesso thread descrive il proprio percorso: C64 Basic, poi una serie di linguaggi imperativi, e un primo contatto con Rust che «è stato tutto tranne che WOW» perché liberarsi delle vecchie abitudini ha richiesto tempo.

Questa è la forma del conto. Se scrivi Python da otto anni, non stai imparando un insieme di regole, stai rinunciando a un insieme di presupposti su chi pulisce dopo di te. Chi sa meno ha meno da disimparare.

Un altro schema ricorre spesso in quel thread, e trasforma un errore di sequenza in un problema di fiducia: la gente si blocca non su Rust ma sulla scelta di un framework web, cercando di imparare il linguaggio tramite Axum o Actix prima di aver assimilato l'ownership. Come ha detto u/jmartin2683, è «come cercare di imparare ruby imparando rails.»

Secondo me la maggior parte degli avvertimenti sul costo punta alla cosa sbagliata. Metti in conto una pratica costante, non un weekend, e non prendere la frustrazione iniziale come un verdetto sulle tue capacità.

Rust ha bisogno di una macchina più grande per compilare che per girare

Ecco il risultato che non mi aspettavo: compilare questo progetto Rust ha richiesto ordini di grandezza di memoria in più rispetto a eseguirlo. Ho compilato un piccolo servizio Axum (Tokio con la feature full attiva, serde, serde_json, tower, una route JSON, circa 60 crate nell'albero delle dipendenze) su rustc e cargo 1.98.1, con strip = true nel profilo release, poi l'ho compilato da zero due volte:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Limitato a un solo job di compilazione (--jobs 1), il picco di memoria tra cargo, rustc e il linker è risultato tra 464 MB e 527 MB a seconda di quale dei miei due metodi di misura consideri (l'ho misurato in due modi perché il primo numero sembrava troppo pulito), e ha richiesto 113 secondi. Con il parallelismo predefinito su quattro vCPU, il picco di memoria è circa raddoppiato arrivando a circa 1 GB e la build è finita in circa 35 secondi. La variabile lì è il parallelismo, non il progetto. Più job significa più processi rustc residenti nello stesso momento, ed è per questo che i compilatori sono uno dei pochi carichi di lavoro che si prendono volentieri ogni core che gli dai per minuti di fila.

Il programma finito pesa 1,3 MB dopo lo strip, e a riposo occupa circa da 3,3 a 3,6 MB di memoria.

Con il parallelismo predefinito si tratta di duecento-trecento volte più memoria per compilare che per eseguire; limitato a un job è comunque ben oltre cento volte. Dimensiona un server su quello che serve al tuo servizio Rust in produzione e puoi ritrovarti con una macchina che non riesce a compilarlo, e il guasto non è un errore pulito: è l'OOM killer che fa fuori rustc a metà build, o un compilatore che manda la swap in thrashing per venti minuti. Due soluzioni funzionano. Compilare da qualche parte con margine e distribuire il binario, lo stesso schema di tenere una macchina di build separata per il lavoro pesante con Docker. Oppure compilare sulla macchina e darle spazio: per un servizio di questo tipo, un paio di gigabyte di RAM e due vCPU bastano comodamente. Quando non è così, la via di fuga è --jobs 1 (sì, è più lento; è quello il compromesso).

Se la macchina su cui lavori non ha quel margine, il nostro VPS Linux autogestito ti dà accesso root con fatturazione oraria o mensile e un posto dove mettere la build e restituirlo quando hai finito, anche se resta un server che gestisci tu e non uno che si gestisce da solo.

Un progetto, una forma, una macchina. La macchina era un container isolato condiviso, non un server dedicato, con circa 2 GB di memoria disponibili, quindi il picco senza limiti girava più vicino al suo tetto di quanto farebbe su una macchina più grande. Non sono una costante universale: se il tuo albero delle dipendenze è quattro volte più grande o il tuo profilo release attiva la link-time optimization, aspettati numeri diversi. Alberi delle dipendenze più grandi, la link-time optimization e il codice ricco di generics possono far salire la memoria di build, quindi non prendere le mie misure come un tetto universale.

La metterei alla voce come lavori, non se imparare il linguaggio. Sappilo prima di sbatterci contro.

Chi dovrebbe imparare Rust

Tre situazioni in cui ti direi di investirci il tempo: software longevo in cui un bug di memoria costa caro, lavoro vicino al sistema operativo, e il desiderio di vedere cosa fa al tuo modo di pensare la memoria il fatto di lottare con il compilatore. Per ognuna c'è un motivo per cui quel tempo ripaga.

Rilasci già software in un altro linguaggio e stai costruendo qualcosa di longevo in cui un bug di memoria costerebbe caro. Un servizio che deve restare su. Una libreria da cui dipendono altri team. Qualsiasi cosa in cui un use-after-free significa una revisione dell'incidente, non uno stack trace nel tuo terminale. È il caso per cui è stata costruita l'intera garanzia, e quello che paghi all'inizio si ammortizza nel corso della vita di ciò che stai costruendo.

Lavori vicino o dentro il software di sistema. Driver, lavoro sui dispositivi, utility del sistema di base, embedded, qualsiasi cosa stia sotto un sistema operativo invece che sopra. L'industria si è impegnata qui come non ha fatto altrove, e qui le prove sulla sicurezza della memoria sono più solide.

Vuoi l'effetto collaterale. Due utenti di quel thread di r/rust sono in totale disaccordo sul valore di Rust per la carriera, eppure qui arrivano allo stesso punto. u/tyler_church, che dice che non ha avuto alcun impatto sulla sua carriera, gli riconosce comunque «forse influenze sottili su come scrivo altri programmi in altri linguaggi». u/SirKastic23, pagato da due anni per scrivere Rust, dice che ha ampliato le sue competenze di programmazione in modi che non si aspettava. Due persone, non uno studio, ma è il ritorno che resta anche se non scrivi mai Rust per lavoro: un cambiamento nel modo in cui pensi, non una riga nel curriculum.

Chi non dovrebbe imparare Rust

Tre situazioni in cui quel tempo è speso meglio altrove: hai una scadenza questo mese, stai proprio imparando a programmare, oppure scegli un linguaggio in base a quanti annunci di lavoro lo citano. La terza è quella su cui si fanno più domande.

Hai una scadenza questo mese per un'app CRUD o un prototipo. Rust arriva con la tempistica esattamente sbagliata per un lavoro che deve esistere entro venerdì. Go è la scelta ovvia al suo posto se vuoi un linguaggio compilato con build veloci e gestione della memoria tramite garbage collector, e non ti servono le garanzie basate sull'ownership di Rust.

Stai proprio imparando a programmare. Questo punto divide davvero chi scrive Rust per mestiere, e il disaccordo nei thread di r/rust va in entrambe le direzioni, quindi la mia posizione è che dare a un principiante un testa o croce è un cattivo consiglio, da qualunque parte cada la moneta. Impara prima come funziona una macchina in un ambiente più indulgente, poi torna e lascia che il compilatore stringa le viti.

Scegli un linguaggio in base a quanti annunci di lavoro lo citano. Qui non ti do un numero, perché non ho trovato una cifra sugli stipendi o sulle posizioni aperte per Rust riconducibile a una fonte che difenderei. Quello che u/crusoe descrive in quel thread di r/rust è un mercato con meno posizioni, più specializzate. È un utente in un thread, non dati sul mercato del lavoro, quindi non ne farei l'affermazione che i lavori in Rust siano rari in generale. Se il volume di offerte è il tuo fattore decisivo, controlla gli annunci attuali nel tuo mercato di riferimento prima di scegliere il linguaggio.

Domande frequenti