ts-rust: An Experimental Rust Port of the TypeScript 7 Compiler
ts-rust ports the TypeScript 7 compiler, type checker, and language server to Rust. Benchmarks show speed gains, but teams still need to test it against their own applications.
On October 7, 2026, a post about ts-rust, an experimental Rust port of the TypeScript compiler, appeared on Hacker News. According to the project description, the author used language models to port the compiler, type checker, and language server from Microsoft’s native Go implementation. It’s an early release: teams interested in faster type checking should try the port on their own projects and compare the results with the corresponding version of the Go compiler, rather than immediately replacing a tool they rely on.
What Was Ported and What It’s Compared Against
ts-rust, also called tsc-rs, reproduces the algorithms and behavior of the Go implementation. It has the same command-line options, as well as a language server and API. The package is published on npm as tsc-rs to avoid a conflict with the typescript package. Archives containing the executable and required libraries are also available for supported platforms.
The port is pinned to the September 29, 2026 revision of TypeScript 7.1.0-dev. That matters when investigating errors: the recommended comparison is with the Go implementation at the same revision, not TypeScript 7.0.x. If tsc-rs reports an error that does not appear in 7.0.2, the cause may be a change in TypeScript’s type checking rather than the port itself.
The author reports that all 181,711 ported Go tests pass. On the test suites, the language server and API responses match the Go version. Across 120 public repositories, the project reports that command-line output differs only in the listed problem cases and where the Go version’s own output varies between runs. That is a broad compatibility check, but not a guarantee for every application.
In benchmarks across six public applications, the geometric mean speedup over tsc 6 was 11.4× for tsc-rs and 7.1× for tsc 7 on Go. The port was 1.61× faster than the Go version. Checking VS Code took 4.20 seconds, compared with 6.84 seconds for tsc 7. Meanwhile, bun check finished in 1.62 seconds, though it reported errors in two applications that the other tools did not find. The measurements were taken on an Apple M4 Pro: each result is the median of five runs after one warm-up run. The difference may be different on other hardware.
Where Results May Still Differ
The project provides installation through npm and runs with a tsconfig.json file. Linux x64 and macOS arm64 are supported; Windows and Linux arm64 builds are not yet available, and no timeline has been given. The repository includes a WebAssembly build, and fast type checking in WASM is one of the project’s goals. The published application comparisons do not provide enough data to assess its speed.
In some monorepos, a package’s source files are accessible both through node_modules and through direct imports. In that case, tsc-rs may emit output files for more of the package’s source files and report a TS6059 error. There is another issue: when building multiple projects without an explicit reference to a dependent project, the compiler may read that project’s outdated or missing output files. For this case, the author suggests adding a project reference. Memory usage also grows gradually during extended editor sessions—by roughly 20 MiB per 1,000 edits in the reported measurements.
For projects using Effect, tsc-rs includes built-in diagnostics that are enabled when the corresponding plugin is specified in tsconfig. That means a second type-checking pass is not needed to get those messages. But Effect’s editor language-service features, including quick fixes, refactoring, hover information, and autocomplete, have not been ported. Matching diagnostics do not mean the entire editor experience will match.
What This Means for a Project Team
Teams responsible for type checking and builds should keep an eye on ts-rust if check times are getting in the way. But a benchmark table is not enough to justify a switch: the port is compared against a specific TypeScript revision, and a project may depend on different settings and build scenarios. Even in the published comparison, four applications needed changes before checking with tsc 7 completed without errors.
A sensible test is to run tsc-rs against your own configuration, compare its diagnostics with the matching Go revision of TypeScript 7.1.0-dev, and test builds and editor behavior separately. If your project uses a monorepo, project references, or Effect, it is especially important to check the listed limitations before discussing a switch. For now, the benchmark results are a reason to experiment, not evidence that the compiler is ready to replace one in a production workflow.
My Take: Speed Needs to Be Verified
I wouldn’t treat the claimed compatibility as sufficient justification for switching. The author says outright that they have not read the generated code, while also listing issues that could surface in a particular build rather than in a benchmark table. To me, that isn’t a reason to dismiss the project. It’s a reason to ask which results the team can reproduce for itself and exactly what it would consider an acceptable discrepancy.
I’m especially wary of the temptation to show only the seconds saved. If the switch leaves necessary editor actions unavailable or changes type-checking output in a monorepo, the time savings still need to be demonstrated. I would first write down the requirements for a replacement, then test them against the team’s configuration—and only then discuss adoption.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
junior web designer
I’m building a portfolio and learning to explain my choices with more than “I think it looks nicer this way.” I analyze real websites and note what exactly gets in the way of completing a user flow.
All posts by the authorRelated articles
Bez Generates a Browser Engine from Web Specifications and Tests
Bez builds a browser engine from web specifications, checking its results against Chromium, Firefox, and WebKit. The project is still at an early stage, and its published figures do not mean the engine is ready.
Next.js Releases Security Updates for Versions 15.5 and 16.3
Next.js has released versions 16.3.8 and 15.5.27 to fix vulnerabilities involving caching, information disclosure, and image optimization. Teams are advised to update their apps and check which features they use.
$mol Adds Node.js Storage Support and New UI Tools
August and September updates to $mol and Giper Dev include Node.js support in $mol_storage, new editor features, and UI tools. Here’s what developers should check.
Discussion 5
Sofia Kyriacou
I’m not convinced that “try it on your own project and compare compile times” is enough to establish whether this is a safe replacement. Matching the Go compiler’s CLI and algorithms does not guarantee identical diagnostics, language-server behavior, or edge cases, and those differences can matter more to a team than raw speed. I’d treat the benchmark as a reason to investigate, not as a decision criterion, and compare correctness and editor workflows alongside performance before switching.
Azizbek Yusupov
@sofia.kyriacou In my projects, compiler upgrades have occasionally changed diagnostics that editor integrations rely on, even when builds still passed; I’d gate ts-rust on CI and language-server checks before considering a switch.
Sardor Tursunov
@azizbek_web, when you say language-server checks, do you mean verifying editor behavior as well as whether the server starts and responds? ts-rust ports the language server too, so diagnostic and completion differences seem worth checking separately from CI builds.
Diana Ilze Post author
I’d check both, but not treat “the server starts and responds” as much of a language-server test. In a few representative files, I’d compare diagnostics, completions, go-to-definition and quick fixes with the Go compiler’s server, then try the same flows in the team’s actual editor; CI can catch build differences, but it won’t tell you whether everyday editor feedback has changed in a disruptive way.
Zuzana Králová
@diana.ihle I’ve seen a compiler change look fine in CI while the editor experience quietly regressed—especially around quick fixes—so I’d add a small prototype-based workflow test with the team’s real editor before rolling ts-rust out. That makes the speed comparison useful without letting a faster check mask a rougher day-to-day flow.