Rewriting TypeScript in Rust with AI in Two Weeks: The Truth Behind TSC-RS

A developer recently announced what sounds like a near-insane project — TSC-RS (TypeScript Rust), a complete Rust rewrite of the TypeScript compiler, type checker, and LSP. What makes it even more dramatic is the author's own account: he had AI agents grinding away for five months, burning through $400K worth of Codex tokens with nothing to show for it — then switched to Opus 5.5, and in just two weeks and roughly $20K, the job was done. Throughout the entire process, he claims he "didn't read a single line of code."

On the surface, this looks like a flashy "vibe coding" experiment. But strip away the $420K headline hook, and it touches on several engineering questions genuinely worth taking seriously: What's the actual ceiling on what AI can do today? Why is the Rust version faster than Microsoft's official Go version? And what does the author actually want — running a complete development experience inside a browser V8 isolate — really mean?

Why Rewriting TypeScript Has Always Been Considered Impossible

To appreciate the difficulty here, you need to understand two distinct parts of the TypeScript compiler. Transpiling TypeScript to JavaScript is actually trivial — you mostly just strip the type annotations. Tools like ESBuild have done this blazingly fast for years. The hard part is type checking, which is also where the most time gets spent.

TypeScript's type system is Turing-complete. It has to faithfully encode all of JavaScript's quirky runtime behavior — variables that change type at runtime, prototype chains, implicit object characteristics. The author offers a sharp analogy: explaining English in English is far easier than explaining English in Spanish. Migrating a type checker from JavaScript to another language is naturally an uphill battle, because when the encoding language and the encoded language differ, complexity multiplies a hundredfold.

This is exactly why the task has long been considered a benchmark for the impossible. The author admits he originally started this project specifically to find something models "absolutely couldn't do" — a way to probe the capability limits of each new generation. With OpenAI's models, the furthest he got was around 84% compatibility, and the closer you got to done, the harder the remaining edge cases became.

TypeScript's type system being Turing-complete isn't just a figure of speech. It means type-level expressions alone can simulate arbitrary computation — conditional types (A extends B ? C : D), recursive types, and mapped types can be combined to run essentially any program at the type level. This makes the type checker fundamentally a problem of solving the undecidable: inferring the result of arbitrarily complex type expressions in finite time. The official TypeScript compiler uses heuristics and depth limits to work around this theoretical bottleneck, but any drop-in replacement aiming for full compatibility must faithfully reproduce these boundary behaviors — not just cover the common paths. This is why the gap between "84% compatible" and "100% compatible" is enormous. The remaining 16% tends to cluster in extreme type gymnastics scenarios that aren't rare at all in large real-world projects like effect and tRPC.

Why Opus Succeeded: It Ported Go, Not JavaScript

The real turning point is buried in the implementation details. When the author dug into the repository, he found something suspicious: it contained a go-std library that ports the Go standard library to Rust line by line — including a Rust reimplementation of goroutines.

This reveals the key to success. Opus wasn't porting TypeScript from JavaScript. It was faithfully translating Microsoft's official Go rewrite (TS Go / TypeScript v7) into Rust, line by line. Go was a far better starting point than JavaScript, because the Microsoft team had already manually encoded all of TypeScript's strange behaviors into Go. What the AI was doing was language-to-language translation, not semantic reconstruction — a far lower bar.

A telling side effect: on the first run, TS Rust was 2–3x slower than the Go version, because the line-by-line port even reimplemented mechanisms like goroutines. The author then set a goal of "at least 2x faster in every dimension," let it run for two weeks, and it got there. There's also a darkly comic detail: the official TS Go had five known issues at the time, and the Rust port faithfully inherited the bugs along with the code. Of six issues in TS Rust, only one was unique to it — the other five were bugs in TypeScript itself. This actually proves it's a high-fidelity drop-in replacement.

Microsoft's TS Go (TypeScript v7) project is essential context here. In late 2024, Microsoft officially announced a Go rewrite of the TypeScript compiler, targeting roughly a 10x speedup for large-project type checking while maintaining full compatibility with the existing TypeScript ecosystem. The core reason for choosing Go was engineering pragmatism: Go's concurrency model (goroutines), memory layout, and coding style align more closely with the original TypeScript compiler's design philosophy, making it easier for the team to understand and maintain. Go also has mature support for native compilation and garbage collection. However, Go's GC makes WebAssembly compilation significantly problematic: GC requires runtime support, which bloats WASM output size and introduces unpredictable pause latencies — poor behavior in browser and edge computing environments. This is exactly the premise for TSC-RS's existence: Go solved the performance problem but gave up the "run anywhere" capability that JavaScript had. Rust delivers both.

Performance Numbers and the Real Cost Breakdown

According to the author's figures, TS Rust is roughly 12.5x faster than TSC 6 (the last JavaScript version), with some scenarios reaching 20x. Against Microsoft's official Go version, it's about 2x faster.

As for that sensational $420K headline, the author ran a more honest accounting. The effective Opus 5.5 work, priced at full API rates, would be around $54K — but he used a subscription. In practice it consumed roughly 10 "weekly quota" units on one account, which works out to about $500 in subscription cost. In other words, the "$420K" is mostly the sunk cost from the earlier OpenAI model experiments plus nominal full-API pricing. The actual productive output cost around $500 in subscription usage.

Worth noting: this isn't the only project in this space. Bun also shipped Bun Check, a Rust-based type checker that's in some cases even faster. But the author points out that Bun Check produces false negatives and false positives on large projects that heavily use complex types — like effect, Sentry, and tRPC — so its fidelity isn't sufficient. TS Rust has built-in support for the effect type-checking plugin and is actually about 4x faster than Bun in real-world scenarios like T3 Chat. His conclusion is measured: for new projects using the full Bun ecosystem, Bun Check is a solid choice; but for a high-fidelity drop-in replacement for the official compiler, TS Rust is more reliable.

The Real Goal: Fitting a Complete Dev Experience into a V8 Isolate

The author keeps emphasizing that performance isn't what he actually cares about. The real reason is WebAssembly.

Go's garbage collector makes it difficult to package into a small, performant WASM binary — which is why TS Go lost the "runs anywhere" property that the JavaScript version had. Rust is a natural fit for WASM. With a Rust type checker, a bold vision becomes feasible: running the entire TypeScript development loop — edit, compile, type check — entirely inside a V8 isolate, rather than a traditional virtual machine.

In the demo he showed, a complete application built by a model runs entirely inside a V8 isolate — even with the filesystem set to read-only — while peak memory stays under 260MB and CPU usage sits around 4%. This borrows from Vercel's Just Bash — a library that fabricates a complete bash environment in memory for agents, making them believe they have real filesystem and process access.

Why does this matter? The author frames it around a cost trajectory argument: inference prices are falling at roughly 10x per year or faster, while AI's voracious appetite for memory is pushing VM and memory rental costs up 25–30% per year. The two curves are crossing — soon, the virtual machine running an agent will cost more than the agent's inference itself.

This is where the Cloudflare-style architecture earns its value. Traditional cloud (AWS, Heroku, etc.) layers Docker and an OS on top of every application, with each instance consuming significant resources. Cloudflare Workers runs code in V8 isolates, sharing a single event loop and scheduler — code sitting idle consumes virtually no CPU. The enormous investment Google has poured into V8 has become an unexpected gift to the whole ecosystem: a Chrome tab is far lighter than a Docker Postgres instance. TS Rust is the missing piece that makes it possible to move the complete development experience into these cheap isolate environments.

A V8 isolate is a core concept from V8, the JavaScript engine underlying Chrome and Node.js. Each isolate is a fully independent JavaScript execution environment with its own heap and garbage collector — they cannot share memory directly. Cloudflare Workers and Deno Deploy exploit this to run thousands of tenants' code simultaneously within a single process. Traditional Docker requires a separate OS process — or even a full VM — per tenant, at orders-of-magnitude greater overhead. A cold-starting V8 isolate typically takes a few milliseconds and a few MB of memory, while a minimal Docker container startup often needs hundreds of milliseconds and tens of MB of additional overhead. This density difference is the technical foundation for the author's claim that "VM costs will exceed inference costs" — when every AI agent task needs an isolated execution environment, the fixed overhead of containerization becomes unsustainable, while the marginal cost of an isolate approaches zero.

What This Means for Software Engineering

The author's stance carries obvious "AI maximalist" energy, but his core argument deserves serious consideration: projects like this shouldn't have been possible. They shouldn't have passed tests. They definitely shouldn't have become viable drop-in replacements. And yet this one did.

He's particularly clear that his real contribution wasn't writing "high-IQ prompts" — it was setting up the environment: configuring parallel workflows, orchestrating multiple machines over SSH, continuously auditing bottlenecks and failure modes, keeping multiple agents working in parallel without interfering with each other. He compares his role to a manager: not writing code, but making sure the team has everything it needs to work effectively. That's probably one of the most grounded descriptions of what an engineer's role looks like in the AI era.

A word of caution: this piece is fundamentally the author's own account. Numbers like $420K and 12.5x speedup are personal estimates without third-party verification, and readers should maintain appropriate skepticism. But even heavily discounted, the basic fact — that AI ported a compiler long considered impossible in two weeks — says something real about how fast capability is advancing.

The author's closing reflection is telling: in the past, crazy ideas like this would only live in his head, or get pitched to smarter people with a hope that someone might build them five years later. Now he just tells Opus to go do it, and watches whether it can. The shape of engineering is being redefined, and the pace of that change makes it genuinely hard to imagine where things will be a year from now.