Rendered at 14:21:37 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
DanRosenwasser 23 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!
samuelstros 23 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.
magicalist 22 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.
collabs 19 hours ago [-]
I would love this to be typescript 8 and 8.1 story (:
22 hours ago [-]
platinumrad 21 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-beyond 19 hours 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.
simplesocieties 14 hours ago [-]
Too late I just shipped tsasic so you can have a custom-made board for every single application you will ever write.
fmbb 8 hours ago [-]
I already started manufacturing 100 shipping containers of left pad machines. Taking orders.
hdjdnxjzhzhs 12 hours ago [-]
Too late, I just shipped tsqntm, who needs silicon when you can use qubits to accelerate every state of every program all at once
z3t4 2 hours ago [-]
Too late, I just encoded a quantum spin oscillator crystal that can infer the types of all existing and future programs
huddo121 12 hours ago [-]
Egg upon all your faces! I have released tsoracle, which knows (by unknown means) whether your ts compiles correctly, instantly!
stymaar 7 hours ago [-]
Larry Ellison's hitmen are already on your tracks for trademark infringement.
Too 6 hours ago [-]
Can someone please instead spend their tokens on vibe coding an electron2rust.
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.
afdbcreid 14 hours ago [-]
I'm pretty sure a program written in asm by agents will not only be very unsafe, but also very slow compared to Rust, or even Go or Java.
awesome_dude 17 hours ago [-]
People massively overestimate Rust's "safety" - it has a very nice approach to managing data races, and. that's it.
It still, like every other language/tool we have that shares state between threads, has race conditions, for example.
RussianCow 14 hours ago [-]
Borrow checker aside, I would like to think that its type system inherently makes it safer than a language like C.
solyin 14 hours ago [-]
You can write bad unsafe code in any language. Rust has a convenient keyword for that. C++ has types.
afiori 8 hours ago [-]
unsafe rust is still typed orders of magnitude better than C
pjmlp 8 hours ago [-]
Even Modula-2 (1978) type system is safer than C.
vovavili 16 hours ago [-]
That is a confidently incorrect assertion.
Kamq 14 hours ago [-]
They said race conditions and specifically exempted data races. You can absolutely write race conditions in rust, they're a logic bug.
As an example, let's say you have two functions A and B. A only works properly if B has never ran for some reason. Let's say they both accept a reference to a value C, and B changes C's value somehow. Because this is rust, we can't have data races, so we wrap it in an ArcMutex or what have you. That doesn't impact the ordering of A and B at all.
If we spawn threads that execute A and B at the same time, it's up to the scheduler if A functions properly.
rrvsh 15 hours ago [-]
You are being downvoted but you are absolutely correct. I have never seen someone assert Rust is a 100% safe. Its touted purely as a _memory_ safe language. To claim otherwise is absurd and very telling of the writer's biases
dnautics 8 hours ago [-]
> I have never seen someone assert Rust is a 100% safe
Maybe I spend too much time on tech internet...
awesome_dude 14 hours ago [-]
> I have never seen someone assert Rust is a 100% safe
Please copy and paste from my post where that's being asserted
> Its touted purely as a _memory_ safe language
Which is different from what was said... how?
> To claim otherwise is absurd and very telling of the writer's biases
To pretend that those claims were made is what's actually telling of biases.
afdbcreid 14 hours ago [-]
> How can Codex write fast-to-compile Rust code, do tell?? Do tell!
Because memory safety isn't just about data races. In fact data races are far from Rust's most innovative or important feature. They are a side-effect, the designers had a nice system and saw it can also prevent data-races, so they said "sure, why not".
solyin 17 hours ago [-]
Did you? GitHub link? because that would be awesome! which asm target did you pick? I looked at using LLVMs' LVM because I didn't want to have to choose ARM or x86? What are some of the trade-offs you made along the way? Wait, are you making a joke and think you're funny? (Hate to be the bearer of bad news but you're not.)
wavemode 22 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.
pjmlp 3 hours ago [-]
There are plenty of CoPilot contributions on tsgo repo, forgotten which company Typescript development is sponsored by?
No, the question is now: "How much human mental momentum, ego, and investment is there in and behind any particular project or its forks?"
stephbook 21 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.
Rapzid 19 hours 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.
mrgoldenbrown 14 hours ago [-]
You need the experience of building and maintaining a compiler to make a great language spec. The tsrs team specifically said they don't want to be trying to change the spec.
greenavocado 19 hours 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.
lifeisloving 18 hours ago [-]
[flagged]
melodyogonna 21 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.
zarzavat 14 hours ago [-]
There are precisely two languages that make the most sense to implement the TypeScript compiler in: Rust and TypeScript itself.
A Rust implementation will have the fastest compilation speeds, memory safety, can easily be compiled to WASM, or compiled to a native node module.
A TypeScript implementation provides the most convenient way for TypeScript code to use the typescript package as a library. Pure JS, no native code or WASM dependencies. No FFI tax, can be jitted.
Go was always a compromise to make a port easier for humans. Go's GC makes it easier to keep the general code structure from the TS implementation. However that GC is also a liability, you sacrifice speed and embeddability.
Personally I'd prefer they went back to TypeScript for the reference implementation, and used Rust for the performance implementation. Go doesn't bring anything to the table anymore.
afdbcreid 14 hours ago [-]
> There are precisely two languages that make the most sense to implement the TypeScript compiler in: Rust and TypeScript itself.
Incorrect. I can maybe agree that those are the only perfect languages to implement tsc in them (if there is such thing). But in the real world, "perfect" does not actually mean "it's a good idea". Go made the most sense to port to (especially before agents), more than Rust (although C# could also be a good idea IMO).
ameliaquining 13 hours ago [-]
C#'s embeddability/interop story is even worse than Go's; IIUC this was the primary reason they chose not to use it.
WorldMaker 11 hours ago [-]
C#'s embeddability/interop story is as good or better than Golang's. The primary reason they chose not to use it was that C# was seen as too verbose compared to the TS original source. In particular TS used a lot of top level functions and bare/anonymous data types and while C# has picked up top level function support it's still not "idiomatic" and while C# has a long standing anonymous data type support it's not very "ergonomic", certainly not compared to TS structural typing. Golang's traits are a bit more ergonomic by comparison, unfortunately.
I also still think C# would have been a better long term option for maintainability, but I'm not on the Typescript team and didn't get a vote, and I can understand their methodology even if I don't agree with it.
fallingbananna 21 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.
20 hours ago [-]
throw567643u8 11 hours ago [-]
The reason Anders gave at the time was Rust effectively outlaws cyclic data structures, which was not fitting of their implementation.
jbellis 6 hours ago [-]
As someone maintaining a close to 3M life Rust codebase, the downsides are real, especially rustc speed. I contribute to the mbx cache project but it only helps so much. It's only a small exaggeration to say that I fantasize daily about pursuing to Go.
pier25 21 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.
theappsecguy 21 hours ago [-]
Fast is one thing, TSGO is fast enough I think, but my god does it suck up memory
norman784 7 hours ago [-]
tsrs also has an LSP, so will be interesting to see how much memory it consumes vs tsgo.
alain_gilbert 21 hours ago [-]
I'm always mind-blown when I read stuff like "speed is overkill". Speechless!
pier25 21 hours ago [-]
do you go to the supermarket with an F1 car?
tialaramex 18 hours ago [-]
I walk to the supermarket. I'm pretty sure an F1 car would be noticeably slower.
On foot I cross the little residential street where I live, walk to the corner, cross the busier road using a Zebra that was installed by thoughtful "pedestrian first" local government, then walk to the next corner where the main entrance to the supermarket is.
In the F1 car lets assume somebody already pre-warmed it and so it's ready to go (F1 cars do not "just work" like your family car because that's not required in the F1 rules) I walk to the car park and get in, I need to accelerate quite hard to get the slippery F1 car up the steep drive, but then brake hard to stop and have somebody else check both ways since an F1 car isn't equipped for this in a side street. Now I pull out, takes no time to reach that street where pedestrian me crossed but I can't use that route in a car, so, go through another residential area, turn onto an old main road, turn again, to a roundabout, go into the underground carpark of the supermarket. Once I've parked I'm about as close to the front door as if I were walking from the Zebra. Huh.
suriyaG 20 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 ?
wiseowise 19 hours ago [-]
No, but I sure wouldn’t mind if I opened my fridge and the food was already there.
riknos314 16 hours ago [-]
My car doesn't require a dedicated team of engineers to start and has a trunk to hold groceries :P
The question isn't really if the speed is bad, it's what tradeoffs you need to make to realize it. The F1 car has a very narrow operating condition and so can make tradeoffs that are completely unreasonable for vehicles that need to do other things.
From what cloudflare is claiming, Tsrs gives me more speed without tradeoffs I care about, so why not have the free speed?
baq 17 hours ago [-]
Oh boy that’s about the most off the mark car analogy I’ve ever seen and I’ve seen some
solyin 17 hours ago [-]
If I could afford one, I absolutely would! I'd add a tow hitch so it had some storage and get it all street legal and add blinkers.
AnnikaL 18 hours 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)?
17 hours ago [-]
sophacles 19 hours 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_gilbert 21 hours ago [-]
Do you usually dig up your garden by hand with a shovel, or do you use a rototiller?
pier25 21 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.
eyelidlessness 20 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).
pier25 15 hours ago [-]
> I think it might have more meaningful impact on high volume use cases, i.e. where cumulative run time is still significant
For sure but those high volume use cases are extremely rare.
com2kid 8 hours ago [-]
By hand. I've been gardening for years now and I only have a loose idea what a rototiller is.
But in any given year I maybe plant a dozen new plants tops. 6 tomato plants and half a dozen other random things.
seanw444 21 hours ago [-]
Do you dig your garden with an excavator?
wiseowise 19 hours ago [-]
Why are bringing Java into this?
Tadpole9181 20 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.
afiori 20 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
Tadpole9181 19 hours ago [-]
And that's a fine argument to make! But this stupid garden analogy is nonsense.
afiori 7 hours ago [-]
no, it is the same idea, even if the excavator was magically free there are associated costs like keeping an industrial machine in your garden, danger or heavy machinery and possibly it is going to destroy you garden.
the analogy is not between each specific consequence/cost, it is relative to "single axis optimization" not being a solid strategy
20 hours ago [-]
skybrian 18 hours 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?
madeofpalk 16 hours ago [-]
If an AI agent could vibe-optimise tsgo, why port it all again over to rust?
samuelstros 16 hours ago [-]
because Rust will be faster and can compile to WASM which the TS ecosystem needs
lifeisloving 18 hours ago [-]
Please you port it if its so easy, the tests are available on gh. I wont be using an llm ported ts compiler anyways, and neither would many others
Its a great way to divide and kill the popularity of your project. I made sure bun is no longer used in my devices or projects that depend on it for example, I'm not alone in this.
egonschiele 23 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.
lifeisloving 18 hours ago [-]
Im not because nobody actually ever learns anything. For every one person that learns something the other 99% of the population gets lazier and dumber, ponder how that might play itself out.
This is probably the most harmful tech ever created simply because how many people trick themselves into thinking they're smarter while actually becoming much dumber. We're actually cooked.
lemagedurage 23 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?
DanRosenwasser 22 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.
zyf 22 hours ago [-]
Been with TS for many years now and the work your team's done over the years is amazing. Thank you
zylepe 16 hours ago [-]
+1 from what I’ve seen, porting apples to apples to rust only impacts performance by a few % (sometimes in the wrong direction). The main speed up comes from algorithmic improvements that can also be applied to the original project.
satvikpendem 22 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.
afdbcreid 23 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)!
dabinat 7 hours ago [-]
This is what bothers me about all the vibe-coded Rust ports. The LLMs are mostly porting the existing architecture and code as-is, which was intended for a different language with different features and tradeoffs. A port that actually uses Rust’s features and is architected in a way that makes sense for Rust code would be a lot better, more maintainable (if that matters anymore) and probably faster too.
Another advantage human ports have is the opportunity to reconsider earlier architectural decisions and change them, instead of just enshrining them in the new language.
wewxjfq 6 hours ago [-]
I never see this caveat mentioned in all the "... vibe-ported to Rust" threads, which makes me wonder who comments on these projects. I hand-ported a few TS hobby projects to Rust+WASM pre-AI and realized there are only two ways to go: Do a low effort translation and create very unidiomatic Rust code or redesign the application from the ground up. There's no middle ground. Option 1 is almost a waste of time and option 2 is incredibly difficult.
rk06 3 hours ago [-]
option 2 is also impractical for most part. doing a rewrite is big thing already, changing implementation paradigm would make "catching up" impossible.
Only practical option is to do low level rewrite (otpion 1) and then rewrite module by module into better approaches.
zamalek 23 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.
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"
solyin 17 hours ago [-]
We've have found an engineering solution to some of the cases for the halting problem, yes. It's still not solved science problem though. Science isn't engineering though.
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.
jamesfinlayson 13 hours ago [-]
I read on here a few months ago about some high-frequency trading system being written in Java and running with no garbage collector enabled, because the application is closed at the end of trading each day and it's extremely fast without garbage collection.
sheepscreek 23 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.
nitsky 23 hours ago [-]
Another reason: type aware listing in oxlint.
anamexis 23 hours ago [-]
Oxlint already has type-aware linting, integrated with TS7/typescript-go.
nitsky 18 hours ago [-]
Yeah but now it can just all be in rust, which is a lot simpler.
simplesocieties 14 hours ago [-]
> It wasn’t “let’s build a faster Rust based Typescript compiler” at all. That was a nice side-effect.
Then why are the performance graphs the headliner topic in the article? The WASM sandbox is barely a footnote.
sheepscreek 13 hours ago [-]
> Then why are the performance graphs the headliner topic in the article?
If you’ve got it, flaunt it?
> The WASM sandbox is barely a footnote.
This one is a real head scratcher. The sandbox was clearly what set them on this path.
Maybe they believe the performance gains are worthy of being discussed by themselves?
xboxnolifes 8 hours ago [-]
What objective things can you mention about the WASM sandbox besides saying "it works"? People prefer seeing good benchmarks.
sara_kumodeck 10 hours ago [-]
that makes sense, shinpping the whole go runtime into a WASM sandobox would have been a feavy price just to compile TypeScript
egonschiele 23 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.
TheSamFischer 23 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.
FuckButtons 23 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.
TheSamFischer 22 hours ago [-]
It’s not a goal post. It was literally a fucking benchmark of the very first LLMs.
pas 18 hours ago [-]
sorry, can please explain this? which benchmark are you referring to?
egonschiele 23 hours ago [-]
That's fair, I was thinking the same – porting must be simpler, especially if there's already a substantial test suite
onlyrealcuzzo 23 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.
egonschiele 23 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.
filopedraz 20 hours ago [-]
[flagged]
spiderice 21 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.
0x696C6961 15 hours ago [-]
The only group of people saying this are those who didn't have much technical ability to begin with.
lioeters 14 hours ago [-]
Found the meat proxy. Your kind will be the first to be replaced. Useless without the machine doing the actual work of thinking.
vips7L 11 hours ago [-]
You’re a waste of time.
jrop 20 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.
gzapp 23 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).
I'm going to do a taboo and comment on my own comment.
I didn't push performance in a way that would cause big deviations from the Golang project's algorithms and data structures; similar to how the TS team didn't want to deviate too far from the JavaScript source till now. Aggressive unmanaged arenas and object pooling was the direction I would have pursued..
The GC in DotNet is a source of major frustration for a tool like this. Without tuning lots of gen 0/1 work occurs to determine if objects should be promoted. The tuning is still not an ideal solution IMHO. Fully unmanaged arenas and aggressive object pooling could help here, but an alternative GC may be part of an ideal, comprehensive solution.. I have have a play with ZeroGC.
There is a warning on the repo that it's not maintained, but I've been curious about the process of updating it to sync "upstream" changes. And it sounds like the TypeScript team are going to start incorporating some of the performance techniques identified in the Rust port in the 7.1 release so... I'll probably at least sync it to up to 7.1 and keep it as an active experiment and case study on LLM porting and DotNet AOT performance.
It's just good fun.
WorldMaker 11 hours ago [-]
It sounds like the big 7.1 performance trick will be unmanaged arenas, so yeah maybe something your LLM agent picks up for "cheap".
gzapp 10 hours ago [-]
Yeah, that definitely seems like the case.
The benefit of those enhancements being wrapped into the reference implementation is it's "easier" for humans and LLMs to reconcile and keep things in sync.
simplesocieties 14 hours ago [-]
AI isn't improving productivity if EVERYONE is trying to reinvent the same f*king thing. What are we doing here? Why publish any open source software at all if someone is gonna swoop in and vibe something better™ faster™ and more memory efficient™ the next day?
oersted 12 hours ago [-]
Just like science, open-source is a collective effort to build increasingly better solutions to the problems we have. We cannot ignore individual benefits in contributing, but that is not everything. It’s about collaborating/competing to build better things, standing on each other’s shoulders.
simplesocieties 12 hours ago [-]
Just to put everything in perspective, I recognize fully that Cloudflare had a use case for tsrs with WASM sandboxing. I am addressing your larger point about this sort of thing becoming the norm.
> We cannot ignore individual benefits in contributing, but that is not everything.
Individual benefits are the very foundation of most collaborative efforts. Pharmaceutical companies get payouts via patents for researching life-saving medicine. Even with money taken out of the equation, many academics slave for years over their research in hope of recognition either via Tenure or Nobel Prize. Ignoring the fact that people want credit for their work is dangerous and irresponsible.
Forking projects that are near-complete or have already undergone major refactors just to snipe them last-minute with vibe coded efforts is going to kill collaboration. I'm never building another project in the open again because that is precisely what I'm aiming to avoid.
vips7L 10 hours ago [-]
Faster ™ doesn’t matter
AbuAssar 1 days 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
aleksandrm 23 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.
satvikpendem 22 hours ago [-]
That was pre-AI. Ironically if they waited just another year they could've done this port directly to Rust themselves.
nish__ 18 hours ago [-]
Not really because this port is based on the Go version. I doubt it would be as easy for an LLM to port the TS 6 codebase.
rk06 3 hours ago [-]
after 7.0, tsgo version is The canonical version. so, there is no other choice here
satvikpendem 11 hours ago [-]
The Go version was a line by line port of the TypeScript version.
ndr 24 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.
lemagedurage 22 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.
22 hours ago [-]
tgv 24 hours ago [-]
Idk. Apart from the fact that benchmarks are generally of questionable value, what's the point? Is the TS compiler unbearably slow?
ruther4d 24 hours ago [-]
They say the point in the article - WASM
msdz 24 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?
AbuAssar 23 hours ago [-]
Go needs a garbage collector while rust doesn’t.
Lvl999Noob 23 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.
WorldMaker 11 hours ago [-]
Wasm GC is not an object-level GC yet. It's still a very low level bit buffer GC. It's closer to the memory page management of an operating system than anything like JS's own GC.
zamalek 23 hours ago [-]
Apparently there were some design issues (raised and ignored) that made it unusable for many languages.
kg 20 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 :)
22 hours ago [-]
Tadpole9181 23 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.
22 hours ago [-]
msdz 23 hours ago [-]
Yes, of course, but couldn’t you have/make one in WASM too? (I have no clue how memory is allocated there)
jerf 23 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).
ZiiS 23 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).
Tadpole9181 23 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.
tgv 23 hours ago [-]
For workers, you only need to strip the types. There's no need to do the expensive checking.
Tadpole9181 23 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.
TheMrZZ 24 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.
pjmlp 24 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.
eterm 24 hours ago [-]
Faster feedback loops almost always deliver improvements elsewhere.
pier25 21 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).
mohammedalfarra 24 hours ago [-]
[flagged]
kidby 24 hours ago [-]
[dead]
Rapzid 23 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?
lemagedurage 22 hours ago [-]
For VSCode: 4x speedup vs TS 7, 3x vs TS 7.1
rs_rs_rs_rs_rs 23 hours ago [-]
Yes, it's in the article.
magicalist 23 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.
Rapzid 22 hours ago [-]
3x isn't so wild but still very impressive.
Leynos 24 hours ago [-]
So that's three now. This, tsgo-rs, and `bun check`
alexanderson 23 hours ago [-]
They mention in the post they are working with Theo to absorb tsgo-rs into tsrs.
Rapzid 23 hours ago [-]
Why would they bother merging his vibe slop if theirs is better?
preommr 19 hours 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?
x-complexity 8 hours ago [-]
> why do they need someone else's vibe coded stuff?
Because even if vibecoded, the initial work has already been done, and it would be absolutely foolish to outright dismiss it just because it doesn't meet puritanical standards.
> How is any of this serious?
It isn't & shouldn't be. The upfront demand for "serious" is what kills public projects in the first place, where they all come from an experimentation perspective.
There is no public project out there that (from its first commit) was fully serious: Each & every one of them were offshoots & experiments, testing to see if the thing was possible in the first place.
shimman 23 hours ago [-]
Big tech looks out after their own. That's all there is to it.
Rapzid 22 hours ago [-]
Prob a PR thing with a quick merge to /dev/null
Leynos 23 hours ago [-]
Nice. I missed that. This is good news.
weinzierl 6 hours ago [-]
"[..] 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 [..] actually comes from optimizations discovered in tsrs."
If the improvements were discovered by porting to a different language they very much come down to language choice (even if they can be implemented in the source language of the port).
The "fearless ..." mottos of Rust are not hyperbole but a serious point. They allow you (and the LLM) be brave with optimizations.
mohsen1 18 hours ago [-]
I ran out of patience before models got good enough to get this done.
I wonder if I'm the only one to see Tsrs and immediately think of Terminate and Stay Resident?
throw567643u8 11 hours ago [-]
I'd love to hear from a Rust programmer on the human readability of the Rust code produced in this port.
austin-cheney 15 hours ago [-]
I use the Typescript compiler to report errors to the shell, but that's it.
Both Bun and Node.js will execute Typescript directly without a compile step. If you are able to write your own front-end bundler then the front-end code also gets the same type stripping from either Bun or Node.js. Since both Bun and Node.js start up my large applications about twice as fast as the Typescript compiler executes I don't see any reason to bother.
zarzavat 14 hours ago [-]
This is like saying you only use your car for transportation, but you don't sleep in it anymore because your bed is more comfortable.
norman784 23 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.
jscheel 22 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.
wannabe44 23 hours ago [-]
Y'all building the same thing.
hollowturtle 19 hours 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
sethaurus 4 hours ago [-]
Deno does not have its own type-checker. The `deno check` command is a wrapper for `tsc`. It will use the Go version if given a flag. The code is not first-party and is not in Rust.
brazukadev 19 hours ago [-]
I think it is a response to tsc-ts and scriptc from Vercel. CloudFlare and vercel CEOs have a personal competition going on.
yabirgb 18 hours ago [-]
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.
LudwigNagasena 17 hours ago [-]
The problem with Python is that the whole ecosystem is based on CPython’s implementation details, so every change inevitably breaks something and requires effort of package maintainers to fix compatibility. There is no test suite an agent can follow.
24 hours ago [-]
21 hours ago [-]
ComputerGuru 19 hours ago [-]
Apparently only supported under darwin and linux for arm64 and x64? At least via npm.
fg137 15 hours ago [-]
How is EmDash doing?
Never heard the name again after the initial hype.
I can vibe code my own CMS with one major version update everyday but that means nothing.
frangonf 23 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.
panzi 21 hours ago [-]
I wonder how fast "Doom in TypeScript" runs in tsrs now. XD
egeozcan 19 hours ago [-]
I think we'll see TypeScript ported to minecraft ported to rust ported to typescript before GTA6.
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.
22 hours ago [-]
cryptonym 23 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
ameliaquining 18 hours ago [-]
I expect I'll switch once Vite starts shipping it by default.
tonyhart7 24 hours ago [-]
I thought its TS port of theo
AntonyGarand 24 hours ago [-]
Theo's port is tsc-rs[0] as reference, and is significantly slower and uses more memory than this new version.
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.
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
jdw64 23 hours ago [-]
These days the trend seems to be rewriting everything in Rust.
zeroq 23 hours ago [-]
I'm staying stainless
satvikpendem 22 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.
jdw64 23 hours ago [-]
Did you know? Even stainless steel RUSTs in sea wind.
wyc610721 13 hours ago [-]
[flagged]
btucker 20 hours ago [-]
[dead]
tonetheman 18 hours ago [-]
[dead]
souvlakee 23 hours ago [-]
[dead]
nalekberov 23 hours ago [-]
[flagged]
nalekberov 18 hours ago [-]
[flagged]
g0ld3nrati0 21 hours ago [-]
so rust is now go-to slop language? can't you guys use C or something. I want rust back.
preg_match 17 hours ago [-]
Rust is basically the perfect language for LLMs because it has a strong, comprehensive, and strict compiler. For coding you really need a tight loop for models so they can iterate. C doesn’t accomplish this because it’s far too “anything goes” so bugs slip through. Dynamically typed languages don’t work either because their source code doesn’t contain enough context.
cpursley 20 hours ago [-]
What? You realize how many people now are excited about Rust that were not before? I am, for one.
bakugo 18 hours ago [-]
So excited that you avoid writing a single line of it at all costs.
cpursley 5 hours ago [-]
Well, it's either typed and memory managed Rust or underperforming NextJS/Python slop. Also, I've read way more Rust and understand it more than I ever did before AI tools became good enough. Using a neat package called Crux for cross platform apps which uses the Elm architecture, which I've very familiar with and have written in the past. Instead of gatekeeping, try opening the door and finding out how to help - it's Rust's time to shine.
sashank_1509 19 hours 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.
hollowturtle 19 hours 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
fg137 15 hours ago [-]
Which language do you write to run code in browsers, especially that can manipulate DOM?
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.
typescript is two things: a language, and a type system.
that same type system exists in the javascript language (jsdoc). doing those type checks is the 'slow' part that makes go / rust appealing. not just stripping types to emit js.
brazukadev 18 hours ago [-]
isn't it better to use JSDoc ?
_sinelaw_ 17 hours ago [-]
I assume you mean jsdoc + tsc in js type checking mode (tsc --allowJs --checkJs --strict)?
inty infers more - including generics (parametric polymorphism), while tsc is more of a simpler local inference.
inty is more strict - it accepts less programs than tsc would. This is mostly on purpose (to our benefit) as some of those programs have unsound code like array covariant (downcasting array members of the wrong type). tsc makes it easier to slip through these bugs.
And if tsc + jsdoc is good then the same question remains (do we really need the TypeScript language?)
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.
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.
Native UI with Crux backend. Best of both worlds.
It still, like every other language/tool we have that shares state between threads, has race conditions, for example.
As an example, let's say you have two functions A and B. A only works properly if B has never ran for some reason. Let's say they both accept a reference to a value C, and B changes C's value somehow. Because this is rust, we can't have data races, so we wrap it in an ArcMutex or what have you. That doesn't impact the ordering of A and B at all.
If we spawn threads that execute A and B at the same time, it's up to the scheduler if A functions properly.
Maybe I spend too much time on tech internet...
Please copy and paste from my post where that's being asserted
> Its touted purely as a _memory_ safe language
Which is different from what was said... how?
> To claim otherwise is absurd and very telling of the writer's biases
To pretend that those claims were made is what's actually telling of biases.
Because memory safety isn't just about data races. In fact data races are far from Rust's most innovative or important feature. They are a side-effect, the designers had a nice system and saw it can also prevent data-races, so they said "sure, why not".
Your question boils down to "why would humans maintain something?" which could have a variety of answers depending on context.
https://github.com/microsoft/typescript-go/pull/4313
"Just" publish the language specs and be done.
I don't think a spec would facilitate them at such a low effort level and cost.
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.
A Rust implementation will have the fastest compilation speeds, memory safety, can easily be compiled to WASM, or compiled to a native node module.
A TypeScript implementation provides the most convenient way for TypeScript code to use the typescript package as a library. Pure JS, no native code or WASM dependencies. No FFI tax, can be jitted.
Go was always a compromise to make a port easier for humans. Go's GC makes it easier to keep the general code structure from the TS implementation. However that GC is also a liability, you sacrifice speed and embeddability.
Personally I'd prefer they went back to TypeScript for the reference implementation, and used Rust for the performance implementation. Go doesn't bring anything to the table anymore.
Incorrect. I can maybe agree that those are the only perfect languages to implement tsc in them (if there is such thing). But in the real world, "perfect" does not actually mean "it's a good idea". Go made the most sense to port to (especially before agents), more than Rust (although C# could also be a good idea IMO).
I also still think C# would have been a better long term option for maintainability, but I'm not on the Typescript team and didn't get a vote, and I can understand their methodology even if I don't agree with it.
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 the Rust version is faster but the difference is probably only noticeable in the top 1% largest projects.
On foot I cross the little residential street where I live, walk to the corner, cross the busier road using a Zebra that was installed by thoughtful "pedestrian first" local government, then walk to the next corner where the main entrance to the supermarket is.
In the F1 car lets assume somebody already pre-warmed it and so it's ready to go (F1 cars do not "just work" like your family car because that's not required in the F1 rules) I walk to the car park and get in, I need to accelerate quite hard to get the slippery F1 car up the steep drive, but then brake hard to stop and have somebody else check both ways since an F1 car isn't equipped for this in a side street. Now I pull out, takes no time to reach that street where pedestrian me crossed but I can't use that route in a car, so, go through another residential area, turn onto an old main road, turn again, to a roundabout, go into the underground carpark of the supermarket. Once I've parked I'm about as close to the front door as if I were walking from the Zebra. Huh.
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 ?
The question isn't really if the speed is bad, it's what tradeoffs you need to make to realize it. The F1 car has a very narrow operating condition and so can make tradeoffs that are completely unreasonable for vehicles that need to do other things.
From what cloudflare is claiming, Tsrs gives me more speed without tradeoffs I care about, so why not have the free speed?
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.
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.
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).
For sure but those high volume use cases are extremely rare.
But in any given year I maybe plant a dozen new plants tops. 6 tomato plants and half a dozen other random things.
"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.
the analogy is not between each specific consequence/cost, it is relative to "single axis optimization" not being a solid strategy
Its a great way to divide and kill the popularity of your project. I made sure bun is no longer used in my devices or projects that depend on it for example, I'm not alone in this.
This is probably the most harmful tech ever created simply because how many people trick themselves into thinking they're smarter while actually becoming much dumber. We're actually cooked.
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)!
Another advantage human ports have is the opportunity to reconsider earlier architectural decisions and change them, instead of just enshrining them in the new language.
Only practical option is to do low level rewrite (otpion 1) and then rewrite module by module into better approaches.
>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.
Then why are the performance graphs the headliner topic in the article? The WASM sandbox is barely a footnote.
If you’ve got it, flaunt it?
> The WASM sandbox is barely a footnote.
This one is a real head scratcher. The sandbox was clearly what set them on this path.
Maybe they believe the performance gains are worthy of being discussed by themselves?
> 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
I didn't push performance in a way that would cause big deviations from the Golang project's algorithms and data structures; similar to how the TS team didn't want to deviate too far from the JavaScript source till now. Aggressive unmanaged arenas and object pooling was the direction I would have pursued..
The GC in DotNet is a source of major frustration for a tool like this. Without tuning lots of gen 0/1 work occurs to determine if objects should be promoted. The tuning is still not an ideal solution IMHO. Fully unmanaged arenas and aggressive object pooling could help here, but an alternative GC may be part of an ideal, comprehensive solution.. I have have a play with ZeroGC.
There is a warning on the repo that it's not maintained, but I've been curious about the process of updating it to sync "upstream" changes. And it sounds like the TypeScript team are going to start incorporating some of the performance techniques identified in the Rust port in the 7.1 release so... I'll probably at least sync it to up to 7.1 and keep it as an active experiment and case study on LLM porting and DotNet AOT performance.
It's just good fun.
The benefit of those enhancements being wrapped into the reference implementation is it's "easier" for humans and LLMs to reconcile and keep things in sync.
> We cannot ignore individual benefits in contributing, but that is not everything.
Individual benefits are the very foundation of most collaborative efforts. Pharmaceutical companies get payouts via patents for researching life-saving medicine. Even with money taken out of the equation, many academics slave for years over their research in hope of recognition either via Tenure or Nobel Prize. Ignoring the fact that people want credit for their work is dangerous and irresponsible.
Forking projects that are near-complete or have already undergone major refactors just to snipe them last-minute with vibe coded efforts is going to kill collaboration. I'm never building another project in the open again because that is precisely what I'm aiming to avoid.
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.
Why not vibecode a Go -> WASM cross-compiler, then?
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 :)
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.
It's not. Even the JS compiler is still fast enough for many projects given the single core improvements in hardware (eg Apple Silicon).
This can type check and compile VSCode in less than a second?
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?
Because even if vibecoded, the initial work has already been done, and it would be absolutely foolish to outright dismiss it just because it doesn't meet puritanical standards.
> How is any of this serious?
It isn't & shouldn't be. The upfront demand for "serious" is what kills public projects in the first place, where they all come from an experimentation perspective.
There is no public project out there that (from its first commit) was fully serious: Each & every one of them were offshoots & experiments, testing to see if the thing was possible in the first place.
If the improvements were discovered by porting to a different language they very much come down to language choice (even if they can be implemented in the source language of the port).
The "fearless ..." mottos of Rust are not hyperbole but a serious point. They allow you (and the LLM) be brave with optimizations.
https://tsz.dev
Congrats to the team on getting this out
Both Bun and Node.js will execute Typescript directly without a compile step. If you are able to write your own front-end bundler then the front-end code also gets the same type stripping from either Bun or Node.js. Since both Bun and Node.js start up my large applications about twice as fast as the Typescript compiler executes I don't see any reason to bother.
Never heard the name again after the initial hype.
I can vibe code my own CMS with one major version update everyday but that means nothing.
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
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
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
You need a quick reality check.
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)
that same type system exists in the javascript language (jsdoc). doing those type checks is the 'slow' part that makes go / rust appealing. not just stripping types to emit js.
inty infers more - including generics (parametric polymorphism), while tsc is more of a simpler local inference.
inty is more strict - it accepts less programs than tsc would. This is mostly on purpose (to our benefit) as some of those programs have unsound code like array covariant (downcasting array members of the wrong type). tsc makes it easier to slip through these bugs.
And if tsc + jsdoc is good then the same question remains (do we really need the TypeScript language?)