TypeScriptコンパイラのRust移植、本家開発者も驚く1週間で3例目
姉妹サイトの新着
Microsoftは2025年、公式のTypeScriptコンパイラをGoで書き直すネイティブ移植(通称tsc7)を進めてきたが、今度はコミュニティ発のRust版移植がHacker Newsで話題になった。TypeScript開発チームのDaniel Rosenwasser氏も「この1週間で同種の移植が3つも出てきた」と反応し注目を集めた。スレッドでは、AIエージェントを使った開発コスト(理論上40万ドル相当という主張)の実態や、Rustを選ぶ意味、本格運用されない移植版の実用的な価値について意見が分かれた。
TypeScriptコンパイラ(tsc)をRustに移植
出典: github.com / 元記事はこちら
TypeScriptチームの人間です。これは本当にすごい仕事で、しかもこの1週間で同じような移植が3つも出てきたのは正直クレイジーですね。今は離席中ですが、詳しく調べた上でまた近いうちにコメントします。
この先はこうなるんじゃないかな。AIエージェントにこの移植版を調べさせて、Go版と比較して本当に使える部分を見つけ、良いアイデアだけ本家コンパイラに取り入れる、みたいな流れ。まあ分からないけど、何にせよ変化が速すぎる。
よく追いついていて立派だと思う。最初にGoへ移植したときは妥当な選択に見えたけど、世の中の変化は本当に速いね。
実際のプロジェクトでの検証部分では、tsc7と比べてコンパイル時間が1〜3秒短くなっていた。こういうのは割合で見たほうが絶対値よりずっと印象的に見えることがある。
AnthropicやOpenAIが無料でトークンをくれたら、自分もこういう思いつきのプロジェクトを作れるのに。両方のサブスクには入ってるけど、トークンはもう他のプロジェクトで使い切ってる。
このスレのタイトルは『TypeScriptコンパイラのGo版書き直しのRust移植』にするべきだね。
Rustへの移植を助けるような、特別な仕組みやテクニックって何かあるの?特にトークン効率の面で。
できる限りLLMを使わない機械的な検証で、しかも分かりやすい診断メッセージを出せるものにすること。変換のステップも同様に機械的かつ診断メッセージ付きにして、さらに手戻りを減らすための良いメモリ機構を用意する、といったあたりかな。
unsafeをどれくらい使っているのか気になる。これらの移植版はRustらしい書き方をしているのか、それともunsafeを乱用しているだけなのか。READMEには特に書かれていないみたいだし。
自分で見てみるといいよ。ざっと見た感じunsafeは使われていないみたいだし、unsafeコードを避けることが明確な目標になっていたようだ。
ちょっと待って、40万ドル以上使ったってこと?
いや、それは複数の上位プラン(20倍プラン)を組み合わせて使った場合の、理論上のトークン価値でしかないよ。
サブスクで使ったトークンを、API料金換算の金額でマウントする人が結構いるよね。正直バカバカしいと思う。コストというのは実際に自分が払った額であって、他の人が払ったかもしれない額じゃない。市場原理からしてもそうだ。AWSのスポットインスタンスを使っておきながら、オンデマンド料金換算の金額を自慢するようなものだ。
40万ドル分のトークンを使ったとして、それがサブスク経由だとしたら、AI企業側はこれでどれくらい損をしたんだろう。(追記:別に心配してるわけじゃなくて、単に気になっただけ)
『スロップ・ライン』――ここより下はすべて自分のLLMが書いたもので、自分の言葉ではありません、というルール。こういう決め事、本当にありがたいと思う。
正直、この先テック業界がどうなるのか全く想像がつかない。変わりすぎた。
これは本格的なプロジェクトになる?いや、ならない。メンテナンスされ続ける?それもない。でも、これやこの手の他の試みは『何ができるか』を示している。電子レンジにDOOMを移植するようなものだ。この時期のことは、みんなが新しいギアを見つけた時代として、後から懐かしく振り返ることになると思う。
何かを作るとき、普通は『これで何を学べるか』ではなく『これは何に使えるか』で考えるものだと思う。家を建てて『これで何を学べるか』なんて聞かないでしょう。実用性を目指しているものに対してその問いを第一に持ってくるのは、正直ちょっとひねくれていると思う。これに価値がある理由は明白で、本家のtscよりずっと速いからだ。
その大部分はOpenAIのトークンに使われて無駄になったらしい。GitHubの説明によると、実際にかかったのは2万4000ドルとのこと。
他の(今は非表示になっている)コメントでも指摘されていたけど、それはAPI経由で計算した場合の推定額で、実際にはサブスク料金で数百〜数千ドル程度だったはずだよ。
トークン換算で42万ドル分、とはいってもほぼ確実にサブスクを使っていたはずだ。
『API料金換算で40万ドル以上使った』とあるけど、これは数ヶ月分のサブスク料金であって、トークンを直接購入したわけじゃないと思う。
だからこそ元のコメントは『これはメンテナンスもテストも不十分な実装にすぎない』と言っていたわけで、だから『これで何を学べるのか』と聞いたんだと思う。リスクのあるツールだからこそでしょ。あなたは話を必要以上に奇妙にしようとしている。
言いたいのは、これは単に『メンテナンスもテストも不十分な実装』では済まされないということ。実際のアプリで1.61倍速くなっていて、場合によっては4倍近く速くなっているケースすらある。
それが言いたかったことなら、なんで『これで何を学べるのかなんて、ひねくれた質問だ』って一段落かけて書いたの?
なぜそんなに速くなるのか気になる。Goはガベージコレクタを除けばRustに比べてそれほど遅いわけじゃないはずなのに。4倍の性能向上というのは、思っていたより大きい。
なぜGoがもう妥当な選択じゃないと思うの?
おそらく、AIエージェントによるコーディングにはRustの方がGoより向いているから、ということなんじゃないかな(確信はないけど、そういう説明っぽい)。
RustのほうがWebAssemblyへのターゲットとして優れているから。
この場合は、単に『これをやるのにどれくらいのコストがかかったか』の目安を示しているだけで、それが正しい基準だと主張しているわけじゃないと思う。
他サイトの新着
『subs』って何のこと?
サブスクリプションのことだよ。
どれだけお金を使っているかを無視すれば、利益は出ているよ。
IPOが楽しみだよ。そうなれば、良くも悪くもこの話にひとまず決着がつくから。
esbuildの作者はRustを使っていたけど、後からGoに切り替えた。その経緯を本人が書いている記事がある。一人の開発者・一つのプロジェクトの話にすぎないけど、読んでいて面白かった。自分はGoが好きだけど、言語を実装するならパターンマッチが欲しいから、最初はRustを試していたと思う。
言語やコンパイラの設計・実装は、かなり人間の仕事だと思う。考慮すべき細かいニュアンスがたくさんあるし、自分たちのコードベースにAIが書いたスパゲッティコードを入れたくもないはずだ。
それがなぜ重要なの?TypeScriptコンパイラをWasmで動かす需要って、かなりニッチな気がするけど。
WasmはRustにとって一級のターゲットで、より速く、より小さいWasmバイナリを生成できる。Goで現実的にWasmをターゲットにするにはTinyGoを使う必要があるはず。GoにガベージコレクタがあることHubこと自体は、Wasm自体にもGCがあるので必ずしも悪いことではないけど、Goは内部ポインタを持つ構造のせいで、GoのGCをそのままWasmのGCに使うのは簡単ではないと思う。
一番のメリットはサイズだと思う。Rustはランタイムを同梱する必要がない。
ガベージコレクタや大掛かりなランタイムがほとんど要らないから、という意味だと思う。直接WASMをターゲットにして、たぶんWASIを使うこともできる。一方Goはガベージコレクタなどを一緒に持ってきてしまう。
この話題の背景と論点
背景として、Microsoftは2025年に公式のTypeScriptコンパイラをGoで書き直すネイティブ移植(通称tsc7)を進めており、本スレで速度比較の基準になっているのはこのGo版である。今回話題のRust版はそれとは別にコミュニティが作った非公式の移植で、AIエージェントによってほぼ自動的に書かれた点が特徴になっている。スレで意見が割れたのは、開発に使った「40万ドル相当のトークン」という数字の解釈だ。これはChatGPTやClaudeなどのサブスクリプションプランを使った場合の、API従量課金に換算した理論上の金額であり、実際に支払った額ではない。実際の支払いは数百〜数千ドル程度だったとみられる。この「API換算額」と「実際の支払額」を混同しやすい点は、AIエージェントによる大規模な自動生成プロジェクトが増えるにつれて、今後も繰り返し話題になりそうな論点だ。
※本記事は海外掲示板 Hacker News のスレッド「Rust Port of TypeScript」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。