Tag: Rust

Il 20 ottobre 2026 sono arrivate due notizie per chi scrive TypeScript tutti i giorni. Microsoft ha pubblicato la beta di TypeScript 7.1, la seconda versione del compilatore riscritto in Go. Lo stesso giorno Cloudflare ha presentato tsrs, un porting (cioè una riscrittura fedele in un altro linguaggio) del compilatore in Rust.

Un porting somiglia al lavoro di un traduttore: il libro passa in un’altra lingua, ma la trama resta la stessa. Per un compilatore la trama sono le regole del linguaggio, e gli errori segnalati dovrebbero essere identici.

Ma che cosa vuol dire, in pratica, per chi lancia tsc sul proprio codice? Basti pensare che sul progetto mui-docs, il migliore dei cinque casi misurati da Microsoft, il controllo dei tipi scende da 22,2 a 11,9 secondi con la beta [1].

Le due notizie arrivano insieme, ma non sono la stessa cosa. Una è una beta ufficiale, con la Release Candidate, cioè la versione candidata a diventare definitiva, annunciata per circa un mese dopo; l’altra è un progetto sperimentale. Proviamo a separare i fatti misurati dagli annunci.

In breve:

La beta di TypeScript 7.1, pubblicata da Microsoft il 20 ottobre 2026, controlla i tipi più in fretta della 7.0 secondo le misure di Microsoft e si può provare su un ramo di prova. Per tsrs, il porting in Rust, Cloudflare dichiara numeri più alti, ma misurati con test suoi e su una versione sperimentale. Per un progetto in produzione, al 22 ottobre 2026, non c’è niente da cambiare.

• TypeScript 7.1 Beta (20 ottobre 2026): su cinque codebase reali Microsoft misura un controllo dei tipi da 1,2 a 1,9 volte più rapido rispetto alla 7.0 e dal 15,8% al 49,6% di memoria in meno.
• tsrs (20 ottobre 2026): nei test di Cloudflare, con 4 thread su quattro progetti, tsrs è fino a 8 volte più rapido di TypeScript 7.0.2, con circa il 70% di memoria in meno; non sono i test di Microsoft.
• Prossime tappe: Microsoft annuncia la Release Candidate di 7.1 “tra circa un mese” dal 20 ottobre 2026; tsrs punta a una versione stabile allineata a TypeScript 7.1.

Che cosa è stato annunciato il 20 ottobre 2026?

Sono stati annunciati due compilatori diversi per lo stesso linguaggio. Microsoft ha rilasciato TypeScript 7.1 Beta, che sul registro npm corrisponde alla versione 7.1.0-beta. È il seguito di TypeScript 7.0, il primo compilatore nativo in Go, rilasciato da Microsoft l’8 luglio 2026 [1] [4] [5].

Cloudflare ha presentato tsrs con un post firmato da Boshen Chen, Dimitri Mitropoulos e Christoph Nakazawa. Il progetto nasce dal lavoro di Max Schwenk, di Owner.com, e Cloudflare scrive di farlo crescere dentro Oxc, una raccolta di strumenti JavaScript scritti in Rust. Nel post Cloudflare dice di lavorarci insieme a VoidZero e in stretta collaborazione con il team di TypeScript [2] [3].

Oltre alla velocità, la 7.1 porta alcune novità per chi scrive codice e per chi costruisce strumenti [1] [4]:

• gli import attributes (metadati come with { type: "css" } attaccati a un import) si possono dichiarare nei moduli ambient (quelli descritti con declare module, di solito nei file .d.ts);
• arriva il supporto alle source phase imports, cioè import source, utile ad esempio per i moduli WebAssembly;
• es2026 diventa un --target e un --lib stabile;
• arriva una nuova API (l’interfaccia con cui altri programmi usano il compilatore) per gli strumenti esterni, diversa da quella di TypeScript 6; la 7.0 non ne aveva.

Ad esempio, chi importa file CSS o Markdown poteva dichiarare un modulo per ogni estensione; con la 7.1 la dichiarazione si lega all’attributo dell’import, e TypeScript segnala un errore se nell’import manca l’attributo richiesto. Per chi scrive strumenti conta invece l’API: con la 7.0 Microsoft aveva fatto in modo che si potesse affiancare TypeScript 6 per gli strumenti che devono accedere al compilatore da codice, come typescript-eslint [1] [4].

Che differenza c’è tra TypeScript 7 in Go e tsrs in Rust?

La differenza principale è chi lo mantiene e a che punto è. TypeScript 7 è il compilatore ufficiale di Microsoft, scritto in Go, e la versione 7.0 è stabile dall’8 luglio 2026. tsrs è un porting in Rust del compilatore 7, mantenuto da altri e, al 22 ottobre 2026, ancora in fase sperimentale [2] [4].

In pratica, chi installa il pacchetto typescript da npm usa già il compilatore in Go, e il comando resta tsc. tsrs è un pacchetto a parte, con il comando tsrs, che compila come tsc e ne accetta quasi tutte le opzioni (le eccezioni sono più avanti) [3] [4].

Cloudflare scrive che il progetto non è un fork: il team di TypeScript resta il responsabile del linguaggio e tsrs ne segue il comportamento “in stretta collaborazione” con quel team [2].

Il README del repository, da parte sua, dichiara due obiettivi. Il primo è una versione stabile allineata a TypeScript 7.1, con una conformità del 100%; il secondo è sostituire senza modifiche (drop-in) compilatore e language server (il programma che dà all’editor completamento, errori e navigazione del codice) di TypeScript 7. Precisa però che il progetto non è affiliato a Microsoft né approvato da Microsoft [3].

Il codice è distribuito con licenza Apache-2.0, come opera derivata di TypeScript. Le pull request esterne sono chiuse, mentre il tracker del repository accetta segnalazioni di bug [3].

Perché un porting in Rust, se quello in Go funziona? La risposta di Cloudflare è WebAssembly, di cui parlo più avanti [2].

Quanto è più veloce TypeScript 7.1 rispetto alla 7.0?

Secondo Microsoft, la 7.1 Beta di TypeScript è da 1,2 a 1,9 volte più rapida della 7.0 sulle cinque codebase che ha misurato (post del 20 ottobre 2026). Il test usa la configurazione predefinita di 4 thread per il controllo dei tipi e l’opzione --noEmit, che controlla i tipi senza generare file JavaScript. Sono quindi tempi di un controllo dei tipi, non di una pipeline di integrazione continua (CI), e il guadagno cambia da progetto a progetto [1].

Codebase	TypeScript 7.0	TypeScript 7.1 Beta	Accelerazione (Microsoft)	Memoria in meno
bluesky	4,48 s	3,89 s	1,2×	15,8%
mui-docs	22,2 s	11,9 s	1,9×	49,6%
sentry	19,6 s	15,1 s	1,3×	20,8%
t3code-server	26,5 s	19,1 s	1,4×	24,6%
vscode	21,6 s	17,7 s	1,2×	17,2%

Il guadagno, però, non è uguale per tutti: su mui-docs il tempo quasi si dimezza, su bluesky e vscode l’accelerazione è di 1,2 volte. Conviene quindi misurare sul proprio codice [1].

Per la 7.0, Microsoft aveva scritto che il compilatore in Go era spesso intorno a 10 volte più veloce di TypeScript 6, la versione precedente, scritta in TypeScript, come la descrive Cloudflare. Le due misure vengono da test diversi, su progetti solo in parte uguali: moltiplicare 10 per 1,9 dà un numero che nessuna fonte ha misurato. Le fonti non danno numeri diretti tra la 7.1 e le versioni 5.x [1] [2] [4].

Che cosa ha voluto dire il passaggio a TypeScript 7 fuori dai grafici? Nel post della 7.0, dell’8 luglio 2026, Microsoft riportava che, secondo gli ingegneri di Slack, passando a TypeScript 7 il controllo dei tipi in CI era sceso da circa 7,5 a 1,25 minuti [4].

Il dato riguarda quindi il passaggio a TypeScript 7, non la 7.1, e Microsoft non dice da quale versione partisse Slack. Va preso per quello che è: una testimonianza raccolta da Microsoft [4].

Cloudflare, nel suo post, parla di una 7.1 beta “fino a 2,5 volte più veloce” della 7.0. Ma attenzione: nei grafici di Cloudflare la versione misurata è una build notturna (7.1.0-dev.20261019.1), non la beta, e il valore massimo lì è 2,58× sul progetto MUI docs [2].

Sono due misure diverse, da non mettere in fila né confrontare tra loro: lo stesso MUI docs, con la 7.0, impiega 22,2 secondi nei test di Microsoft e 10,44 in quelli di Cloudflare [1] [2].

Quanto è veloce tsrs, secondo Cloudflare?

Nei primi benchmark di Cloudflare tsrs è fino a 8 volte più veloce di TypeScript 7.0, a parità di thread di controllo. Il confronto è tra tsrs 0.18.0-ts7.1.0-dev.20260929, che porta in Rust una versione di sviluppo della 7.1, e TypeScript 7.0.2, con 4 thread (--checkers 4) e --noEmit [2] [3].

I progetti sono VS Code, MUI docs, webpack e t3code server, e la misura è il tempo reale (wall time). Il post non indica l’hardware [2].

Nel grafico con la configurazione predefinita di TypeScript (4 thread), Cloudflare riporta un controllo da 3,83 volte (VS Code) a 8,10 volte (MUI docs) più rapido. La memoria di picco scende a una quota tra 0,13 e 0,31 volte quella della 7.0.2, cioè dall’87% al 69% in meno (MUI docs e webpack). Nel testo Cloudflare la riassume in “circa il 70% di memoria in meno” [2].

Nello stesso grafico c’è anche la nightly della 7.1, cioè la build notturna citata sopra: è il confronto più vicino alla 7.1 che si trova lì. Cloudflare non fa questo confronto, ma i tempi ci sono:

Progetto	tsrs	Nightly 7.1
VS Code	1,73 s	5,28 s
MUI docs	1,29 s	4,05 s
webpack	0,23 s	0,71 s
t3code server	1,21 s	7,17 s

Facendo il rapporto, tsrs risulta circa 3 volte più rapido della nightly sui primi tre progetti e circa 6 volte su t3code server [2].

Va letto con due cautele. tsrs si basa su una versione di sviluppo della 7.1 di fine settembre (7.1.0-dev.20260930.4), la nightly è del 19 ottobre, e nessuna delle due è la beta. Inoltre il post di Cloudflare non indica né la macchina né come è stato compilato tsrs [2].

Come già detto per la 7.1, conta chi ha misurato: qui sono gli stessi sviluppatori di tsrs. Cloudflare scrive di aver lavorato con il team di TypeScript perché i test confrontino la stessa configurazione, e pubblica gli script nella cartella bench del repository. Aggiunge anche che alcune ottimizzazioni della 7.1 arrivano da tsrs, mentre il post di Microsoft non nomina tsrs [1] [2] [3].

Un dettaglio per chi lo prova: di serie tsrs non usa 4 thread, ma una configurazione adattiva che, secondo Cloudflare, è più veloce ma usa più memoria. Per un confronto alla pari con tsc serve lo stesso --checkers per entrambi [2].

Perché serve un compilatore TypeScript in WebAssembly?

Serve a far girare il compilatore dove un programma nativo non può andare, come il browser o un ambiente isolato (sandbox). WebAssembly è un formato binario che browser e runtime eseguono in modo portabile e sicuro. Al 22 ottobre 2026 il README di tsrs rimanda a un playground nel browser, dove provare il controllo e la generazione del codice [3].

Secondo Cloudflare, un programma Go compilato in WebAssembly deve portarsi dietro il proprio garbage collector, il sistema che libera la memoria inutilizzata. Rust invece non ne ha bisogno, e questo semplifica lo scambio di dati con l’ambiente che lo ospita. Il pacchetto WebAssembly si chiama @tsrs/wasm e, secondo il README, usa il target wasm32-wasip1 [2] [3].

Cloudflare cita tre usi possibili: strumenti di sviluppo in sandbox per gli agenti AI, il browser e i dispositivi embedded o IoT (Internet of Things, gli oggetti connessi). Il primo è il più vicino al suo lavoro: un agente può far girare l’intera catena di sviluppo in un ambiente isolato sulla piattaforma di Cloudflare [2].

tsrs sostituirà il compilatore ufficiale di TypeScript?

In un progetto può prenderne il posto, perché è pensato per sostituire tsc senza modifiche. Come riferimento del linguaggio no: Cloudflare scrive che non è un fork e che le decisioni sul linguaggio restano al team di TypeScript [2] [3].

La sostituzione riguarda anche l’editor: la documentazione del repository spiega come avviare il language server con tsrs --lsp -stdio. Lo stesso documento avverte che il language server non esegue ancora i content mapper, i plugin con cui TypeScript 7.1 controlla file come quelli di Vue o Svelte [1] [3].

Tuttavia restano differenze note. Il README cita l’ordine in cui compaiono alcune diagnostiche e il mancato supporto di --init e --showConfig. Cloudflare scrive anche che sta lavorando con Theo Browne per unire tsrs e tsc-rs, un altro porting in Rust, in un unico pacchetto con language server e content mapper [2] [3].

Resta da capire come un progetto così grande possa restare allineato all’originale. Per tsrs Cloudflare vuole usare il metodo già applicato a Vinext: un agente che ogni mattina legge le modifiche del progetto originale e test di compatibilità rifatti ogni notte.

L’IA compare anche in un altro punto del post. Per spiegare perché un porting come tsrs arrivi proprio nel 2026, Cloudflare sostiene che i modelli AI più avanzati riescano a fare grandi porting “quasi da soli, nel giro di giorni” (“almost independently in a matter of days”) [2].

Cloudflare però non dice quanta parte di tsrs sia stata scritta così, né allega dati. Nel post linka però quello di Max Schwenk su Owner.com, del 19 ottobre 2026, che presenta tsrs come “un porting di TypeScript in Rust, scritto interamente da agenti” (“A Rust port of TypeScript, written entirely by agents”) [2] [7].

Sui limiti di questi modelli ho scritto in A.I. – Intelligenza artificiale e discriminazione. Un LLM (Large Language Model, il tipo di modello dietro i chatbot) sceglie la parola più probabile e può produrre contenuti coerenti ma falsi, le cosiddette allucinazioni. Per un compilatore, quindi, contano i test più degli annunci.

Come si provano la beta di TypeScript 7.1 e tsrs sul proprio progetto?

Si installa la beta come dipendenza di sviluppo, con il comando indicato da Microsoft [1]:

npm install -D typescript@beta

In una prova del 22 ottobre 2026, su Linux x86_64 (Debian 13, Node.js 20.19.2) e in un progetto vuoto, il comando risponde così:

added 2 packages, and audited 3 packages in 2s

found 0 vulnerabilities

Per controllare la versione:

npx tsc --version

Version 7.1.0-beta

Il 22 ottobre 2026 è la versione che corrisponde al tag beta su npm, mentre latest resta la 7.0.2. Prima di unirla al ramo principale conviene far girare il controllo dei tipi in CI e leggere i nuovi errori [5].

Microsoft segnala infatti due cambiamenti che possono farne comparire. Il primo riguarda i tipi del DOM (le interfacce con cui il codice usa la pagina web nel browser) in lib.d.ts. Il secondo è un controllo più severo sui parametri di tipo distributivi, con un nuovo messaggio d’errore, che Microsoft spiega con un’immagine semplice: un Cat può essere un sottotipo di Animal, ma non di ogni sottotipo di Animal [1].

Chi usa Vue, Svelte, Astro o MDX può guardare anche i content mapper: Microsoft avverte però che il pacchetto d’esempio per Vue non è ancora su npm [1].

Per tsrs, Cloudflare indica la forma più breve, npm install tsrs e poi npx tsrs. Il README del progetto consiglia invece di installarlo come dipendenza di sviluppo e di lanciarlo con --noEmit, che controlla i tipi senza generare JavaScript. Con npm diventa così [2] [3]:

npm install -D tsrs
npx tsrs --noEmit

Nella stessa prova l’installazione aggiunge due pacchetti, tsrs e il suo binario per Linux x64. Su un piccolo file di prova (src/index.ts) con due errori di tipo, npx tsrs --noEmit stampa le stesse righe di tsc 7.1.0-beta ed esce con il codice 2:

src/index.ts(4,7): error TS2322: Type 'string' is not assignable to type 'number'.
src/index.ts(5,20): error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.

Con il codice corretto non stampa nulla ed esce con 0, e in nessuno dei due casi scrive file. È un solo file di prova, quindi non dice nulla sulla conformità in generale.

Perché proprio --noEmit? Senza quell’opzione tsrs si comporta come tsc: legge il tsconfig.json e genera i file JavaScript, e nella stessa prova li ha generati anche con gli errori di tipo. Anche -D ha il suo motivo: senza, npm mette tsrs tra le dipendenze di produzione.

Per vedere su quale versione di TypeScript si basa:

npx tsrs --version

Version 7.1.0-dev.20260930.4 (tsrs 0.18.0-ts7.1.0-dev.20260929, microsoft/TypeScript@b85298b6a81f)

Come si vede dall’output, tsrs si basa su una versione di sviluppo di TypeScript, la 7.1.0-dev.20260930.4, e non sulla beta. Il nome del pacchetto riporta invece il 29 settembre: al 22 ottobre 2026 la versione pubblicata su npm è la 0.18.0-ts7.1.0-dev.20260929 [6].

Prima di provarlo conviene controllare il sistema. La 0.18.0 ha binari solo per macOS con Apple Silicon e per Linux x64 e arm64, sia con glibc sia con musl (le due librerie C più diffuse su Linux; musl è quella di Alpine). Niente Windows e niente Mac con processore Intel [6].

Se il controllo fallisce o dà risultati diversi da tsc, la segnalazione va fatta nel tracker del repository di tsrs su GitHub, che accetta segnalazioni di bug con una riproduzione minima. tsrs non è un progetto Microsoft [3].

Che cosa conviene fare prima della versione finale della 7.1?

Il mio consiglio, in attesa della versione finale, è di lasciare la produzione su TypeScript 7.0, che resta la versione stabile, e di provare la beta della 7.1 su un ramo separato. tsrs è utile da seguire, soprattutto per chi lavora con browser, WebAssembly o agenti, ma va trattato come un esperimento [1] [5].

Chi scrive strumenti, come plugin o integrazioni per l’editor, ha più ragioni per provare la beta: Microsoft chiede commenti sulla nuova API. Chi lavora su Linux o su un Mac con Apple Silicon può invece affiancare tsrs a tsc con --noEmit e confrontare gli errori, senza toccare la build [1].

Non resta che vedere se la Release Candidate di Microsoft confermerà i numeri della beta, e se tsrs arriverà alla versione stabile promessa.

---

Domande frequenti

Perché Microsoft ha scritto TypeScript 7 in Go e non in Rust?

Per restare il più vicino possibile al codice esistente. Nella discussione «Why Go?» del repository typescript-go (5 marzo 2025), Ryan Cavanaugh del team di TypeScript spiega che serviva un porting e non una riscrittura, e che Go, scritto in modo idiomatico, somiglia allo stile del codice originale. Il garbage collector, aggiunge, nel codice di TypeScript pesa poco. Cloudflare ha scelto Rust per WebAssembly, dove non deve portarsi dietro il garbage collector.

Quanto è più veloce TypeScript 7.1 rispetto alla 7.0 e alle versioni precedenti?

Da 1,2 a 1,9 volte rispetto alla 7.0, secondo le misure di Microsoft del 20 ottobre 2026 su cinque codebase, con 4 thread e --noEmit. Per la 7.0 Microsoft aveva indicato circa 10 volte la velocità di TypeScript 6: test diversi, da non moltiplicare. Le fonti non riportano confronti diretti con le versioni 5.x.

Si può usare TypeScript 7.1 beta in produzione?

Meglio di no: è una beta, e Microsoft non dice nulla sull’uso in produzione. La Release Candidate è annunciata per circa un mese dopo il 20 ottobre 2026, la versione finale poco dopo. Conviene provarla su un ramo separato e in CI, controllando i nuovi errori sui tipi del DOM e sui parametri di tipo distributivi.

typescript-eslint funziona con TypeScript 7?

Non direttamente con la 7.0, che non ha un’API per gli strumenti esterni. Nel post dell’8 luglio 2026 Microsoft spiega di aver fatto in modo che si possa affiancare TypeScript 6, con il pacchetto @typescript/typescript6, per strumenti come typescript-eslint. La 7.1 Beta porta una nuova API; nel tracker di typescript-eslint (issue #10940) il supporto alla 7.1 risultava in lavorazione al 30 settembre 2026.

Posso usare tsrs al posto di tsc nel mio progetto?

Sì, in prova: il README lo presenta come sostituto drop-in del compilatore e del language server di TypeScript 7. Al 22 ottobre 2026 la versione su npm è la 0.18.0, che si basa su una versione di sviluppo della 7.1, non sulla beta, e non ha binari per Windows né per Mac con processore Intel. Si installa con npm install -D tsrs e si lancia accanto a tsc con npx tsrs --noEmit.

Come provo la beta di TypeScript 7.1 sul mio progetto?

Con npm install -D typescript@beta, il comando indicato da Microsoft il 20 ottobre 2026, su un ramo dedicato e con il controllo dei tipi in CI. Per tsrs il README indica -D e --noEmit: con npm, npm install -D tsrs e npx tsrs --noEmit. I binari della 0.18.0 esistono solo per Linux e per macOS con Apple Silicon.

---

Fonti

1. Microsoft (Daniel Rosenwasser e il team di TypeScript), “Announcing TypeScript 7.1 Beta”, 20 ottobre 2026 – https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/
2. Cloudflare (Boshen Chen, Dimitri Mitropoulos, Christoph Nakazawa), “Introducing tsrs: A port of TypeScript to Rust”, 20 ottobre 2026 – https://blog.cloudflare.com/typescript-rust-port/
3. Progetto Oxc, repository oxc-project/tsrs su GitHub (README, documentazione in docs/ e cartella bench), consultato il 22 ottobre 2026 – https://github.com/oxc-project/tsrs
4. Microsoft (Daniel Rosenwasser), “Announcing TypeScript 7.0”, 8 luglio 2026 – https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
5. Registro npm, pacchetto typescript (dist-tags: beta = 7.1.0-beta, latest = 7.0.2), dati letti dal registro il 22 ottobre 2026 – https://registry.npmjs.org/typescript
6. Registro npm, pacchetto tsrs (latest = 0.18.0-ts7.1.0-dev.20260929, licenza Apache-2.0, binari per piattaforma in optionalDependencies), dati letti dal registro il 22 ottobre 2026 – https://registry.npmjs.org/tsrs
7. Owner.com (Max Schwenk, Head of AI Developer Experience), “tsrs”, 19 ottobre 2026 – https://building.owner.com/tsrs
8. Microsoft (Ryan Cavanaugh, team di TypeScript), discussione «Why Go?» nel repository microsoft/typescript-go, 5 marzo 2025 – https://github.com/microsoft/typescript-go/discussions/411
9. typescript-eslint, issue #10940 «Enhancement: Use TS 7 (tsgo / typescript-go) for type information» (aggiornamento di Josh Goldberg del 30 settembre 2026), consultato il 22 ottobre 2026 – https://github.com/typescript-eslint/typescript-eslint/issues/10940