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.<p>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.<p>Congrats to the tsrs team on making this official. We're excited and we look forward to continuing on collaboration!
At this point, why invest further in TSGO?<p>No matter how many optimizations can be ported from tsrs to ts-go, Rust will be more efficient and enable the WASM use case.<p>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>That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.</i><p>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 answer is within the comment you wrote. AI is maintaining tsrs whereas humans are maintaining tsgo.<p>Your question boils down to "why would humans maintain something?" which could have a variety of answers depending on context.
Been with TS for many years now and the work your team's done over the years is amazing. Thank you
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.
Thanks for the input, glad to hear both parties benefit.<p>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?
It appears they're using a unique memory model (<a href="https://github.com/oxc-project/tsrs/blob/main/docs/PORTING.md#memory-model-the-important-part" rel="nofollow">https://github.com/oxc-project/tsrs/blob/main/docs/PORTING.m...</a>) 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.<p>Essentially, they fake a GC via never-freed arenas for long-living objects. It's interesting that Rust can do that (hopefully soundly)!
From the file:<p>>Create with P::new(value). p.get() returns &'static T. [...] unless an explicit recycling site proves them dead<p>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).<p>I'm guessing a sycophantic LLM either found or praised this load-bearing seam.
Ah took me a while to understand the reason behind this.<p>It wasn’t “let’s build a faster Rust based Typescript compiler” at all. That was a nice side-effect.<p>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.<p>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:<p>> However, frontier AI models can now do large-scale ports almost independently in a matter of days<p>> I wrote zero code. Not "barely any". Zero<p>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.<p>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.<p>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.
That's fair, I was thinking the same – porting must be simpler, especially if there's already a substantial test suite
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.<p>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.<p>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.
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.
According to voidzero, this port is up to 8x faster than TS 7.0 & ~70% less memory.<p>Microsoft should seriously consider porting typescript to rust at this point
Up to 8x faster seems kinda of a crazy claim. 8x faster at what?! TS 7.0 is reasonably well optimized and compiles VSCode in well under 10 seconds..<p>This can type check and compile VSCode in less than a second?
For VSCode: 4x speedup vs TS 7, 3x vs TS 7.1
Yes, it's in the article.
Well, no, not exactly. The article says vscode is compiled in 5.28s in typescript 7.1 (nightly), and in 1.73s in tsrs (dev), which is 3x faster.
I'm pretty sure they already considered it before settling on Go. Allegedly, they chose Go because it was easier to translate to.
I wonder how more frustrating is it to work on the compiler in rust vs go.<p>IIRC at the time of the port to go they wanted fast test and compile time, of course it's a different era now.
Idk. Apart from the fact that benchmarks are generally of questionable value, what's the point? Is the TS compiler unbearably slow?
They say the point in the article - WASM
The success of "modern" CLI tools written in Rust (uv, oxlint, turbopack) show there's a clear demand for faster tools in general.<p>Also, faster feedback loop is crucial for AIs, so I guess this makes sense.
What they show is that JavaScript should never have left the browser into the backend.<p>Don't rewrite into Rust, Go, Java, .NET, Zig, Odin, whatever.<p>Start with them directly.
Faster feedback loops almost always deliver improvements elsewhere.
[flagged]
[dead]
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).<p><a href="https://github.com/stepwisehq/typescript-dotnet" rel="nofollow">https://github.com/stepwisehq/typescript-dotnet</a>
So that's three now. This, tsgo-rs, and `bun check`
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 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 <i>cut operating expenses</i> by keeping just Anders Hejlsberg in a hammock reciting invariants to claudpilot.
Y'all building the same thing.
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.<p>You almost definitely don't need to immediately plan to switch.
please support TSRX (<a href="https://github.com/tsrx-org/tsrx" rel="nofollow">https://github.com/tsrx-org/tsrx</a>)
These days the trend seems to be rewriting everything in Rust.
I thought its TS port of theo
Theo's port is tsc-rs[0] as reference, and is significantly slower and uses more memory than this new version.<p>[0] <a href="https://github.com/pingdotgg/ts-rust" rel="nofollow">https://github.com/pingdotgg/ts-rust</a>
A new one but they're merging it with Theo's.
[dead]
Oh god, I wish this Rust fetishism would end soon.