tsc の代替実装を作る話、とりわけ Rust や Go で tsc を高速化した移植版を作る話について。非常に野心的で面白いと思いつつ、正直僕は実用レベルまで達したものが本当に登場するのか疑問に思っている。今ある型システムもそうだし、新機能として追加されるものにも追従する必要がある。当然、実用レベルとして使ってもらうには、不具合も少なくないといけない。
それに tsc も最近はパフォーマンス改善に力を入れているように見えている。実際にリリースノートを見ると、ちょくちょくパフォーマンス改善系の変更が入っている。
- TypeScript: Documentation - TypeScript 4.8
- TypeScript: Documentation - TypeScript 4.9
- TypeScript: Documentation - TypeScript 5.0
- TypeScript: Documentation - TypeScript 5.1
- TypeScript: Documentation - TypeScript 5.3
tsc に追いつこうと思うなら型システムの実装をする傍ら、こうしたパフォーマンス改善も取り込む必要があるかもしれない。
とはいえ、仕様は tsc を真似すれば良いので、本家 tsc を作るよりは楽だとは思う。tsc にあるものを、そのまま真似すれば良い。例えば、tsc では Node.js ESM を TypeScript でサポートするための仕様 (--module node16) を何年も掛けて練っていたが、移植する側はそれを省略できる。
といっても Microsoft の優秀なエンジニアを何人も動員してやっと作ってるものを真似するには、それと張り合える開発リソースが必要になる。しかし、そんな開発リソース用意できるのかという。圧倒的な個人技™ を持った人、または集団がいれば話は変わってきそうだけど...
stc の開発終了
なぜこんなことに突然思いを馳せているかというと、tsc を Rust に移植するプロジェクトである「stc」が開発終了したから。
開発を終了させた理由も簡潔に述べられていた。
TypeScript was not something that I could follow up on in an alternative language.
https://github.com/swc-project/swc/issues/571#issuecomment-1915966297 より
なんとも侘しい。
Microsoft が別の言語で rewrite するという道
MS が tsc を TypeScript で書くのをやめて、Rust などに rewrite してくれれば話は早いのだけど、どうなんでしょうね。自分たちで言語の問題点を見つけてブラッシュアップするにはドッグフーディングが重要なのだけど。ドッグフーディングと速度どっちを取るかという問題が発生する。
少なくとも、Microsoft は tsc と VS Code の両方を、ドッグフーディングのために TypeScript で書いている (TypeScript のドキュメンタリーの 9:14〜15:46 の部分で言及されている)。
tsc の高速版が欲しい背景と、その解決策
そもそも誰が tsc の高速版が欲しいと言っていたのだろうか。どこかにまとまっている訳ではないけど、界隈の様子を見るに、こういう感じだと思う:
- 型チェックの時間を短縮したい人
- 少しでも時間を短縮したいから、単に速いのが好きだから、大規模プロジェクトで型チェックが遅すぎて困っているから、など理由は様々
- no-floating-promises などの型情報を使った rule を実装したい Linter 開発者
- deno_lint, biome, oxc
- TypeScript と他言語で型情報を高速にやり取りをするのが難しいので、別言語 (Rust) 実装が欲しいというモチベーション
前者であれば、tsc そのものが改善していくことである程度要求を満たせるとは思う(もちろん、型チェッカーが爆速であるに越したことはないが)。
後者については、stc のようなものを頼らずに解決を測る動きが出ている。例えば oxc では、「モジュールから export される関数や変数に明示的な型注釈を付ける」という制約を課した上で、型情報を用いた lint を実装方針のようだった。この制約を課せば、モジュールグラフ全体を辿らなくとも、lint に必要な型情報を得られるようになる。つまり、型情報を使った lint を高速に行えるようになる。
biome も Roadmap で似たような計画を発表している。
この辺の話は以下のスライドに詳しくまとまっているので、読んでみてほしい。
lint に掛かる時間に悩まされている大規模なプロジェクトであれば、そうした制約を受け入れる価値があると思う。一方、小規模なプロジェクトはどうなんだろう。本当は型推論を駆使して簡潔に書けるはずなのに、制約のせいで明示的に型注釈を書く必要がある...という煩わしさが少なくともある。小規模プロジェクトでは、速度向上による旨味が少ないので、煩わしさのほうが目立ってしまうかもしれない。
まあでもどうなるのか正直わからないなー。型注釈を書くことをそう煩わしく感じないかもしれない。エディタの言語機能や Copilot が勝手に型注釈を補完してくれたら、それなりに煩わしさも軽減されそう。とりあえず試してみたいかな。
代替実装を作るということ
tsc の代替実装を作るのは非常に難しいし、なくてもなんとかなる、と言ってもそれを作る価値は十分あると思う。速度が改善されることで、今までできなかったことができるようになる。制約なんか取っ払って、型推論効かせまくっても型情報使った高速 linter 作れるぜ！ というのは憧れる。本当にできるのなら、是非この目で見てみたい。
まあでも、大変だと思います。
Hohndel氏は最後の質問で、Torvalds氏がLinuxと「Git」に続く別の大規模プロジェクトに取り組むつもりがあるかを聞いた。Torvalds氏は、そうならないことを願っている。
同氏は次のように答えた。「絶対にそうなってほしくない。というのも、これまでに始めたすべてのプロジェクトは、他の人々が不適任であることや金銭目的であることに対するいら立ちがきっかけだったからだ。Linuxを始めた理由は、本物を買う余裕がなかったことだった。そして、こう思った。『どれくらい大変だろうか』と。その答えは『とても大変そう』だ。33年経った今もここにいて、Linuxに取り組んでいるのだから」
トーバルズ氏が語った「XZ Utils」バックドア問題、AIの誇大宣伝 - (page 2) - ZDNET Japan より
