DanRosenwasser5 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!
samuelstros5 hours ago
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.
magicalist4 hours ago
> 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.
collabsan hour ago
I would love this to be typescript 8 and 8.1 story (:
[deleted]4 hours agocollapsed
platinumrad3 hours ago
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.
written-beyondan hour ago
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.
cute_boian hour ago
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.
wavemode4 hours ago
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.
[deleted]4 hours agocollapsed
greenavocado4 hours ago
No, the question is now: "How much human mental momentum, ego, and investment is there in and behind any particular project or its forks?"
stephbook3 hours ago
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.
Rapzidan hour ago
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.
greenavocadoan hour ago
> 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.
melodyogonna2 hours ago
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.
fallingbananna3 hours ago
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.
[deleted]2 hours agocollapsed
skybrian22 minutes ago
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?
pier253 hours ago
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.
theappsecguy3 hours ago
Fast is one thing, TSGO is fast enough I think, but my god does it suck up memory
alain_gilbert3 hours ago
I'm always mind-blown when I read stuff like "speed is overkill". Speechless!
pier253 hours ago
do you go to the supermarket with an F1 car?
AnnikaL7 minutes ago
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)?
wiseowisean hour ago
No, but I sure wouldn’t mind if I opened my fridge and the food was already there.
suriyaG2 hours ago
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 ?
sophacles31 minutes ago
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.
alain_gilbert3 hours ago
Do you usually dig up your garden by hand with a shovel, or do you use a rototiller?
pier253 hours ago
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.
eyelidlessness2 hours ago
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).
seanw4443 hours ago
Do you dig your garden with an excavator?
wiseowisean hour ago
Why are bringing Java into this?
Tadpole91812 hours ago
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.
afiori2 hours ago
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
Tadpole9181an hour ago
And that's a fine argument to make! But this stupid garden analogy is nonsense.
[deleted]2 hours agocollapsed
egonschiele5 hours ago
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.
lemagedurage5 hours ago
Thanks for the input, glad to hear both parties benefit.
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?
DanRosenwasser4 hours ago
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.
zyf4 hours ago
Been with TS for many years now and the work your team's done over the years is amazing. Thank you
satvikpendem3 hours ago
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.
_sinelaw_10 minutes ago
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)
afdbcreid5 hours ago
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)!
zamalek4 hours ago
From the file:
>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... ).
tengbretson3 hours ago
> 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"
afdbcreid4 hours ago
With sanitizers (https://github.com/oxc-project/tsrs/blob/main/notes/mem-recy...). We're back to C I guess. I hate this project now.
lioeters3 hours ago
> load-bearing seam
Zing!
jcmontx4 hours ago
Wouldn't that eat the whole ram?
panzi3 hours ago
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.
sheepscreek5 hours ago
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.
nitsky5 hours ago
Another reason: type aware listing in oxlint.
anamexis5 hours ago
Oxlint already has type-aware linting, integrated with TS7/typescript-go.
nitsky27 minutes ago
Yeah but now it can just all be in rust, which is a lot simpler.
egonschiele5 hours ago
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.
TheSamFischer5 hours ago
> 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.
FuckButtons5 hours ago
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.
TheSamFischer4 hours ago
It’s not a goal post. It was literally a fucking benchmark of the very first LLMs.
pas24 minutes ago
sorry, can please explain this? which benchmark are you referring to?
egonschiele5 hours ago
That's fair, I was thinking the same – porting must be simpler, especially if there's already a substantial test suite
onlyrealcuzzo5 hours ago
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.
egonschiele5 hours ago
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.
filopedraz2 hours ago
[flagged]
spiderice3 hours ago
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.
mohsen125 minutes ago
I ran out of patience before models got good enough to get this done.
Congrats to the team on getting this out
AbuAssar6 hours ago
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
aleksandrm5 hours ago
I'm pretty sure they already considered it before settling on Go. Allegedly, they chose Go because it was easier to translate to.
satvikpendem4 hours ago
That was pre-AI. Ironically if they waited just another year they could've done this port directly to Rust themselves.
ndr6 hours ago
I wonder how more frustrating is it to work on the compiler in rust vs go.
IIRC at the time of the port to go they wanted fast test and compile time, of course it's a different era now.
[deleted]4 hours agocollapsed
lemagedurage4 hours ago
That's interesting. A go version to iterate on the code and a rust version to run the code might be an optimal split here.
tgv6 hours ago
Idk. Apart from the fact that benchmarks are generally of questionable value, what's the point? Is the TS compiler unbearably slow?
ruther4d6 hours ago
They say the point in the article - WASM
msdz6 hours ago
(Not sure if this could be a genuine remark or is more of a joke, but)
Why not vibecode a Go -> WASM cross-compiler, then?
AbuAssar5 hours ago
Go needs a garbage collector while rust doesn’t.
Lvl999Noob5 hours ago
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.
[deleted]4 hours agocollapsed
zamalek5 hours ago
Apparently there were some design issues (raised and ignored) that made it unusable for many languages.
kg2 hours ago
Ignored is a little unfair to the Wasm committee, the Wasm GC is constrained by what is possible to ship in existing Wasm runtimes and the stuff needed by many languages is way beyond what those existing runtimes have available to them.
I think it made sense for them to compromise, at least on the initial version of Wasm GC, to get it out the door. I say this as someone who wants the features that got left out, like interior references :)
Tadpole91815 hours ago
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.
[deleted]4 hours agocollapsed
msdz5 hours ago
Yes, of course, but couldn’t you have/make one in WASM too? (I have no clue how memory is allocated there)
jerf5 hours ago
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).
ZiiS5 hours ago
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).
Tadpole91815 hours ago
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.
tgv5 hours ago
For workers, you only need to strip the types. There's no need to do the expensive checking.
Tadpole91815 hours ago
Did you read TFA?
> 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.
TheMrZZ6 hours ago
The success of "modern" CLI tools written in Rust (uv, oxlint, turbopack) show there's a clear demand for faster tools in general.
Also, faster feedback loop is crucial for AIs, so I guess this makes sense.
pjmlp6 hours ago
What they show is that JavaScript should never have left the browser into the backend.
Don't rewrite into Rust, Go, Java, .NET, Zig, Odin, whatever.
Start with them directly.
pier253 hours ago
> Is the TS compiler unbearably slow?
It's not. Even the JS compiler is still fast enough for many projects given the single core improvements in hardware (eg Apple Silicon).
eterm6 hours ago
Faster feedback loops almost always deliver improvements elsewhere.
mohammedalfarra6 hours ago
[flagged]
kidby6 hours ago
[dead]
Rapzid5 hours ago
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..
This can type check and compile VSCode in less than a second?
lemagedurage4 hours ago
For VSCode: 4x speedup vs TS 7, 3x vs TS 7.1
rs_rs_rs_rs_rs5 hours ago
Yes, it's in the article.
magicalist5 hours ago
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.
Rapzid4 hours ago
3x isn't so wild but still very impressive.
jrop2 hours ago
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.
gzapp5 hours ago
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).
Leynos6 hours ago
So that's three now. This, tsgo-rs, and `bun check`
alexanderson5 hours ago
They mention in the post they are working with Theo to absorb tsgo-rs into tsrs.
Rapzid5 hours ago
Why would they bother merging his vibe slop if theirs is better?
preommran hour ago
so this is software now?
youtuber vibe codes a transpiler says they're not going to bother maintaining it - but big company like cloudflare takes it seriously enough to absorbe into their own official services.
What is happening?
What is even software dev anymore?
What didnt the labs or cloudflare do this themselves, I mean they did, but then if it's all vibe coded, why do they need someone else's vibe coded stuff?
How is any of this serious?
shimman5 hours ago
Big tech looks out after their own. That's all there is to it.
Rapzid4 hours ago
Prob a PR thing with a quick merge to /dev/null
Leynos5 hours ago
Nice. I missed that. This is good news.
sashank_1509an hour ago
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.
hollowturtlean hour ago
> typescript added human readability
Ehm no, added type safety, and dealing with a type checker it's exactly what agents need.
> if no human is coding
Nope outside the bubble there are many still hand coding(me too)
> I guess it will be soon that typescript won’t matter anymore since agents will be writing code is Rust
Oh hold on a second isn't Rust the same as Typescript "adding human readability"?! Why not trashing Rust and just have LLMs output WASM directly? XD Wasm which is basically useless outside the browser or some microvms on the edge, and in the browser you don't even have an interface for directly rendering anything and still have to deal with the dom
You either are highly non technical, very junior or I just don't know
hollowturtlean hour ago
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
brazukadevan hour ago
I think it is a response to tsc-ts and scriptc from Vercel. CloudFlare and vercel CEOs have a personal competition going on.
ComputerGuruan hour ago
Apparently only supported under darwin and linux for arm64 and x64? At least via npm.
norman7845 hours ago
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.
egeozcanan hour ago
I think we'll see TypeScript ported to minecraft ported to rust ported to typescript before GTA6.
wannabe445 hours ago
Y'all building the same thing.
jscheel4 hours ago
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.
[deleted]3 hours agocollapsed
[deleted]6 hours agocollapsed
panzi3 hours ago
I wonder how fast "Doom in TypeScript" runs in tsrs now. XD
frangonf5 hours ago
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.
nsm5 hours ago
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.
[deleted]4 hours agocollapsed
cryptonym5 hours ago
> 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
sinameraji2 hours ago
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
tonyhart76 hours ago
I thought its TS port of theo
AntonyGarand6 hours ago
Theo's port is tsc-rs[0] as reference, and is significantly slower and uses more memory than this new version.
francislavoie6 hours ago
A new one but they're merging it with Theo's.
jdw645 hours ago
These days the trend seems to be rewriting everything in Rust.
zeroq5 hours ago
I'm staying stainless
satvikpendem4 hours ago
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.
jdw645 hours ago
Did you know? Even stainless steel RUSTs in sea wind.
g0ld3nrati03 hours ago
so rust is now go-to slop language? can't you guys use C or something. I want rust back.
cpursley2 hours ago
What? You realize how many people now are excited about Rust that were not before? I am, for one.
btucker2 hours ago
[dead]
tonetheman19 minutes ago
[dead]
souvlakee5 hours ago
[dead]
nalekberov5 hours ago
Oh god, I wish this Rust fetishism would end soon.
retropragma6 hours ago
please support TSRX (https://github.com/tsrx-org/tsrx)