Tsrs: A Port of TypeScript to Rust
blog.cloudflare.com256 points by hnisjafx40 7 hours ago
256 points by hnisjafx40 7 hours ago
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!
At this point, why invest further in TSGO?
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.
> 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.
Too late I just shipped tsvhdl so you have a hardware implementation of the actual TS compiler. Why steal valuable CPU cycles from agent workflows, off load all transpilation and type checking to a dedicated TSC chip.
I am okay if agents can write code that is very safe in ASM. I am sure code written in Rust are naturally safe compared to asm or c. Waiting for tsasm to be significantly faster and safer than tsrs.
Your answer is within the comment you wrote. AI is maintaining tsrs whereas humans are maintaining tsgo.
Your question boils down to "why would humans maintain something?" which could have a variety of answers depending on context.
No, the question is now: "How much human mental momentum, ego, and investment is there in and behind any particular project or its forks?"
I for one would be demotivated. Why maintain an official compiler that's not even half as fast as the vibe-coded one?
"Just" publish the language specs and be done.
These ports are borrowing large parts of the architecture, algorithms, and data structures from the official implementation.
I don't think a spec would facilitate them at such a low effort level and cost.
> Why maintain an official compiler that's not even half as fast as the vibe-coded one?
Because at the end of the day, someone has to actually care and put in effort, even if the thing is machine generated, because it can go off the rails.
I never understand why people say things like this. It is not uncommon for languages to have multiple implementations, everything must not be abandoned for Rust man.
Because TSGO is stable and compatible?
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.
Another advantage of AI, though, is that it becomes easier to maintain more than one TypeScript compiler. Perhaps there's some benefits to having some diversity?
TSGO is already plenty fast and overkill for most projects.
Sure the Rust version is faster but the difference is probably only noticeable in the top 1% largest projects.
Fast is one thing, TSGO is fast enough I think, but my god does it suck up memory
I'm always mind-blown when I read stuff like "speed is overkill". Speechless!
do you go to the supermarket with an F1 car?
If you are travelling a long distance, say over 1000 miles/km, do you always drive? Or do you take an airplane (or a train)?
No, but I sure wouldn’t mind if I opened my fridge and the food was already there.
the cost between an F1 car and a "regular" car is high, both financially and functionally.
but tsrs and tsgo are not a similar comparison. they cost the same (you download a binary and run it) and are functionally identical. in that case why would you not use the faster & better one?
the question should be, do you always want your groceries 50% faster ?
Bad comparrison. The less time my computer spends doing things the less battery I use.
An F1 car goes faster but also uses more fuel to do so.
Any one tool being a bit faster doesn't make my batter last noticeably longer, but defaulting to using the efficient tooling gets me results I can see.
Do you usually dig up your garden by hand with a shovel, or do you use a rototiller?
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.
I think it might have more meaningful impact on high volume use cases, i.e. where cumulative run time is still significant.
That’s already meaningful for at least a couple of companies I’ve seen investing in these ports. It might be niche for individual dev workflows now, but as those evolve it could become less niche (albeit probably still less uniform).
Do you dig your garden with an excavator?
I mean... If I had an excavator it beats using a shovel? This is such a silly "gotcha" analogy because the only reason I wouldn't is cost. And cost is not a reason for tsgo to be slower?
"Would you rather have worse software for literally no benefit?"
We should aim to make software as performant, bug free, feature-complete, and maintainable as is cost effective. It's asinine to argue that software shouldn't be fast, not because of some trade off, but just because someone doesn't need it to be fast for small tasks.
Which, mind you, isn't even the case here. Thousands of businesses use typescript for millions of lines of code. Performance gains can mean tens of thousands of dollars in compute or hardware or time; tons of carbon saved from being emitted.
Yep cost is the reason, allegedly the ts team found go a better language for a port and both using a less ergonomic language and switching target every six months have associated costs