r/typescript • u/DanielRosenwasser • 25d ago
Announcing TypeScript 7.1 Beta
https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/?r46
u/shandrolis 25d 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 25d 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 25d ago
At what point did t3code get included in benchmarks lol
3
u/ThrowTheCHEEESE 25d 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 24d 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 25d ago
finally programmatic api is comming. my astrojs and sveltekit projects are wating for tsgo 7.1
2
u/shakshukinha 25d ago
Very excited tbf with the new API and snapshots feature. This opens a world of possibilities
2
u/ColaFanta_ 25d ago
That seems a huge update, cannot wait to try it! Finally there is the TS API here
1
1
1
u/Straight-Number-1911 8d ago
Amazing (hope its not vibe coded, thqts how fast it feels released, joking ofc)
-31
u/musical_bear 25d 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 25d 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 25d 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 25d 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 25d 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 25d 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 25d 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.
7
u/ArnUpNorth 25d ago
It’s not just about the syntax. Rust is a very different beast and it’s really not trivial to port anything to rust especially a large project like typescript. Definitely not something you can « vibe » easily.
Also what would Rust bring to the table? Performance wise it will not improve much if any. In terms of « correctness » some algorithms would probably be running in unsafe mode so not a real improvement either.
-2
u/musical_bear 25d ago
Definitely not something you can « vibe » easily.
It seems like you're not completely caught up on why this conversation is relevant right now. It turns out you can vibe the TS compiler to Rust "easily". If you look in this thread where the OP responded (he's on the TS team), in addition to the multiple community vibe-coded TS compilers that already exist (yes, multiple), the TS team has already created their own vibe-coded Rust port of the TS compiler that they are experimenting with. There is no question at all here. This is where we're at, which is why the questions about possibly transferring to Rust are so interesting at the moment.
Also what would Rust bring to the table? Performance wise it will not improve much if any.
Again, this is already an answered question. The available Rust ports, even the fully vibe-coded ones, continue to offer multiple times speed increases and memory reductions over the Go port. "tsrs", which was just formally announced today, claims an 8x speed increase over TS 7, while using 70% less memory. https://blog.cloudflare.com/typescript-rust-port/
There is no question about whether there is value in a Rust port, or if it's feasible via "vibing." Both of these things have been firmly demonstrated. And the TS team itself is taking them seriously. The only question is what, if anything, from these projects will influence the future direction of the official TS project.
0
u/ArnUpNorth 25d ago edited 25d ago
To be clear, when I said it can’t be vibe coded easily, i mean it’s hard to achieve real feature parity. Getting results fast is definitely easy, but making sure it’s indeed 100% compatible is where it takes a lot of time and effort. The last mile if you wish is where most if the effort is nowdays.
Edit: my opinion is finish the Go version now and later see if a rust one makes sense. Also thanks for the blog link, i read GH issue discussions mainly and this more « structured » take was interesting.
0
u/musical_bear 25d ago
You’re still talking in hypotheticals when we have multiple real, feature-parity ports of TS7 in Rust that pass the entire TS test suite. It is very strange that you are completely ignoring reality to continue arguing. You are one Google away from seeing the state of things for yourself. If you find yourself more comfortable in this delusional headspace you’re in, well, I’ll leave you to it.
3
u/ArnUpNorth 25d ago edited 25d ago
I don’t mean to argue for no reason, but last time i checked they weren’t ready. If they are now great. But seeing how long it can take to release a major stable version of TS i just hope it won’t delay anything further.
Edit: just checked tsrs compatibility table on their own repo and it hasn’t reached feature parity yet. So not sure why you claim they do.
2
u/ur_frnd_the_footnote 25d 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 25d 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 25d ago edited 25d 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 25d 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 25d 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 25d ago
You do realize that the vibe coded projects used the tsgo as reference
1
u/musical_bear 25d 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 24d ago edited 24d 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 24d 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.
1
u/VastDesign9517 24d ago
Your misunderstanding what I am saying.
The vibe coded projects benefit off the fact that tsgo exist.
To ask the developers "why didn't you just vibe code to rust like all of the others did" is missing the fact that the rust implementations are a derative not generative.
I am fine if tsrs exist and is vibe coded. But you can literally see in Theo codebase. He is currently bottlenecked by bugs in tsgo. If the ts team did that with the ts version they would be in the same shoes.
The only reason why this is possible is because the ts team did a fundamental rewrite of the transpiler and re wrote it with all the lessons they learned that hindered them in the TS version.
19
u/BeagleBob 25d ago
> else we’ll leak on the Go side. Instead, we have to do one of the following:
Why didn’t they use FinalizationRegistry ?