Hey there, TypeScript team member here. The tsrs project has been extremely interesting to see come together. We've been working with the maintainers to better understand how tsrs is fast and what sorts of optimizations it uses are safe. We even did our own Rust vibe port and what we currently suspect is that a lot of the speed does not just come down to language choice, and some of what is going to make TS 7.1 faster and leaner (see the charts in the blog post) actually comes from optimizations discovered in tsrs.
We think the wasm and oxlint integration makes a lot of sense for Cloudflare's needs, so this investment makes sense. At the same time, we'll be working hard and collaborating to make the official TypeScript toolset faster and even more efficient.
Congrats to the tsrs team on making this official. We're excited and we look forward to continuing on collaboration!
No matter how many optimizations can be ported from tsrs to ts-go, Rust will be more efficient and enable the WASM use case.
The premise of porting the compiler from TS to GO was ease of migration due to Go's garbage collector. That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.
I assume that most of the speedup in ts-rs does not simply stem from using a language without garbage collection, but actually from doing smart optimizations that can be done in any langauge.
Similar to how uv in the Python world explained that their implementation being in Rust has very little to do with the most impactful speedups they did.
> That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.
Sure, but that only matters if migration is going to be the last thing anyone does on a project. Unless you think typescript 7.1 ought to be enough for anybody, it also matters what the typescript team wants to write/read/reason in.
I just vibecofed tsasm. tsrs is obsolete now and anyone who still uses it is hopelessly behind the times. The tsrs team should delete the repository immediately and join my project.
Now we're getting somewhere. This is a great example because obviously speed depends on the context.
Obviously a shovel is quite an improvement for home gardeners but big constructions need a completely different tool.
For +99% of TS projects going from eg 10ms to 1ms is not going to make any difference even though it's a 10x improvement. In part because most monitors refresh at 60hz (16ms per frame) but even with +120hz monitors this is not going to have an impact on any workflow. Even for CI network latency is going to be a much bigger factor than improving TS compilation beyond the performance that TSGO already provides.
Thanks for the response and it is encouraging to hear that there's more to this project than vibe coding! Sounds like some interesting things were found in the process, and I'm all for vibe coding as a way to learn new things.
Ah I was gonna ask what happened with tsc-rs by Theo but looks like you guys are merging it in, at least it won't be a waste of his $500k in token spend, lol.
If I recall correctly, a few of both - there were instances where some work could be done more lazily/minimally (https://github.com/microsoft/TypeScript/pull/64476), and there were instances where we changed our allocation patterns and played around with some struct layouts. We originally strived not to drastically reorganize our data structures to make things easier to port, and we have more flexibility now. We're continuing to experiment more here.
It appears they're using a unique memory model (https://github.com/oxc-project/tsrs/blob/main/docs/PORTING.m...) to overcome the challenge that prevented the TypeScript team from choosing Rust to begin with: Rust has no GC and porting from a GC language to it often requires restructure of data.
Essentially, they fake a GC via never-freed arenas for long-living objects. It's interesting that Rust can do that (hopefully soundly)!
>Create with P::new(value). p.get() returns &'static T. [...] unless an explicit recycling site proves them dead
It's unsound, the LLM/human is doing the proving. They've hidden unsafe in an abstraction without removing the unsafeness. Using the arena allocator's lifetime would have been safe and easy (bumpalo recommends this AFAIK).
I'm guessing a sycophantic LLM either found or praised this load-bearing seam.
Calling this a breakthrough in memory management is an understatement. Call up the Turing Award committee. We just discovered a solution to the halting problem! Turns out that for certain applications the answer is unequivocally "yes"
Compilers often just build up more and more data structures in memory until the end when they then release everything more or less at once. With an arena you can then just throw away the whole arena at the end, assuming there are no resource handles that need to be closed in drop().
A long time ago I read an article about someone speeding up a C++ compiler that is itself written in C++ (was it g++? maybe clang?). They simply patched out delete so it did nothing. The compiler used marginally more memory but ran much faster, since releasing all the small objects one by one is just useless work at the end of the compilation.
A GCed language has a similar behavior and could therefore be fast in that case. It just builds up all the objects and then when the program exists it doesn't have to GC them all, it just throws away the whole process memory. So I can imagine one could "optimize" a compiler written in a GCed language by deactivating the GC.
Ah took me a while to understand the reason behind this.
It wasn’t “let’s build a faster Rust based Typescript compiler” at all. That was a nice side-effect.
They needed a Typescript compiler that can run on their WASM only sandbox. So the only existing option was to export tsc Go to WASM, but that comes with the full Go runtime.
And to avoid that cost, they experimented with a Rust compiler and turns out it’s even faster than the reference tsc/Go implementation.
It's exciting to see the speed gains. I use TypeScript every day on a large codebase, and it is too slow to run locally.
I don't love this change though:
> However, frontier AI models can now do large-scale ports almost independently in a matter of days
> I wrote zero code. Not "barely any". Zero
So we are going to move from a carefully handwritten port to an entirely AI-generated port. I know this is the way the industry is headed, I use coding agents a ton. But I still review their output because they often don't make sound architectural decisions. Maybe this is a sign that my way of working is going away. I'm not sure how to justify that kind of time spent when someone can do the same thing in a matter of days with barely any effort.
I am working on my own language now, I've spent most of this year on it. The idea that someone could just replace it in a matter of days is wild. Wonder how the TS team at Microsoft feels about this.
> The idea that someone could just replace it in a matter of days is wild.
They didn’t design a language that millions of human engineers enjoy (?, lol) using. They took an existing codebase and ported it. Yes, the porting part is easier now but only because another project and spec exist.
While this is true - and I see the same sentiment as i am about to make ad nauseam - it is kind of amazing how far the goal posts have moved in such a short space of time.
If TypeScript has the integration testing framework in place to verify that the compiler actually works (and it should) - then, presumably, you should be able to swap in a Chinese Room black-box and - at least - know that it works.
You do have to be worried that it's possibly installing trojan horses on your computer while compiling code, or any other number of unwanted side effects.
But you can and should be able to have integration testing in place to know that a compiler - at a minimum - actually works.
Totally fair. The thing is, though, agents often write code in ways I don't expect, and I don't think any human would write, which makes me think that code may also break in a way that no human expects or would have written a test for.
Your way of working is definitely going away. And quickly. The idea of reviewing code today is already a questionable use of time. In a few more months to a year it will clearly be a waste of time.
Shameless plug of my Typescript C# port. It's a case study with some interesting (perhaps) notes from me in the README about approach, performance, and cost(~$75).
Wasm comes with a garbage collector though, no? So a garbage collected language that offloads all memory management to the runtime would actually be better than one that ignored the platform and does its own stuff.
The JVM alone has, what, 4 different modern GCs now? Garbage collectors aren't really universal, so they can pose different issues for different languages.
Yes, and when you ship a Go WASM package it is already included. But it has a certain impedence mismatch with WASM since it is rolling its own stuff that WASM can't see, I believe the performance is a bit less good than it could be, and it results in very large WASM packages for small amounts of code.
Since a typescript compiler isn't "a small amount of code", you'd have to see specific numbers on the final WASM assembly size to know how relevant that is. I'd expect well-written Rust code to beat well-written Go code on final assembly size by some amount, which may or may not be relevant to any particular use case (since in a lot of cases one "couple dozen megabytes" is much the same as another when it really gets down to it, it's not like Go is going to be emitting gigabytes to Rust's hundreds of kilobytes or something). However I can't judge what AI-written Rust code versus well-written Go code would come out as. AI is not terribly good at being concise (he said, while writing this post between prompts fighting with an AI to make a PR much more concise than it currently is).
You already can run the Go tsc in WASM using mature tools; but it further amplifies the memory and performance difference between the Rust version (which maps more cleanly onto WASM's design).
1. Porting typescript is made easier by the enormous test suite they can copy for verification.
2. They're doing this for workers, so with a systems-level language, there's a much higher potential for CPU and memory savings (an order of magnitude on this first pass, apparently). Driving their compute costs down is very revenue-efficient at this scale.
> Just a few weeks ago we announced supporting native Rust in Workers with the new Emscripten target for wasm-bindgen. When you run entire software build and deployment systems in tight loops on Workers, the benefits of a small memory footprint pay off quickly.
I'm tired of all the new tools that comes out every day, but I would say, this is basically the Vite team and if they implement it with Vite+, then I'm all for it, less decisions about tooling to be made, one config file, etc.
I benchmarked tsrs a few weeks ago. I was testing out tsgo, ts-rust, tsrs, and bun for typechecking on our monorepo. tsrs is definitely awesome, it is very memory efficient when bumping up the number of threads. Not as efficient as bun, but it has incremental checks, which bun does not have.
I use oxc tooling and it's great to see the rust rewrite singularity in action and get to ride the fastest horses, but I would like that they made a branch for 7.2 as experiment to see how it compares. Maybe this ends in a win for Microsoft, they could cut operating expenses by keeping just Anders Hejlsberg in a hammock reciting invariants to claudpilot.
Obligatory reminder that their needs from a TS compiler are extremely different from a regular web developers iteration cycle. They are trying to run millions of these while saving on costs.
You almost definitely don't need to immediately plan to switch.
> This enables new possibilities when combined with agents: You are now able to run a development toolchain end-to-end in a fully sandboxed environment on Cloudflare.
True. Looks like main use-case is AI Agent Sandboxing
You should say you're staying fungal infection free as it's named after the Rust fungus not the chemical reaction even if that's what people think these days.
We think the wasm and oxlint integration makes a lot of sense for Cloudflare's needs, so this investment makes sense. At the same time, we'll be working hard and collaborating to make the official TypeScript toolset faster and even more efficient.
Congrats to the tsrs team on making this official. We're excited and we look forward to continuing on collaboration!
No matter how many optimizations can be ported from tsrs to ts-go, Rust will be more efficient and enable the WASM use case.
The premise of porting the compiler from TS to GO was ease of migration due to Go's garbage collector. That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.
I assume that most of the speedup in ts-rs does not simply stem from using a language without garbage collection, but actually from doing smart optimizations that can be done in any langauge.
Similar to how uv in the Python world explained that their implementation being in Rust has very little to do with the most impactful speedups they did.
Sure, but that only matters if migration is going to be the last thing anyone does on a project. Unless you think typescript 7.1 ought to be enough for anybody, it also matters what the typescript team wants to write/read/reason in.
Your question boils down to "why would humans maintain something?" which could have a variety of answers depending on context.
"Just" publish the language specs and be done.
Sure the Rust version is faster but the difference is probably only noticeable in the top 1% largest projects.
Obviously a shovel is quite an improvement for home gardeners but big constructions need a completely different tool.
For +99% of TS projects going from eg 10ms to 1ms is not going to make any difference even though it's a 10x improvement. In part because most monitors refresh at 60hz (16ms per frame) but even with +120hz monitors this is not going to have an impact on any workflow. Even for CI network latency is going to be a much bigger factor than improving TS compilation beyond the performance that TSGO already provides.
Could you elaborate on what type of optimizations were added to TS 7.1? As in, were they more algorithmic or related to memory management?
Essentially, they fake a GC via never-freed arenas for long-living objects. It's interesting that Rust can do that (hopefully soundly)!
>Create with P::new(value). p.get() returns &'static T. [...] unless an explicit recycling site proves them dead
It's unsound, the LLM/human is doing the proving. They've hidden unsafe in an abstraction without removing the unsafeness. Using the arena allocator's lifetime would have been safe and easy (bumpalo recommends this AFAIK).
I'm guessing a sycophantic LLM either found or praised this load-bearing seam.
Never deallocating would have been sound (missile memory management: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98... ).
Calling this a breakthrough in memory management is an understatement. Call up the Turing Award committee. We just discovered a solution to the halting problem! Turns out that for certain applications the answer is unequivocally "yes"
Zing!
A long time ago I read an article about someone speeding up a C++ compiler that is itself written in C++ (was it g++? maybe clang?). They simply patched out delete so it did nothing. The compiler used marginally more memory but ran much faster, since releasing all the small objects one by one is just useless work at the end of the compilation.
A GCed language has a similar behavior and could therefore be fast in that case. It just builds up all the objects and then when the program exists it doesn't have to GC them all, it just throws away the whole process memory. So I can imagine one could "optimize" a compiler written in a GCed language by deactivating the GC.
It wasn’t “let’s build a faster Rust based Typescript compiler” at all. That was a nice side-effect.
They needed a Typescript compiler that can run on their WASM only sandbox. So the only existing option was to export tsc Go to WASM, but that comes with the full Go runtime.
And to avoid that cost, they experimented with a Rust compiler and turns out it’s even faster than the reference tsc/Go implementation.
> However, frontier AI models can now do large-scale ports almost independently in a matter of days
> I wrote zero code. Not "barely any". Zero
So we are going to move from a carefully handwritten port to an entirely AI-generated port. I know this is the way the industry is headed, I use coding agents a ton. But I still review their output because they often don't make sound architectural decisions. Maybe this is a sign that my way of working is going away. I'm not sure how to justify that kind of time spent when someone can do the same thing in a matter of days with barely any effort.
I am working on my own language now, I've spent most of this year on it. The idea that someone could just replace it in a matter of days is wild. Wonder how the TS team at Microsoft feels about this.
They didn’t design a language that millions of human engineers enjoy (?, lol) using. They took an existing codebase and ported it. Yes, the porting part is easier now but only because another project and spec exist.
You do have to be worried that it's possibly installing trojan horses on your computer while compiling code, or any other number of unwanted side effects.
But you can and should be able to have integration testing in place to know that a compiler - at a minimum - actually works.
https://github.com/stepwisehq/typescript-dotnet
Microsoft should seriously consider porting typescript to rust at this point
IIRC at the time of the port to go they wanted fast test and compile time, of course it's a different era now.
It's not. Even the JS compiler is still fast enough for many projects given the single core improvements in hardware (eg Apple Silicon).
Why not vibecode a Go -> WASM cross-compiler, then?
Since a typescript compiler isn't "a small amount of code", you'd have to see specific numbers on the final WASM assembly size to know how relevant that is. I'd expect well-written Rust code to beat well-written Go code on final assembly size by some amount, which may or may not be relevant to any particular use case (since in a lot of cases one "couple dozen megabytes" is much the same as another when it really gets down to it, it's not like Go is going to be emitting gigabytes to Rust's hundreds of kilobytes or something). However I can't judge what AI-written Rust code versus well-written Go code would come out as. AI is not terribly good at being concise (he said, while writing this post between prompts fighting with an AI to make a PR much more concise than it currently is).
2. They're doing this for workers, so with a systems-level language, there's a much higher potential for CPU and memory savings (an order of magnitude on this first pass, apparently). Driving their compute costs down is very revenue-efficient at this scale.
> Just a few weeks ago we announced supporting native Rust in Workers with the new Emscripten target for wasm-bindgen. When you run entire software build and deployment systems in tight loops on Workers, the benefits of a small memory footprint pay off quickly.
Also, faster feedback loop is crucial for AIs, so I guess this makes sense.
Don't rewrite into Rust, Go, Java, .NET, Zig, Odin, whatever.
Start with them directly.
This can type check and compile VSCode in less than a second?
You almost definitely don't need to immediately plan to switch.
True. Looks like main use-case is AI Agent Sandboxing
[0] https://github.com/pingdotgg/ts-rust