将 TypeScript 编译器、检查器和 lsp 移植到 Rust，由 LLM 提供

我想看看法学硕士是否可以将 TypeScript 编译器、检查器和 lsp 移植到 Rust。事实证明他们可以。完成这项工作需要花费超过 420,000 美元的代币，但您可能只需大约 2 万美元就可以完成（见下文） 测试模型功能 制作一个快速的 TypeScript 类型检查器 制作一个可以在 WASM 中使用高性能 Memes 的 ts 检查器 这是一个早期版本。它在我们测试过的每个现实世界项目中都具有 100% 的兼容性。它应该可以作为绝大多数应用程序的替代品。请参阅已知问题。另外值得一提的是：我从来没有读过这段代码。请注意，我不知道这是否真的有效。 npm install -D tsc-rs npx tsc-rs -p tsconfig.json 我使用了很多 OpenAI 模型来尝试完成这个移植。我使用 GPT-5.6 Sol 和 GPT 6 Astra 总共完成了超过 400,000 美元的 API 定价代币。他们在几个月的 /goal 循环中编写了超过 130 万行 Rust，但从未达到 84% 的兼容性。当我看到我的 Claude Code 限制燃烧得如此之少时，我认为将 Opus 5.5 扔到这里会很有趣。它在 10 小时内就完成了工作 v0。我假设它继续使用 Codex 模型编写的代码。我错了。 Opus 5.5 从头开始​​。它只用了 1/10 的时间就比 Astra 走得更远。我让它继续下去，而且确实如此。两周内 API 支出的代币总支出约为 24,047 美元。我使用的是我的 Claude 账户，结果达到了我 200 美元计划每周限额的 925% 到 983% 之间。当然，价格昂贵，但考虑到 typescript-go 投入了多少工作，这也不算太糟糕。下面的所有内容都是由我的法学硕士撰写的，而不是我。 ts-rust 是 Microsoft 原生 TypeScript 编译器的直接移植，它是用 Go 编写的（ microsoft/TypeScript ，以前的 typescript-go ）。它保留了 Go 的算法和行为，并具有相同的命令行 ( tsc )、语言服务器和 API。 npm install -D tsc-rs npx tsc-rs -p tsconfig.json tsc-rs 采用与 tsc 相同的选项。 npm 包是 tsc-rs，因此它不会与 typescript 包冲突。每个版本还为每个平台提供了一个独立的存档：tsc 二进制文件及其旁边的 lib 文件。平台：Linux x64（静态，任何发行版）和 macOS arm64。 Windows 和 Linux arm64 尚不可用。要在 VS Code 中使用它，请参阅 npm 包 README 。 tsc-rs 内置了 Effect 语言服务诊断（代码 377xxx），因此 Effect 项目不需要第二个编译器。它们来自与 TypeScript 诊断相同的检查，语言服务器也会显示它们。它们仅在 tsconfig 具有插件时运行，如 @effect/language-service : { "compilerOptions" : { "plugins" : [{ "name" : " @effect/language-service " }] } } 规则、选项和 @effect-diagnostics 注释是 Effect-TS/tsgo 0.46.1 的端口。语言服务的编辑器功能（快速修复、重构、悬停、补全）未移植。该端口固定到一个上游修订版 microsoft/TypeScript 673a5f17d713 （2026-09-29，TypeScript 7.1.0-dev； UPSTREAM.md ），并与该修订版的 Go 进行比较。要进行比较，请使用 typescript@7.1.0-dev.20260929.1 ，而不是 7.0.x 或 @typescript/native-preview 。此构建还显示的一个差异是上游行为，当端口移动到较新的引脚时，它就会消失。结果相同。 TanStack Query 核心和 Hono 检查与 Go 的诊断相同。所有 181,711 个移植的 Go 测试均通过。语言服务器和 API 答案在 oracle 测试集上与 Go 匹配。快点。在 60 个开源项目中，类型检查大约花费了 Go 一半的时间（几何平均值）。预览包是在 CI 中构建的，没有 PGO 和 BOLT，因此它们比测量的构建慢。真实的项目。在 120 个开源存储库中，命令行输出与 Go 的不同之处仅在于以下问题以及 Go 自己的输出在每次运行时发生变化。 T3 Code 的完整类型检查，与 tsc 6、tsc 7 和 Bun 中的新 Bun 检查进行比较。 T3 Code 使用 Effect，因此有两种情况：不使用 Effect 诊断和使用 Effect 诊断。每次都是五个 T3 代码项目的总和。越低则越快。无效果诊断 检查器时间 vs tsc 6 vs tsc 7 面包检查 4.07s 15.4× 3.95× 更快 █ tsc-rs 7.25s 8.6× 2.22× 更快 ██ tsc 7 16.10s 3.9× 基线 █████ tsc 6 62.63s 基线 3.89× 慢██████████████████ 使用效果诊断检查器时间 vs tsc 6 vs tsc 7 + Effect tsc-rs（内置效果） 11.13s 12.5× 1.89× 更快 ███ tsc 7 + @effect/tsgo 21.07s 6.6× 基线 ██████ 面包检查，然后effect-tsgo诊断 37.60s 3.7× 1.78× 较慢 ███████████ tsc 6 + @effect/language-service 138.63s 基线 6.58× 较慢 █████████████████████████████████████████ 当您不需要效果诊断时，bun 检查是最快的。它没有它们，因此 Effect 项目需要第二遍。 tsc-rs 从其一张支票中获取它们。错误。 tsc-rs 、 tsc 7 + @effect/tsgo 和effect-tsgo 诊断传递报告相同的221 Effect 诊断。 tsc 6 使用 JavaScript Effect 插件 (@effect/language-service 0.87.4)，它有一个不同的规则集：它报告