Posted by hnisjafx40 8 hours ago
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.
It still, like every other language/tool we have that shares state between threads, has race conditions, for example.
Your question boils down to "why would humans maintain something?" which could have a variety of answers depending on context.
"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.
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 ?
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).
"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.
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)!
>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.
> 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.
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)
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?)
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.
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.
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.
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?