Port of the TypeScript compiler, checker and lsp to Rust, by LLM
LLM-driven ports of the TypeScript compiler and type checker to Rust are raising questions about cost, performance, and maintainability. Commenters debate the headline claim of “$400k of API tokens” (largely subsidized via subscriptions), compare OpenAI and Anthropic models’ effectiveness on this task, and weigh Rust against Go and JavaScript for compilers, especially when targeting WebAssembly. Many see the project as a striking proof-of-concept—faster than the official toolchain but likely unmaintained—and as an early glimpse of a future where large, complex systems are routinely machine-translated between languages.
Project Cost and LLM Economics
- The README’s “$400k in API-priced tokens” sparked extensive debate.
- Multiple comments note this is a theoretical API-equivalent cost; in practice it was done via subscriptions and evaluation credits, with actual spend reported around ~$24k and possibly much less for the final successful pass.
- Some argue quoting API-equivalent cost is misleading “flexing”; others say it’s useful to signal what the work would cost at list prices.
- There’s discussion of whether AI companies “lose money” on heavy subscription users; some point to high reported gross margins and argue subscriptions are at least break-even.
Rust vs Go vs JS and WASM
- Several comments note this is effectively a Rust port of a Go rewrite of the original TypeScript compiler.
- Debate over Go vs Rust: Go was chosen for ergonomics and ease of porting; Rust is argued to be better for performance and WebAssembly (smaller, faster binaries, minimal runtime).
- Others say Go can also target WASM (especially TinyGo) and that GC vs non-GC isn’t a simple “faster/slower” story.
- Some argue JS was never seriously considered as the new implementation language and that this was a missed opportunity; others point out TS was originally in JS.
LLMs as Coders: Quality, Testing, and Trust
- The port was largely produced by LLMs, with one model (Opus) significantly outperforming earlier OpenAI attempts in speed and progress.
- The author states they “never read a line of this code,” alarming some commenters who see this as irresponsible; others claim passing the full TS test suite is sufficient.
- Concerns raised: hidden gaps where original tests relied on “common sense”; maintainability of code no human understands; long-term evolution under changing requirements.
- Counterpoint: for heavily tested systems, agents iterating against tests may leave fewer gaps than humans, and future workflows may center on adding tests rather than manually editing code.
Seriousness, Impact, and Emotional Reactions
- Some see the project as a meme/experiment unlikely to be maintained, akin to “running Doom on a microwave,” but still important as a capability demo.
- Others emphasize real utility: reported 1.6–4x speedups over tsc in some real-world projects, and better suitability for WASM deployments.
- Emotional divide: some feel AI rewrites “remove the craft” and make such projects less inspiring; others focus on the explosion of what’s practically possible when development cost drops dramatically.