Theo's tsc-rs: TypeScript Compiler in Rust (2026)

Theo's tsc-rs is an experimental Rust port of Microsoft's TypeScript 7 compiler. It can be tested as a faster checker, but its current evidence supports a controlled evaluation, not a blind production replacement.

By Max Wells, updated October 11, 2026

TL;DR: Theo Browne's ts-rust, distributed as tsc-rs, is an experimental Rust port of Microsoft's native TypeScript 7 compiler. It targets the compiler, checker, language server, and API, not TypeScript applications. The repository reports matching results across its test and project comparisons, plus a 1.89x geometric mean speedup over TypeScript 7 on six open-source apps. Bun is faster in that same table. The useful verdict is to test tsc-rs in CI or a pinned local workflow, not replace a production toolchain because a Rust benchmark looks good.

• Project: pingdotgg/ts-rust, also called tsc-rs
• Baseline: Microsoft's TypeScript 7 native compiler written in Go
• Reported result: 1.89x faster than TypeScript 7 in the repository's six-app geometric mean
• Important limit: the measurements are project-reported, the port is experimental, and Bun is faster overall in the same comparison

What Is Theo's tsc-rs Project?

tsc-rs is a Rust implementation of the native TypeScript 7 compiler toolchain, not a tool that rewrites TypeScript applications into Rust. Theo Browne's public ts-rust repository aims to preserve the behavior of Microsoft's Go implementation while changing the implementation language and runtime.

That scope makes the project more interesting than another TypeScript versus Rust opinion piece. TypeScript remains the language developers write. Rust becomes the language used to implement the tool that parses, checks, emits, and serves that TypeScript code.

The repository describes four targets:

• the command-line compiler with the familiar tsc shape;
• the type checker and diagnostics;
• the language server used by editors;
• an API intended to match the upstream compiler's behavior.

The repository is also unusually explicit about its origin. Theo says the project started as an experiment to see whether LLMs could port the TypeScript compiler, checker, and language server to Rust. Earlier model runs did not reach the desired compatibility level. A later Claude Opus 5.5 run produced a working version, according to the project's own account.

That is the news hook. The technical question is not whether an AI can print Rust quickly. It is whether a generated Rust implementation can preserve a large, behavior-sensitive compiler well enough to be useful to real TypeScript projects.

The Important Distinction: Compiler Port, Not Application Migration

tsc-rs rewrites compiler tooling in Rust, not TypeScript applications. The phrase “TypeScript rewritten in Rust” can create the wrong mental model. tsc-rs does not take a Next.js application, a Node.js API, or a React codebase and convert it into Rust. It replaces part of the developer tooling used to understand that code.

Application source
    |
    v
TypeScript files, tsconfig, declarations
    |
    v
tsc-rs: parser, checker, diagnostics, language server
    |
    v
Compiler output and editor feedback

The application can remain TypeScript. A team can install tsc-rs as a development dependency, point it at a tsconfig.json, and compare its diagnostics with the compiler already used in CI. The migration boundary is the toolchain, not the product runtime.

This distinction also prevents a common SEO and engineering mistake. A search for “Rust TypeScript compiler” has a different intent from “Rust versus TypeScript for backend development.” The first asks whether a compiler implementation is credible. The second asks which language a team should use to build an application. tsc-rs answers the first question only.

Why Microsoft Go Is the Right Baseline

Microsoft's Go implementation is the correct baseline for evaluating tsc-rs, not only the older JavaScript compiler. The original TypeScript compiler was implemented in JavaScript and ran through Node.js. Microsoft is now shipping a native TypeScript implementation in Go under the TypeScript 7 project. Its TypeScript 7 announcement reports large speed and memory improvements over TypeScript 6 on selected projects.

That means an honest tsc-rs comparison needs three labels:

Saying that tsc-rs is 13.4x faster than TypeScript 6 sounds impressive but skips the most relevant competitor. The repository's own real-world table reports tsc-rs at 1.89x faster than TypeScript 7 by geometric mean. That is the number that matters when evaluating a Rust implementation against Microsoft's current native direction.

The Go baseline also makes compatibility central. This is not a greenfield compiler that can choose a simpler language subset. It tries to follow the behavior of a moving upstream implementation, including diagnostics, project configuration, editor behavior, and edge cases that application benchmarks rarely expose.

What Theo's Experiment Actually Tested

Theo's project tests whether agents can preserve compiler behavior at systems scale, not merely generate a large amount of Rust. The repository README reports more than $420,000 in API-priced tokens across earlier attempts using OpenAI models, with those attempts reaching roughly 84 percent compatibility. It then attributes a working version to Claude Opus 5.5, with about $24,047 in API spend over two weeks.

Those amounts are project history, not a normal cost estimate for a compiler team. They still reveal the shape of the experiment:

Large upstream codebase
    |
    v
Agent-generated Rust port
    |
    v
Compatibility tests and Go comparison
    |
    v
Real repositories and benchmark runs

The compelling part is the feedback loop. A compiler port has a large oracle: the upstream implementation can run the same inputs and produce a result to compare against. That makes it unusually suitable for agents. The model does not need a human to judge every line immediately. Tests can expose behavioral differences, and the agent can iterate against concrete failures.

This does not mean compiler ports are easy. It means they provide a better evaluation environment than vague application prompts. “Build a good backend” is hard to score. “Given this project and this configuration, produce the same diagnostics as the reference compiler” creates a measurable target.

The README also says the repository author has not read a line of the generated code. That is a provocative detail, not a production recommendation. It demonstrates how far an external evaluation loop can carry an experiment. It does not remove the need for code ownership when a compiler becomes a critical part of a company's build or editor workflow.

The Speed Result Is Strong, But Bun Wins the Headline Table

tsc-rs is faster than TypeScript 7 in the repository's six-app benchmark, but Bun is faster overall in the same table. The repository's most useful benchmark checks six real open-source applications with TypeScript 6, TypeScript 7, tsc-rs, and bun check. It uses an Apple M4 Pro with 12 cores and 48 GB of memory, five measured runs after one warmup run, and --noEmit --incremental false.

The reported times are:

Compared with TypeScript 7, the repository reports tsc-rs as 1.89x faster and Bun as 2.95x faster by geometric mean. Bun is faster on every listed application except tRPC.

That weakens the lazy headline “Rust beats every TypeScript checker.” It strengthens a more precise conclusion: a Rust port can preserve TypeScript 7's output model while delivering a meaningful speedup, but implementation language alone does not guarantee the fastest checker. Bun's architecture makes a different tradeoff, including a shared type store across cores.

The output difference matters. The repository says Bun produced diagnostics different from TypeScript 7 on some projects, including additional errors in T3 Code. tsc-rs keeps the TypeScript 7 model because its goal is matching output, even when that limits the opportunity to change the internal algorithm. A faster result is only useful if it still answers the questions a team expects its compiler to answer.

The benchmark also needs a version warning. The GitHub page showed tsc-rs 0.3.0 as the latest release when this article was researched, while the README's six-app measurements identify the measured binary as tsc-rs 0.2.0. Do not present those measurements as a clean benchmark of every 0.3.0 build. Fast-moving repositories need version-pinned comparisons.

Compatibility Is the Real Product

A compiler is useful only when its diagnostics and outputs remain trustworthy for the projects that depend on it.

Compiler speed attracts attention. Compatibility determines whether a team can adopt the tool.

The repository reports that all 181,711 ported Go tests pass. It also says TanStack Query core and Hono produce diagnostics identical to Go, that language server and API answers match Go on oracle test sets, and that 120 open-source repositories differ from Go only in documented cases or cases where Go's own output varies with timing.

These are encouraging signals because they test more than a single synthetic project. Still, they remain repository claims. The right wording is “the project reports,” not “independent testing proves.”

The pinned upstream revision is also important. The repository follows Microsoft TypeScript commit 673a5f17d713, dated September 29, 2026, and labels it TypeScript 7.1.0-dev. A difference between tsc-rs and an installed TypeScript version may be a real port bug, or it may come from comparing different upstream revisions.

tsc-rs result
    compared with
TypeScript Go result at the same pinned revision
    not automatically compared with
Whatever TypeScript version a project installed yesterday

This is normal for compiler work. A team needs to pin the reference version, run the same project configurations, compare diagnostics, and record any intentional differences. “Drop-in replacement” is a project-specific claim, not a permanent property attached to the package name.

Where the Port Still Needs Engineering Judgment

The repository's known problems are adoption requirements, not footnotes.

The repository lists several known problems. They are not reasons to dismiss the project. They are exactly the details a team needs before making it part of a production workflow.

Monorepo file ownership can differ. In some workspaces, a source file is reachable through both node_modules and a direct import. tsc-rs can write output for more files and report TS6059 where TypeScript makes a timing-sensitive decision.

Project references can expose build timing. With tsc -b, one project can consume another project's output while that output is being written. The Go implementation and tsc-rs may observe different states. The repository recommends adding the missing project reference when this occurs.

Long editor sessions need monitoring. The README reports memory growth of about 20 MiB per 1,000 edits in measured sessions. It says the process starts above TypeScript's memory use, then stays below it after roughly 20 edits in those sessions. That is useful evidence, but not a guarantee for every editor workload.

Version output can surprise scripts. tsc-rs --version reports the TypeScript revision it ports, not the npm package version. CI and release scripts should not assume those values are interchangeable.

Effect support is partial. The project includes Effect diagnostics in the same check, but the README says editor features such as quick fixes, refactors, hover, and completions are not ported. A team should test the editor experience separately from command-line checking.

These limitations create a practical rule: test the exact workflow that matters. A green compiler run on a small package says little about a large monorepo with project references, editor sessions, generated sources, and custom language service plugins.

Can You Use tsc-rs Today?

You can use tsc-rs today as a controlled experiment, but not as an automatic replacement for the only compiler in a production pipeline.

Yes, as a controlled experiment. No, as an automatic replacement for the only compiler in a production pipeline.

The install path is intentionally small:

npm install -D tsc-rs
npx tsc-rs -p tsconfig.json

A safer evaluation path looks like this:

1. Pin the package version and the upstream TypeScript revision in the experiment notes.
2. Run the existing tsc and tsc-rs against the same clean checkout.
3. Compare exit codes, diagnostics, emitted declarations, and generated output.
4. Test project references, monorepo package boundaries, editor startup, and long edit sessions.
5. Measure the full CI step, not only compiler time. Installation, cache behavior, process startup, and downstream tasks can dominate a small project.
6. Keep the established compiler available as a fallback while the comparison runs for several releases.

For a TypeScript team, the first win may be a faster local check or a faster CI validation job. It does not require migrating application code to Rust. For a platform team, the experiment can also show whether a native checker reduces enough compute or feedback latency to justify a new toolchain dependency.

The T3 Code pull request is a useful example of this evaluation style. Its title calls the change “WIP, experimental.” That wording is healthy. A real repository integration is stronger evidence than a toy benchmark, but a pull request is not broad production adoption.

What This Means for Rust and TypeScript Engineers

The project expands Rust's role from application runtime to the developer tooling underneath millions of TypeScript projects. Rust is not only competing to run web servers, databases, or game engines. It can also sit underneath the tools used by millions of TypeScript developers.

For Rust engineers, the valuable skills are compiler implementation, incremental computation, diagnostics, language server protocols, file-system behavior, and benchmark design. For TypeScript engineers, understanding the toolchain boundary becomes more valuable. The application can stay in TypeScript while the compiler underneath becomes native Rust or Go.

For engineering leaders, the decision is less about language loyalty and more about feedback economics:

Developer edit
    -> type check
    -> diagnostic or editor response
    -> correction
    -> next edit

If a team runs millions of checks, or if slow feedback blocks every developer, a faster checker has compounding value. If the project is small, if editor compatibility is more important than raw CLI time, or if the current compiler already fits inside the team's budget, migration may create more risk than benefit.

The agent angle changes hiring less than it changes review. An AI can generate a compiler port, but somebody still needs to understand semantic compatibility, memory behavior, concurrency, release pinning, and failure diagnosis. The strongest profile is a developer who understands TypeScript's user-facing behavior and Rust's systems tradeoffs well enough to test the bridge between them.

Is tsc-rs Better Than TypeScript 7?

Not universally. tsc-rs is promising when a project values TypeScript 7-compatible output and wants to test a faster native implementation. It is not yet a blanket replacement for Microsoft's Go compiler, and the repository's own benchmark shows Bun ahead overall.

The practical ranking depends on the requirement:

This is why the project deserves attention without deserving hype. It shows that a Rust port can be fast, broad, and behavior-focused. It does not establish that Rust is the best implementation language for every compiler, or that a compiler with passing tests is automatically ready for every editor and build system.

Frequently Asked Questions

The Bottom Line

Theo's tsc-rs is strong evidence that agent-assisted Rust compiler work is worth testing, not proof that it is ready to replace TypeScript 7 everywhere.

Theo's tsc-rs is strong news because it tests an important boundary: can agents produce a systems-level Rust implementation while an existing compiler provides a behavioral oracle?

The current answer is promising but bounded. The repository reports broad compatibility, a meaningful speedup over Microsoft's Go implementation, and a package that real TypeScript projects can try. It also reports known monorepo, project reference, editor, version, and plugin limitations. Its benchmark shows Bun faster overall, and its newest release is moving faster than its published benchmark labels.

For TypeScript teams, run a pinned comparison before making a decision. For Rust engineers, study the project as evidence that compiler tooling and developer infrastructure are becoming serious Rust use cases. For everyone, keep the central lesson precise: tsc-rs is a compiler port experiment, not proof that Rust replaces TypeScript or that AI removes the need for technical ownership.

Related Rustify Articles

• Rust vs TypeScript for full-stack development
• How to move from a TypeScript backend to Rust
• Why GitHub rewrote the Copilot runtime in Rust
• Building AI agents from scratch in Rust

Sources

• Theo Browne's pingdotgg/ts-rust repository
• The ts-rust release page
• Microsoft's TypeScript 7 announcement
• Microsoft TypeScript repository
• T3 Code pull request testing tsc-rs