tsrs porta TypeScript in Rust: la velocità deve fare i conti con la compatibilità

TypeScript ha un’altra strada verso un compilatore più rapido: tsrs, porting sperimentale in Rust sostenuto da Cloudflare e VoidZero e sviluppato con Max Schwenk di Owner.com. L’annuncio del 20 ottobre promette controlli più brevi e minore consumo di memoria. La domanda decisiva è se un’implementazione diversa riesca a continuare a dare le stesse risposte mentre TypeScript evolve.

Per chi sviluppa, il compilatore fa parte delle regole su cui poggia il progetto. Accelerare un controllo è utile se il cambio di strumento non modifica silenziosamente il codice che viene accettato. Il lavoro sulla compatibilità merita quindi la stessa attenzione del numero più vistoso nei benchmark.

Prima del moltiplicatore viene il confronto

Cloudflare dichiara controlli fino a otto volte più rapidi e circa il 70 per cento di memoria in meno rispetto a TypeScript 7.0, a parità di processi di verifica. Sono risultati preliminari del progetto, non una garanzia per ogni repository. Lo stesso annuncio segnala che TypeScript 7.1 beta migliora già rispetto alla 7.0: la versione precedente non è l’unico termine di paragone utile.

La metodologia dei benchmark rende visibili le variabili. Registra tempo trascorso, picco di memoria residente e numero di errori su progetti fissati a revisioni precise, controllando il parallelismo. Le tabelle correnti impiegano anche una versione di sviluppo specifica di TypeScript. Un grafico consultato successivamente può quindi avere una base diversa da quella citata al lancio.

Aumentare i processi non offre prestazioni gratuite: può cambiare la pressione sulla memoria e le risorse lasciate ad altri lavori. Confrontare impostazioni equivalenti risponde a una domanda; confrontare quelle predefinite di ciascuno strumento risponde a un’altra. Entrambe possono essere interessanti, ma sovrapporle rende il moltiplicatore meno utile.

La compatibilità non finisce con l’annuncio

Il documento sulla compatibilità prende come riferimento una precisa revisione dell’implementazione TypeScript. Riporta un’estesa verifica di conformità, insieme alle differenze ancora presenti e ai problemi nei confronti su repository reali. Un’elevata percentuale di risultati corretti dimostra progresso, senza cancellare l’aggettivo “sperimentale”.

La questione va oltre il successo di un comando. L’ordine dei messaggi diagnostici, il loro testo e le dichiarazioni prodotte possono influire su integrazioni dell’editor, test e strumenti di compilazione. Un porting può sembrare intercambiabile su una piccola applicazione e mostrare differenze su codice più ampio, con tipi o configurazioni particolari.

Anche il repository distingue lo stato attuale da una sostituzione stabile e universalmente compatibile. Affiancarlo al controllo già usato dal progetto offre perciò una prima valutazione più informativa che renderlo subito l’unico controllo obbligatorio prima della distribuzione. È un criterio per esaminare lo strumento, non il resoconto di una nostra prova prestazionale.

La memoria cambia anche il luogo di lavoro

La motivazione di Cloudflare comprende WebAssembly: requisiti di memoria più contenuti possono rendere praticabili ambienti completi di verifica nel browser o in servizi con risorse limitate. La possibilità interessante non è soltanto una barra di avanzamento più breve. È far entrare un ambiente di sviluppo dove prima faticava a funzionare.

Si intravede una continuità con il passaggio di Deno a Cloudflare, pur trattandosi di progetti e impegni differenti: un porting del compilatore non è una migrazione del runtime. Entrambi avvicinano gli strumenti degli sviluppatori alla strategia della piattaforma.

Per chi segue il software open source, tsrs propone prove consultabili e limiti espliciti. Il risultato duraturo sarebbe ridurre l’attesa lasciando intatto il significato del programma. È una promessa più impegnativa del primo posto in un grafico.