Perché in tanti stanno migrando a Rust (e cosa c’entra il frontend)

Negli ultimi mesi si sta consolidando un pattern abbastanza evidente: sempre più componenti “di base” dell’ecosistema (runtime, bundler, tooling, librerie di sistema) stanno guardando a Rust come destinazione naturale.

Per chi fa frontend questa non è una moda distante: la velocità del nostro workflow, la stabilità delle dipendenze native, i tempi di build, l’affidabilità dei binari che installiamo in CI—tutto passa da software che vive sotto al codice JavaScript/TypeScript.

In questo articolo metto in fila i motivi tecnici più solidi dietro questa tendenza, e le implicazioni pratiche per chi lavora quotidianamente sul web.

---

Una riscrittura enorme che fa discutere: non solo “perché Rust”, ma “come ci arrivi”

Negli ultimi tempi ha fatto rumore una migrazione completa di un progetto di toolchain da un linguaggio low-level (Zig) a Rust, con una pull request gigantesca e tempi di integrazione estremamente rapidi. Il punto interessante non è la solita domanda “perché riscrivere?”, ma che tipo di riscrittura stiamo normalizzando:

• cambi di linguaggio su codebase molto grandi;
• porting “a parità di architettura” (stesse strutture, stessi concetti, stesso comportamento atteso);
• un uso massiccio di AI/agent per generare gran parte del codice.

Questo porta due effetti opposti:

1. Abbassa drasticamente il costo iniziale di una migrazione (e quindi rende realistiche scelte prima impensabili).
2. Alza il rischio di revisione: anche con una suite di test eccellente, è difficile “capire davvero” milioni di righe nuove in poco tempo.

Per un team, la domanda non è solo “il codice passa i test?”, ma anche:

• possiamo manutenere questa base di codice tra 6, 12, 24 mesi?
• sappiamo debuggare i casi limite a basso livello?
• possiamo fare performance tuning senza muoverci alla cieca?

La migrazione a Rust spesso viene giustificata proprio con una parola: maintainability. Ma per ottenerla, non basta cambiare sintassi. Serve anche un processo che regga.

---

Perché Rust è così appetibile per runtime e toolchain

Rust è diventato un punto d’arrivo per chi vuole stare in un territorio particolare:

• prestazioni da linguaggio di sistema;
• assenza di garbage collector (e quindi meno overhead e meno imprevedibilità);
• un modello di sicurezza della memoria spostato a compile-time.

Questa combinazione è esattamente ciò che serve a componenti come:

• runtime che devono gestire I/O e concorrenza;
• bundler e transpiler che macinano file e AST;
• tool da CLI che devono essere veloci, piccoli e affidabili;
• librerie native che girano in contesti diversi (local dev, CI, container, macchine con architetture differenti).

Il vantaggio “concreto”: performance più prevedibili

Molte scelte tecnologiche, in pratica, ruotano attorno a una parola: prevedibilità.

Un tool che ogni tanto “fa pause” o diventa improvvisamente più lento sotto carico è molto più difficile da ottimizzare e rendere affidabile, soprattutto quando è un mattone della pipeline (build, test, packaging, install).

---

Garbage collector: utile, ma non gratis

Chi arriva dal mondo JavaScript è abituato a un fatto: la memoria la gestisce qualcun altro. Ed è spesso un vantaggio enorme in termini di produttività.

Però il GC ha costi reali:

• introduce pause di esecuzione (anche se moderne e ottimizzate);
• rende alcune classi di performance issue più difficili da diagnosticare;
• soprattutto, in sistemi latency-sensitive, la variabilità conta quanto (se non più) del throughput medio.

“Il GC previene le memory leak” è un mito (o meglio: è incompleto)

Il GC libera memoria solo quando gli oggetti diventano irraggiungibili. Se tu mantieni un riferimento vivo—magari in una cache, una closure, un listener—quella memoria resta.

Nel frontend lo vediamo spesso:

• listener mai rimossi;
• riferimenti conservati in singleton o store globali;
• oggetti “appesi” a code path rari (per esempio feature flag o edge case di navigazione).

Il GC non “risolve” questi problemi: spesso li nasconde finché non esplodono in produzione.

Effetto collaterale: architetture pigre

Quando la gestione memoria è totalmente astratta, è più facile accumulare:

• oggetti temporanei in loop caldi;
• livelli di astrazione non necessari;
• callback/closure ovunque.

Poi, quando arrivano rallentamenti, è comodo dare la colpa al runtime. Ma in molti casi è una somma di scelte progettuali.

---

Il vero superpotere di Rust: il borrow checker (e il fatto che ti fermi prima di eseguire)

Rust non usa un garbage collector. Per evitare che questo si trasformi in un ritorno al “far west” della memoria manuale, introduce il suo meccanismo più distintivo: il borrow checker.

L’idea chiave è potente per chiunque abbia mai debuggato un crash “impossibile”:

• certe classi di bug legate a ownership, aliasing e lifetimes vengono bloccate a compile-time;
• il programma non compila se il compilatore non riesce a garantire che l’accesso alla memoria sia sicuro.

Questo cambia completamente l’economia dei problemi:

• meno bug che arrivano in runtime;
• meno “undefined behavior” silenzioso;
• vulnerabilità più difficili da introdurre involontariamente.

Sì: paghi in complessità e curva di apprendimento. Ma per progetti di toolchain e infrastruttura, quel costo viene spesso considerato un investimento.

---

AI e riscritture: accelerazione reale, ma la qualità si misura dopo

L’uso di agent e modelli per generare codice sta rendendo plausibili migrazioni che un tempo avrebbero richiesto mesi (o anni). Questo però non elimina i vincoli ingegneristici:

• una migrazione è “finita” solo quando hai confidenza operativa (osservabilità, profiling, debugging, incident response);
• la manutenzione richiede che qualcuno capisca perché il codice è così, non solo che cosa fa;
• la revisione non può basarsi solo su diff enormi e test verdi.

In altre parole: AI può aiutarti a scrivere tantissimo codice, ma non può sostituire la responsabilità su performance, sicurezza e manutenibilità—soprattutto quando quel codice diventa un’infrastruttura usata da altri.

---

Cosa significa tutto questo per chi fa frontend

Anche se non scrivi Rust tutti i giorni, ci sono tre takeaway utili:

1. La toolchain che usi tenderà ad avere sempre più componenti in Rust (o in linguaggi di sistema simili). Questo impatta installazione, CI, compatibilità e debugging.
2. Performance prevedibili battono performance “medie” quando il tuo tool è una dipendenza critica. Build che “ogni tanto” rallentano sono costi reali.
3. La memoria non è un problema “solo backend”: leak e overhead esistono eccome anche nel browser e nelle app desktop basate su web tech. L’attenzione che Rust porta sul tema è un promemoria utile.

---

Conclusione

La migrazione verso Rust non è soltanto una questione di hype. È spesso la conseguenza di obiettivi molto concreti: binari più piccoli, prestazioni più stabili, meno bug a basso livello, e una base più sostenibile nel tempo.

La parte davvero nuova, oggi, è che la barriera d’ingresso alle riscritture si sta abbassando grazie agli strumenti AI. Ma il valore di Rust—per come è progettato—resta lo stesso: costringerti a pagare certe decisioni prima, quando correggerle è ancora economico.

Se lavori nel frontend, vale la pena seguire questi movimenti non per “cambiare linguaggio”, ma per capire dove sta andando l’infrastruttura su cui poggia il nostro lavoro quotidiano.