Cloudflare says its Rust TypeScript port is 8x faster. I measured 5.3x — and 72% less memory.

Cloudflare announced tsrs today: a Rust port of the TypeScript compiler, built with VoidZero and the original tsc-rs author, incubated under Oxc, and developed "in close collaboration with the TypeScript team." The headline numbers are specific, which is an invitation: up to 8x faster and ~70% less memory than TypeScript 7.0, at the same number of type-check workers.

An experimental release is on npm, so the claim is checkable the way all compiler claims should be checked — by installing both and timing them. I did. The short version: the memory claim landed almost exactly, the speed claim is real but "up to" is doing some work, the diagnostics matched perfectly, the emitted JS was byte-identical — and the exit code wasn't.

The setup

npm install tsrs typescript
tsrs        0.18.0-ts7.1.0-dev.20260929
            reports: Version 7.1.0-dev.20260930.4 (microsoft/TypeScript@b85298b)
typescript  7.0.2   (the "TypeScript 7.0" baseline from the claim)
machine     2 vCPU Linux VM, Node v24.20.0

One fairness note, because Cloudflare is honest about it in the post and you should be too when quoting me: tsrs tracks TypeScript 7.1 dev, and the post itself says TypeScript 7.1 beta is already up to 2.5x faster than 7.0, partly from optimizations upstreamed from tsrs. So this is not a clean "Rust vs Go, same compiler version" race. It's the race a user actually gets today: the two packages you can npm install right now, run with defaults on the same project. That's the comparison that decides whether you switch.

The corpus is synthetic but not trivial: 400 TypeScript files, 35,199 lines, generated deterministically — a chain of modules, each defining a generic interface, 28 generic functions doing Map construction over typed arrays, and Pick/& type aliases, all under strict: true with skipLibCheck. Both compilers ran tsc --noEmit / tsrs --noEmit, three runs each, timed externally with peak RSS from wait4 rusage (the compiler's own peak, not the npm shim's).

The numbers

clean project, 400 files / 35,199 lines, --noEmit, defaults
              run 1     run 2     run 3     median    peak RSS
tsc 7.0.2     3.400s    2.508s    1.936s    2.508s    ~392 MB
tsrs 0.18.0   0.581s    0.474s    0.385s    0.474s    ~110 MB

Median-to-median that's 5.3x faster; best-to-best it's 5.0x; first (cold) runs give 5.9x. I couldn't coax out 8x on this box and corpus — but this is a 2-vCPU VM and a mid-size synthetic project, not Cloudflare's benchmark suite, and their wording is "up to." What I can say is that a 5x type-check speedup is not a rounding error or a cherry-picked microbenchmark. It's the difference between a check you run on save and a check you run on commit.

Memory is where it gets almost boring: ~110 MB vs ~392 MB peak is 72% less, against a claim of "~70% less." Reproduced, nearly to the digit. On a laptop that number is trivia; in the environments Cloudflare cares about — Wasm sandboxes, browser-hosted toolchains, Workers — it's the whole argument, and their post makes it explicitly: a Go binary compiled to Wasm carries its garbage collector with it, a Rust one doesn't have one to carry.

Startup overhead, for the small-project case (a one-file project, 5 runs each):

tsc    0.825  0.860  0.552  0.525  0.514   (seconds)
tsrs   0.450  0.354  0.247  0.209  0.217

Even where there's almost nothing to compile, tsrs starts in roughly half the time. Both are dominated by process startup at this size; the ratio is the story, not the absolutes.

Does it agree with tsc?

Speed is worthless if the port quietly checks a slightly different language. I seeded the same project with four errors across two files — two bad assignments, a call to a nonexistent function, and a method call on a number:

tsc:  exit=1, 4 errors
tsrs: exit=2, 4 errors
  src/mod10.ts(89,14):  error TS2322: Type 'string' is not assignable to type 'number'.
  src/mod10.ts(90,14):  error TS2322: Type 'number' is not assignable to type 'string'.
  src/mod10.ts(91,1):   error TS2304: Cannot find name 'nonexistentFunction'.
  src/mod200.ts(89,42): error TS2339: Property 'toUpperCase' does not exist on type 'number'.

The four diagnostics are identical in file, line, column, code, and message — in this run even the order matched, though Cloudflare warns diagnostic order is a known current difference, so don't build tooling that depends on it. Then I compiled the clean project to JS with both: 400 output files each, and diff -rq found zero differences — byte-identical emit on this corpus.

The one real divergence I found is small and exactly the kind that breaks a CI script at 2 a.m.: on type errors, tsc exits 1 and tsrs exits 2. Any script doing if [ $? -eq 1 ] instead of -ne 0 will treat a failed tsrs check as success-shaped. It's an experimental release (the version string is a dev build, 0.18.0-ts7.1.0-dev), so this is a "file it and move on" difference, not a scandal — but it's the sort of detail the announcement's "compiles like tsc" framing glosses over, and now you know to grep for it.

Verdict

Reproduced, with one qualifier each:

• "~70% less memory" — yes: 72% less on my corpus.
• "Up to 8x faster" — I measured 5.3x median on a 2-vCPU VM with a 35k-line synthetic project, against a baseline (7.0.2) that tsrs's own upstream (7.1) is already much faster than. Treat 8x as a ceiling, 5x as plausible, and measure your own repo — the gap will move with project shape and core count.
• Faithful port — on everything I threw at it: identical diagnostics, identical emit. One exit-code difference to check in your scripts.

The more interesting claim in Cloudflare's post isn't a number at all: it's that frontier models now make ports like this feasible in days, so the maintenance strategy is an agent that reads upstream TypeScript diffs every morning and regenerates a compatibility matrix every night. If that process holds, tsrs stays faithful; if it slips, tsrs becomes a fork with good benchmarks. The 5.3x I measured is real today. Whether it's still the same language in a year is a process question, and for once the vendor said so themselves.

Sources: Cloudflare's announcement (published today, October 20; HN 329 points), the tsrs npm package (0.18.0-ts7.1.0-dev.20260929). All timings, memory figures, diagnostics, and emit comparisons above were measured locally today; the corpus generator and benchmark script are deterministic (seed 42).