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)!
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.
What strange times. A few years ago seeing a headline like this, my jaw would have literally dropped. Instead I'm wondering what kind of software projects will have meaning in the future if this headline feels common.
Or we can just drop TypeScript completely and type-check JavaScript directly.
With HM-style type inference, row-polymorphism, sum types, type classes for overloading + operations, recursive types for object methods, and type annotations for edge cases.
I've been working on this since before TypeScript existed. Latest incarnation: https://github.com/sinelaw/inty
Demo: https://sinelaw.github.io/inty/ (you may need to reload once)
According to voidzero, this port is up to 8x faster than TS 7.0 & ~70% less memory.
Microsoft should seriously consider porting typescript to rust at this point
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).
I wonder if something similar has been attempted with Python. CPython is a project where I don't know how they are taking advantage of AI.
I guess it will be soon that typescript won’t matter anymore since agents will be writing code is Rust compiled to WASM or similar for everything. typescript added human readability or JavaScript, if no human is coding, I don’t see the point of wasting tokens on this.
I ran out of patience before models got good enough to get this done.
Congrats to the team on getting this out
All of this just for enabling the WASM use case? Why not keep supporting Deno then that is written in Rust? To me it just sounds like a technical ai journey and a blow to the go port
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.
Y'all building the same thing.
Apparently only supported under darwin and linux for arm64 and x64? At least via npm.
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.
It's a nit, but do you guys need to embed the TS version in semver? https://www.npmjs.com/package/tsrs?activeTab=versions
I wonder how fast "Doom in TypeScript" runs in tsrs now. XD
I think we'll see TypeScript ported to minecraft ported to rust ported to typescript before GTA6.
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 is insane! saw a quote tweet of this by an infra engineer at chat gpt who said “ I'm looking at migrating over for the ChatGPT codebase and saw ~70% improvements on both wall time perf + peak cpu/memory usage.
this is great for getting work done faster but also much better if you want to run concurrent agents/worktrees at scale”. https://x.com/feedthejim/status/2112584843368570921?s=46
then i went and tried this on my own open source harness. type checking went from 10 seconds to under half a second and uses a quarter of the memory. madness
These days the trend seems to be rewriting everything in Rust.
[dead]
[dead]
[dead]
so rust is now go-to slop language? can't you guys use C or something. I want rust back.
Oh god, I wish this Rust fetishism would end soon.
please support TSRX (https://github.com/tsrx-org/tsrx)
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!