Tsrs: TypeScriptのRustへのポート

tsrsの紹介：TypeScriptのRustへの移植

CloudflareとVoidZeroは、Owner.comのMax Schwenk氏と協力し、tsrsを開発しています。これはTypeScriptコンパイラのRustへの移植版です。私たちはTypeScriptチームと緊密に連携し、tsrsをOxc JavaScriptコンパイラツールチェーンの一部としてインキュベートしています。

私たちの目標は、開発者がコードのチェックを待つ時間を減らし、構築により多くの時間を費やせるようにすることです。TypeScriptをより高速かつメモリ効率良くすることで、ブラウザ内を含む、より多くの場所で完全な開発環境を提供できるようになります。

明確にしておきたいのは、私たちはTypeScriptをフォークしているわけではないということです。私たちは、言語の設計と方向性については、TypeScriptチームが完全に管理すべきだと考えています。彼らはJavaScriptコミュニティ全体でのTypeScriptの採用を主導しながら、長期的なビジョンを維持してきました。私たちはそれを変えるつもりはありません。

TypeScriptチームは多くのことについて非常に迅速に進めることができますが、一部の機能については、適切な実装を選択する前に、何年もかけて意図的に選択肢を検討し、プロトタイプを作成することがあります。Rustへの移植は、それらの決定に厳密に従う必要があります。さもなければ、最終的には崩壊し、互換性がなくなってしまいます。私たちは、元の実装に基づいてTypeScript言語を厳密に維持しなければなりません。そして、その見た目を決定する責任は、TypeScriptチームのみが負うべきです。

パフォーマンスとメモリの改善

TypeScriptのRustポートの初期ベンチマークは有望です。tsrsは、同じ数の型チェックワーカーを使用した場合、TypeScript 7.0と比較して最大8倍高速で、メモリ使用量は約70%少なくなっています。

［画像: tsrsとTypeScript 7.0のパフォーマンス比較を示すグラフ］

ご覧のとおり、次期バージョンのTypeScriptはすでに多くのパフォーマンス改善をもたらしており、TypeScript 7.1ベータ版はTypeScript 7.0よりも最大2.5倍高速になっています。これらの最適化の一部はtsrsからアップストリームにマージされており、さらに多くの改善が見つかることを期待しています。

最近、さまざまなパフォーマンスに関する主張を伴う、異なるTypeScriptポートのベンチマークを目にしたかもしれません。これは、多くの場合、TypeScriptのデフォルトとは異なる、より大きなマシンタイプやオプションを使用しているためです。私たちはTypeScriptチームと協力して、上記のベンチマークが同じ構成を比較していることを確認しました。

デフォルトでは、tsrsはマシンタイプに依存する適応型構成で出荷されます。これはより多くのメモリを使用しますが、さらに高速です。

［画像: tsrsの適応型構成におけるパフォーマンスを示すグラフ］

tsrsを試す

Rustで実装されたTypeScriptは、TypeScriptの忠実なポートとなることを目指しています。npmからtsrsパッケージをインストールすることで、実験的なリリースを試すことができます。

npm install tsrs
npx tsrs

なぜ今なのか？

長年にわたり、TypeScriptを他の言語に移植する多くの試みを見てきました。関わる複雑さのため、成功したのは1つだけでした。それは、TypeScriptチームによるJavaScriptからGoへのTypeScriptの移植です。

しかし、最先端のAIモデルは、現在では大規模な移植を数日でほぼ独立して行うことができます。私たちは、RustやC++におけるTypeScriptのスローフォーク、忠実なポート、そして完全に再設計されたバージョンを見てきました。より高速なTypeScriptに対する需要が明らかに存在します。

なぜRustなのか？

「TypeScriptのGoポートはすでにTypeScriptを10倍高速にし、以前のTypeScriptで書かれたバージョンよりもはるかにメモリ効率を向上させた。それは十分ではないのか？」と思うかもしれません。

しかし、それは速度だけではありません。Rustはいくつかのユニークな利点を提供します。WebAssemblyでの実行です。RustとWasmの連携は常に強力であり、その理由の1つはRustの言語設計の基本にあります。GoプログラムをWasmにコンパイルすると、Goのガベージコレクタも一緒にコンパイルする必要があります。しかし、Rustのメモリ管理モデルは、WebAssemblyゲストとホスト間のメモリ相互作用を容易にします。これは、RustがWebAssemblyユースケースに非常に適している主な理由の1つです。それはメモリ効率です。

Cloudflare Workersは長らくWasmをサポートしています。ほんの数週間前、私たちは新しいEmscriptenターゲットとwasm-bindgenを使用して、WorkersでのネイティブRustサポートを発表しました。ソフトウェアビルドおよびデプロイメントシステム全体をWorkers上でタイトなループで実行する場合、小さなメモリフットプリントの利点はすぐに現れます。これは、これまで実行できなかった場所で、これらのワークロードを非常に効率的に実行できることを意味します。

これはエージェントと組み合わせることで新たな可能性を切り開きます。これにより、Cloudflare上で完全にカプセル化された開発システムをエンドツーエンドで実行できるようになります。しかし、Wasmを使用すると、ブラウザのクライアントサイド、組み込みデバイス、またはIoTアプリケーションで安全にこれらの環境を実行することもできます。

tsrsポートはどのように保守されるか？

まず、私たちはTheo Browne氏と協力して、tsc-rsとtsrsを単一のパッケージにマージし、Language Server Protocol (LSP) やコンテンツマッパーを含むTypeScriptのすべての機能をサポートするようにします。第二に、私たちは最近のブログ記事で説明したように、VinextをアップストリームであるNext.jsと同期して維持する方法で大きな成功を収めています。

毎朝、エージェントが変更を確認し、差分を取得し、Vinextに影響を与える可能性のあるものすべてについて追跡Issueを開きます。毎晩、互換性マトリックスが再生成され、Vinextに対してNext.jsテストスイートを実行します。これらのテストやIssueのいずれかがギャップを明らかにした場合、エージェントは両方のコードベースの変更を特定し、再現を作成し、関連するテストを移植し、修正を提案できる立場にあります。

私たちはこのプロセスをTypeScriptにも適用し、アップストリームTypeScriptからの動作の乖離を導入しないように細心の注意を払います。パフォーマンスの改善が見つかった場合は、TypeScript Goコードベースにも貢献するよう試み、すべての人に利益をもたらします。

最後に、現時点ではアップストリームバージョンとの間に、例えば診断情報の出力順序のような、いくつかの違いがあることを認識しています。安定版リリースを発行するまでには、これらの違いを最小限に抑えることを目指しています。

次は何？

Cloudflareはすでに、Vite、Rolldown、Oxlint、Oxfmtなど、JavaScriptエコシステムを支える多くの無料オープンソースRustツールを提供しています。Cloudflareで開発する1000万人以上の開発者にとって、基盤となる開発者ツールチェーンをより高速に、よりポータブルに、そしてより多くの場所で実行しやすくすることは非常に重要です。私たちは、Oxlintでの型認識型リンティングルールなど、tsrsを私たちのスタックにさらに深く統合することを実験することに興奮しています。

Vinextと同様に、私たちの目標は、TypeScript自体を妨げることなく、tsrsを適切に保守された健全なオープンソースプロジェクトとして実行することです。Oxcチームは、コードベースをより高速にし、メモリ使用量を削減し、保守しやすくするために、すでにリファクタリングを開始しています。TypeScriptチームもこれを真剣に受け止めており、tscのメモリとパフォーマンスの改善を実験していることを知っています。私たちは、TypeScriptチームおよびJavaScriptコミュニティと協力して、TypeScriptの最良かつ最速の実装を共に構築することに興奮しています。