r/typescript • u/DanielRosenwasser • 7d ago
Announcing TypeScript 7.1 Beta
https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/?r46
u/shandrolis 7d ago
Excited to see this, and faster than I imagined to be honest! Looking forward to the release, for the TS Api especially
8
u/rodrigocfd 7d ago
Same here. The performance improvements look impressive, I wasn't expecting that much.
Congrats to u/DanielRosenwasser and the TypeScript Team.
13
10
u/shakshukinha 7d ago
At what point did t3code get included in benchmarks lol
3
u/ThrowTheCHEEESE 7d ago
tsrs and the other rust ports made waves with it in their benchmarks. I’m guessing the typescript team wants to compare to that
3
u/Top_Bumblebee_7762 6d ago
Mappers seem to be a popular feature. The creator of zod has built a library for it already https://github.com/colinhacks/motherload
5
u/Clickin650 7d ago
finally programmatic api is comming. my astrojs and sveltekit projects are wating for tsgo 7.1
2
u/shakshukinha 7d ago
Very excited tbf with the new API and snapshots feature. This opens a world of possibilities
2
u/ColaFanta_ 7d ago
That seems a huge update, cannot wait to try it! Finally there is the TS API here
1
1
-31
u/musical_bear 7d ago
Not that I expect any action from the team necessarily, but I was kind of hoping for some kind of official acknowledgement or musings on the recent wave of agentic-coded Rust ports. I don't want to downplay the efficiency improvements in this release, but it does feel a little less good than it should knowing that there is possibly even more low-hanging fruit where that came from that could be unlocked "easily." It seems like if something of that nature were to be done, it would be ideal to do it before the TSGo codebase and community have gotten too comfortable / familiar.
27
u/DanielRosenwasser 7d ago
To be totally open, we are balancing all of that while also trying to make sure that TypeScript 7.1 gets shipped. We reached out to the authors of different ports but don't want to make any statements prematurely and randomize the community. The short story is we want to first understand how these ports got faster. The common theme was often that the authors asked an agent to port to Rust and it seemed to work but it wasn't faster; and so the author then had the agent make it faster. We're experimenting with a separate Rust port and are seeing something similar, and we've also experimented with our new API overlaid onto tsrs to validate future directions.
I don't think there is a risk in the community getting "comfortable" with TS 7 based on the way it's implemented today. Even after 7.1, our API should work fine regardless of implementation language.
9
u/musical_bear 7d ago
Appreciate the response. All I was hoping was that you guys were at least looking into it and critically weighing options, and it sounds like you're way ahead of me. I have no attachment to any of those specific rust ports; I just want TS to be as good as it can be. And completely understandable on just getting 7.1 out and leaving this conversation for later. Huge milestone regardless - great work.
38
u/pr00xxy 7d ago
That's a lot of words, what are you even trying to imply? That they should vibecode a port to rust?
-15
u/musical_bear 7d ago
I would just appreciate some sort of official comment on it. I'm not saying that they should vibe code a port to Rust, but I would love to see them critically engage with the idea and explain why they are or are not looking into that option.
And again, the main reason to address it "now" would be it seems like it has a greater chance to get done at all if it happens "now". I've seen indications that members of the team are actually thinking about this, and I was just hoping for some kind of insight from them in this blog, but maybe this isn't the place. Perhaps that will accompany the 7.2 and "what's next" discussions, if at all.
8
u/ArnUpNorth 7d ago
They already addressed it in a blog explaining why they chose Go and it made a lot of sense. What would rust even bring to the table at this point ?
-3
u/musical_bear 7d ago
That blog about why they chose Go is why this conversation is so relevant. At the time that blog was written, no one had access to the tools we do now that (arguably) make the syntax similarity between two languages insignificant when doing a port. Go was chosen pragmatically because they were able to move pieces over essentially 1:1, manually, as humans. Would they have made the same decision if they could have "vibe coded" an entire Rust port in a couple of days and then used that as a baseline? Obviously that is a huge missing variable from their original rationale, because that option didn't exist yet.
2
u/ur_frnd_the_footnote 7d ago
Why is it more likely now? It seems like the more powerful agents become the more likely it is, since that means it is increasingly easy and increasingly trusted
0
u/musical_bear 7d ago
I mentioned why in my initial comment. I'm not saying it's impossible to do it later, and other projects have done this same thing, but it doesn't inspire great community trust or cohesion to get the community on board with the Go codebase for a length of time and then just rip it out and replace it with something else so quickly. To a degree that's already a risk, but the idea of doing it now is that the Go port is still so new, borderline experimental still at this point, so the community hasn't had enough time to get attached to the Go project before it gets replaced.
It's harder to justify the technology swap for not as substantial a performance boost as going from TS -> Go, no matter how "easy" it is, if the community gets too comfortable with the Go codebase in other words.
-11
u/Wonderful-Habit-139 7d ago edited 7d ago
Yes.
Edit: Aight I knew this would be taken as "Yes they should do it". I'm against that lol. Just answered the question directly.
9
u/a_kaydash 7d ago
Daniel commented on the tsrs thread on Hacker News. A bunch of the optimisations in TS 7.1 came from looking at tsrs. https://news.ycombinator.com/item?id=50167925
6
u/musical_bear 7d ago
Thanks for the link -- I saw some of his earlier comments but not this one. And thanks for being the only person actually trying to have a conversation about this (so far). Crazy that people are getting upset for merely suggesting conversations about making the compiler another ~5x faster, conservatively, using an option that did not exist back when the team originally chose Go. The whole point of this rewrite was supposed to be making the compiler faster within a reasonable timeframe.
0
u/VastDesign9517 7d ago
You do realize that the vibe coded projects used the tsgo as reference
1
u/musical_bear 6d ago
Yes, because the tsgo project is the only one that contains the latest features and will continue to get updated. To my knowledge the only reason the Go codebase was referenced was because at the time vibe coding at this scale became viable in general, the latest TS version already happened to be written in Go.
I’m not aware of any reason why this same thing wouldn’t have worked had they referenced the original TS codebase instead. But doing so would have been silly because their reference would have been forever locked to an old TS version.
1
u/VastDesign9517 6d ago edited 6d ago
What problem does rust exactly solve here? What you described is the reason why vibe coding fails. In go they made new features and fixes. Then you get to port using vibe coding.
1
u/musical_bear 6d ago
There are working Rust ports right now that offer yet another nearly 10x speed and memory improvements over the Go port.
There is also this pretty compelling rationale on this specific rust port project https://blog.cloudflare.com/typescript-rust-port#why-rust , which calls out that Rust has far, far better WASM support than Go does, and there are already many compelling use cases for wanting to run TSC in WASM.
This isn't yet another fringe "redo it in Rust" thing. The TypeScript team is taking this seriously (see the OP's replies in this thread, or the link supplied by one of the other comments to the Hacker News discussion where again, the TS team chipped in). Also, both Cloudflare and VoidZero are propping up and sustaining one of the official Rust ports (in that blog I linked above). There is zero reason to do something like this and support a product like that for "not solving any problems."
The impression I got from the TS team member's comments were that they are looking closely at collaborating in some fashion with projects like tsrs.
19
u/BeagleBob 7d ago
> else we’ll leak on the Go side. Instead, we have to do one of the following:
Why didn’t they use FinalizationRegistry ?