Ping’s ts-rust repository reports an LLM-driven Rust port of the TypeScript compiler, type checker and language server, with all 181,711 ported Go tests passing. The project offers an npm package, tsc-rs, and reports faster type checks than the Go compiler on its published app benchmarks. Its author also says he has never read a line of the code.
The project gives developers a concrete case to examine when asking how far coding agents can take a large port. The README describes a working implementation with compatibility tests and known defects. Whether it can replace a team’s compiler depends on which TypeScript revision that team uses, how it builds projects and what it needs from the editor.
The successful attempt followed months of failed work
The author says GPT-5.6 Sol and GPT 6 Astra produced more than 1.3 million lines of Rust over several months of automated goal loops. He values those tokens at more than $400,000 at API prices and says compatibility stalled around 84%.
He then tried Opus 5.5 through Claude Code. According to his account, it produced a working first version in ten hours and started from scratch rather than continuing the earlier code. He let it run for two weeks, reporting roughly $24,047 in API-valued token usage through his Claude accounts. The README describes usage against $200-plan weekly limits, so the token valuation alone does not establish his actual cash spending.
These are the author’s accounts of successive attempts. The README supplies too little shared detail about prompts and execution conditions to treat the outcome as a controlled model comparison.
The author marks a section called “The Slop Line” and says the LLMs wrote everything below it. That includes the detailed compatibility and benchmark reports. Those reports are project claims, rather than results we reproduced.
What the port reports today
ts-rust ports Microsoft’s native Go implementation of TypeScript. It pins compatibility to upstream revision 673a5f17d713, dated September 29, 2026, for TypeScript 7.1.0-dev. The README directs users to compare it with typescript@7.1.0-dev.20260929.1.
The project reports identical diagnostics for TanStack Query core and Hono, passing language-server and API comparison tests, and checks against 120 open-source repositories. Its known differences include extra emitted files and TS6059 errors in some monorepos. Build mode can also read old or missing outputs when projects omit a needed project reference. During long editor sessions, it reports memory growth of about 20 MiB per 1,000 edits.
The npm package supports Linux x64 and macOS arm64. The repository also contains a WebAssembly build. It integrates Effect diagnostics, but the Effect-specific editor work, such as quick fixes and refactors, remains unported.
The speed claim depends on the workload
The README’s six-app benchmark reports a geometric-mean speedup of 1.61 times over TypeScript 7. It measures native binaries on an Apple M4 Pro, using the median of five runs after one warmup. The commands disable output generation and incremental checking.
Two rows show why both elapsed time and relative speed matter:
| App | TypeScript 7 | ts-rust | Time saved per check |
|---|---|---|---|
| VS Code | 6.84 seconds | 4.20 seconds | 2.64 seconds |
| tRPC server package | 0.16 seconds | 0.09 seconds | 0.07 seconds |
The saved times are our subtraction of the published figures. Bun’s checker is faster than ts-rust on five of the six apps, though the README reports extra Bun errors on Sentry and tRPC. The distributed preview packages also omit the profile-guided and binary optimizations used for the project’s faster measured build.
Hacker News asks who will maintain it
In the Hacker News discussion, DanRosenwasser, identifying himself as a TypeScript team member, called the work impressive and said the team hoped to learn more. Other commenters questioned whether passing inherited tests establishes coverage for untested behavior.
The discussion also separates utility from maintenance. yoyohello13 questioned the reason to adopt a less-maintained implementation, while rowanG077 pointed to its reported speed. anonymous908213 raised the difficulty of changing code that nobody has read. Rapzid challenged the use of API-valued tokens as a statement of actual cost. Those concerns turn the adoption question toward future fixes and updates as well as today’s test results.
