Typescript Just Got 10x Faster

And if Wes were to pick another one, then But there's this, like And that was really Scott of how the port progressed.

We're we're but but we would we do want things that are, like, more reasonable within the type system to be a lot faster. Right? And so, you know, like, I think we've had conversations around,

The runtimes themselves have always interesting and, you know, they're working on these sorts of things. They they do want to strive to make this accessible for JavaScript users.

has different challenges problems you might run into like cyclic data structures and and whatever. But this so supposed to saving you from this problem also actually,

that

That is that is just an artifact of of of Turing completeness. Right? And so That's interesting.

Well, I mean, once once you're 10 x faster, you know, you Yeah. You could you could potentially

That's fast. I mean, 4,700

has hit the limit of template literal types,

Yeah. We're we're just this this thing, you know, either a command line compiler that that writes to the console or a language service that doesn't write at all but short message.

sooner.

more contextual information quarter of the file. Well, we give them the

Man, I didn't even think of that. Like, immediately, my mind went to, I can now type check my entire project

a lot there's always this, like, kinda dance between, like, a super powerful inference

if you're running a program

Yes. And type checking your entire project in one fell swoop is gonna be just endlessly easier. Right? Is that is that the the whole goal here?

checking of them now,

You know? Oh, yeah. Right. Or on save.

That haven't really and emitting

This JS this has been one of those sort of funny conversations that we've always talked about, regardless of the rewrite, JS, like, are you all familiar with the with this concept of induced demand,

or thirty or whatever, you know, your size of your project is, it's basically instantaneous.

checking element LLM output,

in getting to 10 x. Because the 10 x doesn't just come from native code. Half of it comes from use of shared memory concurrency,

where, like, you know, as you build out more roads,

So

not have sub projects or whatever and just make a big mono mono project out of it if if you want it. But I think that that So we're 10 x ing, the the the speed of the of the the TypeScript compiler and toolset.

I mean, the porting effort semantically oodles, of course.

And so the game is if if you can't utilize all of those course, you're just leaving a ton of money on the table. And JavaScript

that we could potentially make it 10 times faster. Right? So so now we're sort of unleashing the beast finally. Right? Because Yeah. We do have an incredibly fast compiler. I mean, the ability to compile one and a and fully type check one and ESLint one and a half million lines of code in five seconds,

to run a program to figure out the errors like, Versus Node extensions

we want something that can be a plug and place replacement for for our existing compiler. And the only way you get that And and we have not upped those limits, and we're not planning to. Okay. Yeah. You know? So Yeah. So you'll you'll hit the limiter quicker, but it'll be the same limiter.

So it's sort of like, you know, we we we've always been wary of, like, well, we're not trying to give more rope, to people.

It comes with a whole slew

JavaScript functions

Okay. Okay. That's good. So how long has this been in development for? And and has it been difficult to not mention it until now?

and generating types. So now I assume this means we'll be able to do a lot more

And, of course, that we've also seen efforts in the in the community to to attempt to port TypeScript, half of our performance gain is from being native code and the other half is from being able to utilize all those CPUs

you know, the they're working on it, but at at the same time, it it it will take some time before JavaScript is there, I think. Okay. Yeah. The TypeScript toolset is very much an outlier in suitability

Well, as someone who has,

So when when you say you you ported it, does it mean you literally just took all the different

ever could be a union.

server

not bonkers,

right, we have we have gotten such a good pulse. Yep. And we've been able to make it that great toolset. Right? And and JavaScript is, like, pretty fast on a whole, right, for for the search of things that needs to model. Right? I mean, it's a highly dynamic language in many ways. Yeah. I would add, I I'm actually pretty proud of the compiler we built in in you Node, like, everyone would tell you you're absolutely

the thing that we are it means that we don't have to go in and make the entire type checker thread safe tools, invocations

crazy inference.

Yes. I mean, you've seen you've seen Node running in

the runtime platform for compute intensive at all. Each of these type checkers are completely isolated.

That's amazing. And so Versus Node naturally will just inherently feel faster all around. Right?

and get for the same behavior.

basically forced us to leave that money on the table because and and there are good reasons why why JavaScript doesn't support shared memory concurrency.

and all sorts of clever ways of using template literals and picking them apart with conditional types and and and inference and so forth.

JS, like,

language to write TypeScript in, but TypeScript is a fantastic language to write most of the other stuff, applications in this world. Well, it's by building TypeScript in TypeScript, The whole, like, being able to produce heat with a battery is is amazing. Yeah. I know there's probably a limit to to how much, but it they're great. I should get a pair of these. Yeah. I usually just use my laptop on a video call.

Yeah. Totally.

you know, there's all these sort of limiters and things like that to make sure that you know, our type system is expressive, and it's Turing complete.

really quickly. Well, well, you really can't because you have to rethink

And if you make that same string accessible by multiple threads, then, like, now you need to, like do you have to lock on that thing? Like, you know, that's not necessarily gonna be fast all the time. So yeah. I mean, like, the the run times, they're supposed they're made in a way that's good for efficient concatenation over and over and over again. Right?

for for running on the JavaScript

Right.

Yeah. On maybe even on key down,

TypeScript is not the best

handles JSON messages in a in a highly concurrent manner. Right? So we're very much sorta, like, don't fit the profile. Right? And so Yeah. It's not it's not surprising, you know, that that that this environment is not optimized for this kind of workload.

Yeah. So for as as long as it's worked,

And And it was pretty encouraging.

succeeded. And largely, I think it's because they were never

You know? You everything has to be thread safe, and you have to have race detectors, and you have to have all sorts of things that are way beyond what's meaningful

Unbelievable. Yeah. Yeah. So I I guess now might be a good time to say if if not JavaScript, then

for rethinking what we do with the language service because it is now so fast. Yeah. Especially when it comes to things like AI, you know, and like providing

each phase of compilation

opportunities Right now, though, given the velocity, we're probably not gonna take pull requests early on here because there's just so much going on already, and we just wanna get ported.

But, you know, there are a lot of challenges, like, hey. Your strings internally around,

behaviors polymorphically worst case, it produces a list of error messages, right?

someone writing code in the browser Wes which is the natural affinity of JavaScript. Right? It's not just you know, the style of code that JavaScript users would have to write would have to be defensive

that Wes you could go one way or the other way. Like, often would say type inference we were just talking about, there are often many correct results, But it takes for a lot of clever algorithms to tame that beast. Right? And we have a lot of that in there. But but,

a little bit afraid of is that people will just stop optimizing

the So you gotta go check all of the properties. And, of course, those properties might themselves be of type a or b or whatever. And so it all becomes Yeah. That's actually where the bottleneck JS, and you it always surprises you. So profilers, in that sense, I think Yarn are like they're just this surprise generator.

multiple efforts Mhmm.

Yes. It's been difficult for sure. Of course, this conversation about native code is has been ongoing for a long time because everyone knows, you know, that, like, JavaScript comes with some overhead when you run it. And I can talk more about the specific challenges that we face there, but three x from peaking in native code simply because we don't have what happens with with with with classes is whenever you call a method on a class in JavaScript, But this is gonna be an open source project just like the old TypeScript was. So yeah. Beautiful.

Inference

you know, we kinda knew that, okay, we could project from this. And and it just held up, you know, because those early prototypes warp about 10 times faster and were filled 10 times faster. Now there are challenges, mind you, with with getting the 10 x, and and and we should talk about that because an interface pointer when you consider that we're gonna port, come up with a whole new story for how that's gonna work. I mean, our our existing functions on it, you know, so you can call back into the closure and and etcetera, etcetera.

a lot of people have that compile and type check phase in their in their inner loop dev cycle. Right? And that's where all of a sudden, instead of having to sit and wait for like twenty seconds the thing that I I'm excited about is just that possible. I you know, we're not gonna make any promises. And I I I also a long time ago.

there JS no guarantee that anything will terminate.

and and rewrote them in another language. And and I promise we will get to what language it is. Wes. Yeah. Yeah. Yeah. Kinda. Kinda. Yes. Okay.

of last year just because we were curious. Okay. It's like it's time for us to get some data because there's all these rumors. Oh, it's gonna be Node it's gonna be the same speed. It's gonna be two x, five x, 10 x, hundred x, you know, infinite x, faster. You know? People are making all these claims about how much faster, and and we felt, okay. Let's let's spend a little time, try to get a baseline for what what is what is possible here.

its performance is not bad. It's not bad at all if you compare it to other compilers. It does pretty darn Wes. But we've always known

How how are you using it, if you don't understand it? Node. I was I was just curious what the limit Wes. So I tried to make a type of phone number where every number

myriad

And it's a port, not a the brief take a,

and behaves, in general, we're gonna invite you to contribute as well.

Man, that's awesome. And that, performance problems

to be clear, that is that is both parsing and type checking of code bases?

that produces And we Node it, for example, I mean, our existing our our Go compiler now compiles Versus Node with with no errors,

And we compile and

That is that is exactly it. In fact, with with the stuff that we with the stuff that we open sourced now, that is what you can do. Yes. Wow. Now, of course, it's not Deno. But, you know, at the same time GitHub you know, only then do you know that it's verifiably that's a lot harder to parallelize.

will be native code. Yes. Wow.

improvement

replacement treat the node.

like, a marquee project that everyone's familiar with, this Versus Node. And that's, you know, forty seven forty seven hundred files, one and a half million, one point six million lines of Node.

So one day, I'll be able to just type TSC into my terminal, and it'll be 10 times faster?

This is log, stock, and barrel, the the the the whole. Yes. Scanning, parsing, binding, platform. Right? I mean, JavaScript is affinitized upfront that all of these embarrassingly parallel things like parsing and binding I mean, they have

aiming to have a plug and play Friends that go, that's the best thing. I put them in my back pocket when I go for a walk, and I'm nice and warp the whole time.

for our existing toolset

The whole pipeline I think that there's we we've scraped the top hundred repos.

I I I like I said, you know, the the command line compiler,

That can be pretty heavily a lot of computation on the type checker It's really trippy.

resolve all the types, check that they are assignable to all these other types or or whatever, all the various checks that need to be done. Right? And so we really want the same behavior. And so only by porting the code do you get the same semantics And That's right. Yeah. It's getting hot in here. Yeah. Yeah. I know. It's been a long one. Yeah.

We have to filter them on whether they use JS doc or JSX because that port is not complete yet. Okay. But so we've scraped the top hundred that that don't, to drop all of that is that now you're buying yourself a whole bunch of problems that no one bargained for. And so when you sum all of that up, Go just was the it was the natural place for us to go. And I I I will say also, you know, what what interesting artifact of the TypeScript code Bos is that it was from from the get go written in a very functional style.

we're able to more efficiently allocate data structures and things like that. And when you are duplicating some of that memory through, you know, multiple checkers and things like that, you know, it's it's maybe not as much of a savings, but you're still able to go Who you wanna let the cat out of the bag? Or

The the closures are also, like, much more optimized pnpm engines just because they can be. Right? Like, the engines know exactly how to find where a variable lives in a closure, and so it's it's a lot faster than, like, storing it on objects. And because you're just I only say, yeah. Sure. Everything worked the way it was supposed to because you wrote the Node, and it's been working for the whole time, you know, since you started.

the VM does know where the call goes. There's no polymorphism that contains, like, 50,000 lines of code with, like, a whole bunch of smaller functions inside. And the the global Scott, in quotes, of the type checker are the locals of the create type checker function. And it then returns an an object with a bunch of callback to build the data structures, and then you can stop modifying the data structures and treat them as immutable, and then share them amongst multiple other threads in your next phase of compilation.

serially.

And and, also,

He works at ByteDance, and he said

native code language's object model. Right? Because it has like crazy things like expando property. You can use properties. You just go up to an object and jam a property onto it. Oh, yeah. That's fine. You know, you you can compute the property Node, I mean, even, right, with that as an expression.

but we go two to three times faster.

without build mode, meaning no project references Right. By, And Yeah. You know, we've had to put in limiters to make sure that when you when you you know, you just said, you've Wes you do a keystroke in your editor, you wanna get errors

especially JavaScript,

like, TypeScript

correct, right? You can't you can't just hand AI the keys to the car and go, yeah, you go generate the code and then run it, and then, let's see what happens.

when I open up my editor, it takes a few seconds. Usually, what they mean is not that the editor takes a few seconds to open, but, like, you might see a little spinner that says, like, loading, blah blah blah, and its dependencies. And that's from that's from the TypeScript language service.

I guess, pprof, and and also a tool that we used in JavaScript that someone on our team, Jake on our team, built called pprofit,

or a big web app, it's almost definitely written in TypeScript these days. Right? And and many of them are not, you know, what they call

ASTs, it just changed the constructs in JavaScript into valid Go constructs. Operators are slightly different and there's no ternary operator and blah, blah, blah. That sort of thing, right? if you have cyclic data structures, that

in TypeScript itself

implement. Because USB rechargeable we could start off 32 web workers, So we had to do some serious reengineering of our data structures.

part of the power of TypeScript's type system is that it's structural.

bigger. Right? We we've and and we've talked with companies

Node So on this type, I'm Versus Node, I think, or yeah. I mean, it's it's a lot.

And type checking is not so kind

and data analytics platforms of, you know, trying to slice and dice data,

this replacing TSC as we know it? It depends on which part of TSC. If you're just talking about the command line compiler, we're pretty we're pretty close.

Yeah. So we wanted that level of control.

in parallel,

you'll want to check out Sentry at century.i0/syntax.

But we're close. We're really close. I'd I'd say we're, like, 80 to 90% done. And Yeah. I I think it also you know, it opens up I keep coming back to, there's this new AI frontier

and so forth. But there's also,

Are there specifically

they're gonna say, well,

Right? So for example, pnpm access type, the ability to

people that have it. So Versus Code is obviously a large code Bos. Would you say it's 50 megs?

We're we're so excited by how everyone else JS excited when they hear about this. Yeah.

And that that comes partially because, you know, parsing is literally just, like, allocating constantly, like, going and chomping up your memory.

You Wes, basically,

the object Node in Go

some builds

and so forth.

the language service, in serial then

So so a lot of that has been sort of solved by being able to, like, throw Node routines at that at that process, being a little bit faster, having this background GC thread that is just, like, and You know, it's helped us optimize the job ship code Bos, the type job Vercel of the type of Node base. And it's also helped us find a lot of great wins as we've ported over the new code as Wes, because, you know, some allocation stuff is a little different here or whatever. But but it it has given like, told us, hey.

We are now in the AI era.

some form of verifiability

We have very few classes in there. The type checker

greenfield

And Mhmm. Because, oh, it only takes ten seconds. Right? And so now instead, you're just gonna generate 10 x more types and stop at ten seconds as opposed to actually get it down to where it should be. Right? This is the problem of having a Torrid complete type system. You are basically

you know, build mode and a language server

as to be embarrassingly in about five and a half, six seconds.

of a typical program. The two thirds that remain is the check phase, the type checking.

you know, that would that would tell you, oh, here here's here's you know, you're looping here way too many times, or this is this is too expensive. So that's something down the line we may wanna may wanna look at. I think also, and all of the issues that come along with ownership and blah, blah, blah, and dangling pointers or what what what have you, right? points to itself but gives you the ability to

I don't know if you guys can prepared with, either of those.

And that then allowed us to attain a certain velocity you're dealing with manual memory management. Now it has the borrow checker that saves you from a whole bunch of you know, on the fly,

is the most computationally

was a must.

And then the six point o, the current JavaScript code base current TypeScript code base will continue in Scott of the six point o, like, lineage.

But if you're trying to port

That's why we have those nested errors?

large

that builds around our tools and Yeah. Where we have to, in some cases, is quite different from JavaScript's object model. Okay. Well, I should say to be honest, what I should say instead is JavaScript's object model is quite different from any other in the universe. And so we wanted great support for concurrency.

the reasons for that, of course. We did indeed experiment with many other languages.

Right?

you know, I have a long history with C Warp. And why not my favorite language, x, y, or z? If you look at our wish ESLint, everywhere, these type constructs we have are incredibly powerful, but with great power comes great responsibility. And and Mhmm. And, you know, I I'm just hoping that the community will continue to be responsible.

I guess that's easy to analyze something. We we always have to involve the compiler in in semantically the first the very first TypeScript compiler and then binding, install simple tables in the ASTs. And then from there on out, we don't modify them. And that means we can now have multiple that we all get.

just AI is maybe more suitable there. So Wes, no. It would be a hundred times faster because it's three times faster because of native and 32 times faster. Oh, yeah. Yeah. You're right. Because, like,

assignable or equivalent they're all sitting in the same memory, from that effort. That is the really parse, check, bind, demit, the whole thing Okay.

but it's it's significant. Right? It's a huge win for CI. Right? Yeah. Yeah. We had,

parallel.

way faster, and you're still consuming generally less memory than, like, the JavaScript version of TypeScript today.

You can also get it it was originally made for the Go community. Right? It's great as long as you've got something from your language toolset, and there's a pretty good one for JavaScript to get this. Cool. You know, a little anecdote there that

was just a thing that, oh my god, we'll just never be able to take advantage of of this latent

really,

That's really its output.

money on the table in some cases. And, I mean, there's still more for us to do.

one thing to keep in mind is that that we've gradually been I mean, we're running 20,000 That requires someone has to be able to check the semantics because, and JS is JSON or having

you ask for auto imports. And for all the auto imports, it needs to figure out, like, you know, what's the best way to display that?

everything can reference everything effectively. And that means you've got to build up the entire program

could have it in Versus Node by Christmas,

Well, there there's a lot of analyses that we we've often said, well, that's expensive.

uh-huh. So that's the cheat, if you will.

This will help you, like, figure out

lazy by nature and doesn't need to type check the entire program to produce the errors for a a single file. In fact, we have the ability to just type check one file.

how good they are for the environment, right? You buy these like little At least, no.

It is, but it works remarkably well because now you can implement casts resolving types, sometimes resolving the same type, but they don't know that.

Now as warp type checking this file, that that means we're gonna visit the AST, walk down all the nodes in that file, and check every and and, of course, they're gonna reference stuff in other files. So we're gonna go do some work resolving types over in this other file and that other file, but most of it is local. And on all major platforms, first of all. We wanted a language that could give us great support for

Things like parsing source files and binding source files.

So there's there's more experience in your favorite editor, like Mhmm. Versus and Versus Code. Right? When you open up a project

Because anyone can walk in and assign a new value to this property and that's what your methods are. Now that in turn means that inlining is basically off the table, because the VM doesn't know where this call is gonna go because, like, a couple of instructions later, it might go somewhere else because someone assigned a new function pointer here.

every single one of the data structures and how they hold on to memory and the lifetime. And that's, like, the key thing is, like, you you do think about the lifetime. That's a feature of that language.

and then we give each of them a quarter of the five. Well, we give them the whole program, it's meaning that it's syntactically correct. So we would literally take the TypeScript AST, and then we had an emitter that would emit out Go.

that's that kinda ties into that question of, like, port versus rewrite. Right? Because as soon as you start to have to make some of the same calls

be computationally a in in getting there. But what I was gonna get at then with with the with the port was that we get, like, those can the existence of a garbage collector. And garbage collection has never been a gating factor for us. It's never been a problem.

tooling ecosystem

another language and you have to rethink, oh, well, technically, this thing could hold on to that thing and the other and and and that's and and now you're not really porting. You're rethinking every single part of your application in the lifetimes.

And we were perfectly happy being garbage collectors. So GC

Wes Anders went off and, like, started off the first prototype, as well.

be closed over as much.

you know, okay. I wanna represent And that used to take more than a minute. And to build on what Anders just said, yeah. You you'll be able to type in TSC

causing

dream up identifier names, the way you do things. I mean, it's constructs that I honestly have not seen in in in type theory before. Like like, what have you. Node, we knew

extension that we have, and and just see how fast it builds. And then, hopefully, we'll make it a little bit easier in the future to to get your hands on it and try it out. Yeah.

Objects, you can never in JavaScript guarantee privacy in in your objects. Well, with later versions of JavaScript, you can get pretty close with symbols and private private fields Yarn a class thing only. But ever since day one, you've been able to create closures in JavaScript where you close over local Scott, and that local state is completely sealed off. No one can access that state other than callbacks that you of the compile time 50,000 In aggregate, they represent maybe a third that is, I think, super interesting. Like what can you do with ultra fast type checkers in the AI era? And how can we start to think even deeper about that, about providing more semantic products? Because that's, you know,

Airbnb has well, I think this JS, like yeah.

So so we were trying to work on things like that on on the JavaScript code Bos too. We have something called isolated declarations. That's, like, a very heavy version of that. There is also a new, a newer mode, called no check, which doesn't Scott check, but it it it checks less if you're asking for declaration files and things like that. So so, basically, it tries to involve the check the the type checker as little as possible to do certain work like emit.

support on all major platforms and native first. I mean, not like some ahead of time compile of of something that first ran us byte Node and whatever. We want to like, something that is optimized for native I started prototyping there. And that actually allows Npm to do inlining, and plus it makes the calls faster and so forth and the state access quicker. And and so so functional style JavaScript actually ends up being more efficient, interestingly.

Everyone, of course, asked about Rust. Why not Rust? And and why not c warp Since, But with with local functions, what is it, and why was that choice made? We ultimately chose to go with, Go, the programming language called Go. And we can get into,

feel like it's it's adding any time to the runtime of your program. But I I would say for a lot of the other things, like, you know, you ask for completions,

but then we tell each of them to check a quarter of the five.

energy going into that. And so,

But structural type systems are also the most expensive kind that you can

and

and they Scott. Right? Now checking, emitting.

well, now you have a bunch of AST sitting in memory.

and everyone can get at it. Now the only way in JavaScript to get concurrency is by having web workers.

just, like, developer salary and,

it could be tricky.

And, you know, some of the stuff that we're doing right now is, like, a naive port, and we're gonna get the real stuff with more of the optimizations

And then finally, I would say Wes wanted a language that's simple and Sanity to approach

you know, the other side of this would be, like, you know, we we were talking about different language choices. Right? So if you pick something like Rust that that doesn't even have, like, a garbage collector

those are the things that also only take about you obviously want AI to look at the code and go, what do you think is a good name for this identifier? What do you use elsewhere? Let me use that. Right? And so forth. So so there there are things like that that we're we're we're just Gotcha. You Node? Yeah. Yeah.

For the sick pick that I have, it's a tool called,

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on over to century.i0/syntax.

the the sort of, like, things that v eight is doing under the hood so that we can try to find

You could do all these nutty things. Everything converts to everything, you know, there's there's and and then the TypeScript type system has union types, right, and and these fancy constructs that, you know, you don't really find in other programming languages.

you're really doing it's always an indirection. All methods effectively are virtual in JavaScript. Right? because Node, the one thing that we couldn't copy and paste were all the data structures,

iteration

will

how much memory are we saving? Right? We're we're actually using less memory now because That can take, like, over thirty minutes ESLint some cases. Right?

with the cycles. And Mhmm. Our ASTs, I mean, we navigate our our apps our abstract syntax trees. Right? They are type constructs or type constructors exactly the same except 10 times faster.

go routines, and then we each give them a source file.

I mean, there there are definitely these these issues where, like, you ask someone why something's slow. Right? For JavaScript code base at scale, and do a whole bunch of stuff before we can actually serve a request.

whatever we expose. Right? And so what do we expose, and how do we go about exposing that? Because it is also not

come and build it yourself.

like like, CI. Their CI bills went down quite a bit. It's it's significant when it gets that large.

all my data structures in TypeScript, all my algorithms in TypeScript the same way,

that doesn't matter. It's it's all about the structure.

We're gonna tell you when things go wrong before they go wrong. We're trying to give you a good editor experience. And then the next step of that is, like, well, like, what are we doing to give you a big chunk of that win out of the box that you happen to do that? So that's part of the native effort. Right? Like, you go for thirty from thirty minutes to three minutes. You go from thirty seconds to three seconds. Right?

these functions don't exist and blah, blah, blah.

Plus Wes are 20% more memory, when you wanna know if type a is them

which is

loop,

leaner profiles.

that meant that we basically had these

And and it seems kinda mundane. Right? You don't see all that work. You don't it doesn't tell you, like, you know, I spent, like,

Anders, do you have a sick pick as well, or are you gonna piggyback on that one?

Absolutely not. We're we're we're not done yet. Right?

And JavaScript will just give you undefined if they're not there. But in Go, you can't do that. You can't just cast something because it's a type safe language. It is not gonna allow you to cast it. I mean, it's like you either have this property or you don't have it. And the only way to get polymorphism

internal to Microsoft and external. Right? So, like,

Bos of soap, basically, that you recharge and then they go for hours and hours and they're awesome.

causes a big problem for you because now you have to unwind that. You have to come up with new data structures that aren't cyclic

projects and, like, you know, electron apps that we've developed are all in TypeScript.

Again, we've been using this tool for a long time, and it totally rules. Alright.

And are there there Yarn parts of TypeScript that are specifically

in a node

a long time.

if you had AI available from the get go. Like a bunch of refactorings And then as you start resolving TypeScript,

our entire system. Right? so huge.

well, we knew that we were leaving all this money on the table on multi core systems, Maybe cyclic and recursive and explodes in your face pretty much all the time.

that there's only one threat. Right? goes and

sometime at the end of spring this year. You know, that's aspirational. Right? Like, we're we're gonna shoot for it. We can't guarantee things, but, like, we'd sure would like to try to aim for that. Yeah. Mhmm. And then,

that style of coding is very that is precisely how Go works also.

shared array buffers. But those are not objects. Those are just blittable bits. Right? deeper interplay there that I think is gonna become more and more important. And that's something we're gonna double down on a lot, I think. Awesome. Is there anything we didn't cover before we get into the last section here and wrap it up? Anything you wanted to say? Well, I I, you know, I hope everyone And then the scheduler just schedules, and off they go to the races. And if you have 16 cores, you go 16 times faster. Man. And then we just wait for all of them to finish, and then now you're done.

did you have the general ideas of where you'd find all of the savings from the Scott? Or I'm sure you're still familiar with the code Bos in general.

because our team is gonna live in this toolset.

basically.

But then once you listen to them, then kaboom, things start going faster.

s see if we were exaggerating. It's No. It's it's not like, oh, yeah. Once you put it together, all the pieces and all the imports is 50,000. No. The literally, the file is 53,041

of course, and then there are all of the then there's the entire precisely the same error messages immutable

But there are no sorts of exotic things you need to get installed. It's mostly go a command line tool called Hereby that we already used to build TypeScript. And then you should be able to run it right on your system, play around with the

in a sense, a historical

really doesn't and, you know, think about these concerns.

runtime. Right? Well,

in JavaScript. There there there basically, there are two ways of having state in JavaScript. You can either have it in objects.

Did you say, alright. Let's get the port working first, and then I I know exactly where I'm going to tackle, or was it a lot more exploration?

if you just explicitly write what the return types are, what the types of your variables are, things like that. And that's because that can all be syntactically projects in a fraction of the time of what it took in the old compiler.

but they build up their own state when it comes to the types. And that means they're running full throttle a bunch of base level functionality will be the same, but a bunch of the more higher level refactorings and and quick fixes and what have you,

and faster

Rust does not have a GC.

All that parsing a source file consists of is load a file into memory in a string

involved part of full experts on engine internals, but we have dove into a lot about engine internals. We have people on the team who have written,

And it's kind of beautiful because problem.

for to parse Viasco, we start off 4,700 But web workers are by design completely isolated and you can't communicate between them other than bypassing messages the drawback here, of course, is that we end up consuming a bit more memory because we have all of these situations where like all of the built in types in the standard library, we end up resolving n times if you have n checkers, right? Because everyone refers to a race, so that gets resolved four times, etcetera, etcetera. But but like I said, by and large, things are local. And so what we see is Wes we've run with four checkers, which is what's currently hardwired into into into the code Bos,

So when you set out to do this part,

he said, like, their thing took, like, thirty minutes to build or something like that. And he Scott they got it down to several minutes. And he he says, like, millions and millions of dollars of

they can be generated a lot more efficiently

hand warmers.

And so for a long time, like, what are we gonna do? But we had this working theory that

see that

and the data type definitions, because

Wes didn't want any of that.

could be scaled linearly

having a good infrastructure person who loves to, like, make everybody else on your team happy, it goes a long way. Right? And, on the very large scale. Right? So, like, you know, Outlook and Teams and Power BI and and then some. Right? So many web

So they all compile, but the sets of errors they produce might not be exactly right. And so we're stamping that out. We're very close to being able to run all of our tests.

he was able to port

And we've been scratching our our heads about that

with other source files or there are no cross references. So it's just like this local compute intensive problem that you can run on one core. And if you have 16 cores, you can go 16 times faster

They introduced a, like, a no slow types ESLint rule.

if not most, we'd like to try to get out by towards the end of this year as well. Right? So, like, hey, no problem. Like, this this is what we write in every one of our plans. Right? It's it's the same then as it is now. We aspire to do these things, and we really wanna aim for that. But, hey, like, all indicators are

just to try to figure out, like, what's the type of each of those things so that I can I can print out a nice name for some of these things, which sounds nuts?

And it can be hard to know when they're expensive. I I will grant you that. There are times where I wish we had a type debugger,

and create dashboards and things like that that are all, So it's it's an all up win, really. And if you Scott more, you can throw more at it as well.

API, if you will, Yarn almost putting it in quotes because the API is effectively, so in that sense, it was also a very natural fit.

There Wes a bit more exploration. I I will say one thing that so we know our compiler very Wes. And and the compiler, like I said, is engineered to be Scott of a very functional piece of code. Right? And and which is which is wonderful because that means that you can do things like these embarrassingly parallel, Yeah. Yeah. It's it's super powerful, but it's also super dangerous, right, if you if if you get too esoteric.

but we've never done the work to actually adopt it. That we're doing now as well, which which makes us more embeddable in in in in a number of of of situations. But but that means there's some new work that we have to do there. So it's a long work stream, and it'll come in phases. Right? But, like, the first waypoint is that command line compiler replacement, and that's pretty close. If we're thinking about, like, concretely, like, actual time lines, we'd like to be able to have something that is But the Node, actually, And we started so we started prototyping.

that when they wanna publish their declaration files, the sort of things that describe to the checker, hey. Yeah. There's a JavaScript file here, but here are the types for it. You don't have to read all the JavaScript. Right? So those DTS files,

Zach. He's, like, he's working on RS Pack.

The only thing they share are the and yet you may depend on which one gets picked.

Well, in a structural language, files. Right? I mean, like, it's Yeah. It's really fast. It's how many megabytes of source code? Is that 50 megs of source Node? it's not in the same process as you, it's in a separate process.

Node. Npm Canadian. I know all about that. Yeah. Yeah. Yeah. They're awesome. I mean, instead of these chemical

you know,

you possibly couldn't do before? I know, like, the the LSP and and whatnot. Is there is there anything else where,

on the number of CPUs you have available on on your machine. However, we compile sure. Well, the big announcement is that, we are porting the TypeScript compiler and toolset to native Node, and we are realizing about a 10 x performance

pretty good on this so far. Good. So maybe

hey. It's JavaScript. You can call anything you want. Yeah. Right? Yeah. Yeah. It's like we had a function. You wanted the function. Yeah. Where's the function? Right? You exported it to And when you can call anything you want, people call anything you want. Right? And that means I our entire implementation I don't even remember how fast you were able to do it from start to end. I think that the scanner and the parser, I had it done in, like, a month or a month and a half.

I I know you just end up with more drivers, and so traffic doesn't actually get solved?

gap.

in a nominal language, well, if let's see. Does b derive from a? Yes or Node? That's a pretty quick check. And if it doesn't, well, then they're not compatible.

And, you know, I I'm not I don't know, Anders. Like, you you could probably answer this too. But Like like you say, it's a mature language now. We're more than a decade old. Right? We're and

embarrassingly

power, you know, that everyone has. Right? And if you want to see all of the errors in your application,

in your Node apps or JavaScript apps? No. It but just more in in our in our compiler implementation. We've used it in the in the the new command line compiler or the new language service. But yeah. It's a format, and then it's also a visualizer. And there's ways of getting it from JavaScript, so you can get a JavaScript profile.

because there's no contention

putting together a good for a while, just had, like, a lot of issues just opening up and and things like that. And they've had to adopt project references and whatnot.

When are you gonna do that? So if you think if you're gonna say, alright. We're gonna rewrite it. That's gonna take

that we've released was actually written in a more class like style. And we found that to be not at all efficient on on JavaScript because But it's definitely

the native port of TypeScript

a language that has global script files, right? That that one file over here can reference another file over there, and or modules can import each other. So and and being a different executable as it's as it's being produced by the AI. Right? So Yeah. It's that things that just weren't meaningful before all of a sudden become possible.

And then finally,

I'm super excited about this project as well, and thank you for all your time coming on and explaining everything to us. Yeah. Thank you so much. Thanks for having us. It's been a pleasure.

Each of them might resolve the same type. So some types will be resolved four times, right? And that's effectively what we are. We do an awful lot of compute, and we have no UI whatsoever, really.

in in the language, to foist on is if you port. Because And and having which means if you have an array of a hundred thingies, you have a hundred allocations as opposed to one allocation type checker right there. But Oh my god. There are examples like that, like SQL parsers

or where you where you cheat like excellent

that we sometimes will call Project Corsa, go through different sorts of representations, and now those have to be thread safe in such in so and so ways because

taking this opportunity to reengineer our language service to use LSP

From all sorts of users who were hitting, like, the scaling issues and the and the memory issues, out of memory issues.

So someone who has 32 cores on their their laptop

step? Yes. That parsing step JS Node 32 times faster? It would be 32.

And ultimately, with all of those in mind, go one out. In particular, reasons why we didn't choose Rust is That turned out not to be the right way of doing it. And there are a bunch of reasons why, you know, but and and some of them are sort of, like, reflective of of of the way Go treats interfaces. But we ended up sort of with a more hybrid model where where we maintain the same kind of data structures that we have in the TypeScript compiler Wes every AST node has a kind property that tells you what kind it is. And that's fine. And in JavaScript, that's all you need because then you can once you know the kind, then you know, and then I can safely access these properties and they'll be there and they'll have values.

Or or you're right. Like, because there's a lot of who knows how much work needs to be done here to actually check that, like, you know, this thing is compatible with this, and then you end up just saying, like, yes.

They they've they've spoken about it in public at conferences and whatnot, but they have a very, very large code Bos that, you know, previously, And the key Wes,

in a data structure.

Or else we would have broken checker. Ts into 10 files output does it produce ultimately, like in a batch compile? So let me back up again. We don't really have a speed problem when it comes to providing language service facilities, like hover, add statement completion, or whatever. Those execute in so little time because a compiler is so lazy

I wanna ask you about some of the larger TypeScript

Now the reason this works, though, if you think about it, is that when all of these parsers then or all these Go routines are done, Over there. What the heck's going on over there? Right? co TypeScript compiler. And we knew from from the get go that that is not what we wanna do. Because if we're ever gonna do this native thing and and move the whole team to, you know,

the amounts that you're hearing about how much we've, like, looked into all of these different things JS how much TypeScript in the JavaScript code Bos before a lot of this. Right? So that that no slow TypeScript that I think you mentioned,

getting the type of this property.

But we have this working theory that that the interesting thing about type checker is what output does it produce when you're when you're batch compiled? Well,

parallel.

of in this agentic era that we're entering? Well, Yeah.

Yeah. Alright. Well, thank you so much for all your work on on TypeScript over the Yarn, to both of you.

things that you have to shake and whatever, and God knows

you Node? I I I think if you have a team and you have a person who is very invested in

exactly identically to how we we we did it before. But we can certainly get error baselines going and then start burning down that that work.

already. So

And whatever features get introduced there, we're gonna we're gonna make sure that we can type check them. But even that work stream is not moving at the same clip as it used to with Wes and ES6 and then and whatever back in back in the old days where lots of stuff was happening. Right? or something. But like desktop CPUs. Absolutely.

We don't distribute it at the moment, but we think that the build step should be fairly easy on the whole if you're willing to get your hands a little dirty with the toolset.

if if you could run the JavaScript

Right? And this this issue of of visiting everything, is effectively exposed. Right? And a bunch of things we do in the language service, you would do differently today

Mhmm. I wanna actually use this as a way to just, like, point out

random collections of source files sitting in separate isolated memory spaces. And we Sanity, but they can't talk to each other. And the only way to get them into the same memory space is to marshal it, which means turn it into JSON, which takes longer than it took to parse the source code in the first place. So

parts of TypeScript that are slow, and and now are they better? Yeah. No. No. No. That that's a really good question. And it kinda ties to a lot of, like, what we were specifically trying to work on

it's very clear what needs to it just needs to function exactly the same way as the old command line compiler. Produce the same errors, do it the same way, have the same semantics and so forth.

and something that has a decent toolset,

a really great profiling tool and visualizing tool for,

any refactoring you do that has to introduce new identifier names, cyclic data structures that have with pair of pointers, and every node has a bunch of child pointers, and you can navigate up and down the tree. And we do that But

with to analyze

will change because of this new compiler?

And off they go to the races.

that that it only resolves a little bit of stuff and then it delivers the answer. So we have no problem responding at less than a hundred milliseconds, generally speaking.

and and once we get there, then there will be a command line compiler that you could that you could use. But then there's the entire type checker is one function called create type checker crazy for building a compiler in JavaScript. Right? I mean, that's what we went and Node, and it it became one of the most widely used compilers in the world. And honestly, now you've given it all up. And so that was the problem that that we always ran ran our heads into the wall on with with with JavaScript. Right? Mhmm. Now that problem simply does not exist in Go because it it has shared memory concurrency JS does most modern native programming languages. But

The new language service may not be

lines long. Sure. And I'll tell you why. It's because that's the only way that you can you can get closed over state

if you in line them all. Right? of challenges.

the way I sometimes talk about it is that what is it that's going to keep AI honest when you're building agents for LLMs,

a huge chunk of the parser.

I don't know if it if it makes any sense, but my this is a pick that my wife came up with that we use now. We're giving these as as gifts to many friends, and they all love them. And they're like with UI and the browser, but we have an excellent execution environment in Node Scott JS. Right? But JavaScript was never engineered to be

Wow. And and then at that point, we were getting numbers that but most of the types are local.

by having each of the cores.

That's from us trying to read through your file system, parse,

not just implementing a compiler, but also a memory manager,

add parse 32 times faster, and then we would have 32 But, obviously, that's that's Well, I believe in the union tax, we we stop after 10,000.

we give or mutexes or You can't buy a single CPU anymore. You can only buy things with at least eight cores in them, right? Unless you're buying a microcontroller

That is

that are completely generic Wes you can have like a T sub K.

if not used correctly. Right?

Yeah. They're I've had a couple friends recommend it because I have a heated vest that I wear often Yeah. Yeah. Yeah. Around the house or whatever. Yeah. Uh-huh.

as a specific build tool, but it's it's all about how

we had this code Bos in Go that had like tens of thousands of errors, but we could copy and paste a function at a time and then fix it up.

embed when porting to Go, you you asked earlier, did you did you literally port function by function? So Yeah. In in the beginning, I was manually porting function by function. Very quickly, we wrote a tool that would take our TypeScript code Bos and then just turn all of the TypeScript syntax into Go syntax. Now layout of data structures. In particular, we want the ability to have structs, which is something that JavaScript doesn't do. In JavaScript, everything is an allocation if you're if you're dealing with an object. There is no way of, like, inlining stuff, Node certain constructs, but it's like not a start from first principles effort, which means we are literally Now it's syntactically correct, but it's not gonna combine

we consume about

I know we had we had Ryan Dahl on. He's creator of Node. Js, and and he he was on talking about Deno.

We Wes have we have a lot of you could call them advanced. You can call them esoteric. You can call them whatever

return out of your function. Right? But you can't have local functions that aren't in the same file as you.

You're able to get rid of all the hot paths out of here, and now this thing is blazing fast. Right?

problems

Whereas

and then build an AST, I. E. Build while in our current compiler proceeds entirely Our wish list includes things you know, let's say, const x colon foo. Well, now you've got to figure out where foo is. Oh, foo was imported from over here, and now you gotta go resolve that stuff over there. So everything a cyclic or a data structure that allows you to navigate that source file.

and was the inspiration for LSP, but

absolves you from I mean, that could go horribly wrong. That probably will go horribly wrong. Right? You Scott have

But that's that's where those Node Scott of things often come up. Or you might have, like, one of those examples where you've got, like, someone trying to parse out SQL, like Anderson.

We have that Wes you first, you can check the kind of the Node and go, oh, this says I'm identifier. In that case, I can safely call the dot assignifier So that

I know that,

once we once we found the right way to do that, and that was actually a journey in and of itself. Because in Go, you sort of start out thinking, oh, well, I'm gonna have an AST.

take advantage of, like, the ability to have state that doesn't need to

when you then combine it with with with conditional types that are Turing complete

code Bos you've seen because I'm I'm always curious about what's out there. And I'm sure you you've both at Microsoft as well as I'm sure you've heard from

Right? And that's what we do. First, parsing, you know, that builds up the ASTs,

It has about 300 different kinds of Node. So probably I should have an interface that represents a node, and then I should have interfaces for each of the different kinds and whatever. And we sort of started down that path.

like, your entire runtime has to be thread safe for that even to be possible.

I know there's some stuff that you buy for they never set out to port. They set out to build a compatible native incredibly expensive

email clients

again, The entire JavaScript runtime is manifestly and producing what we call symbol baselines. But we are still working on our type printer, and that means we can't do type baselines which now is every system Go does not have classes. It's all functions and data structures. And so

And that's not gonna be the case anymore. Now we're gonna be in a separate process as a native exe that, you know, you could only talk to each I've been writing code for a long time. And you always think you know Wes it comes to performance, you go, oh, yeah. Yeah. I know this. This is slow. This is this is what I need to optimize. And then you go optimize and nothing happens. And then you go, but but but but but but for surely did this. And then you run a profiler, and then it's like, woah.

But they run fast Even your phone.

But I I think the the thing that that kinda segues into is that the type checker

on all the cores, it would be 16 times faster. Right? Yeah.

tests

you know, for a very, very big project, like, it's not your favorite we get right to it, and we're able to

And, ultimately,

we do think that there's gonna be a long period

Does this open us up to any features

do you wanna give it back? And we say no. Right? versions of a code Bos. Right? They they often Scott as JavaScript and then move to TypeScript because the scale was so

at rough parity of the command line compiler

exactly Wes don't view it at the new API. We don't view it exactly the same. First of all, we have this, like, native gap that we have to bridge, right, and

what is

and whatever, and what's gonna what's gonna do that, what's gonna keep AI honest is things like compilers and language services. So there's this

you know, many of these are, like, hundreds of projects wide or, like, even thousands of projects large. Right? And so especially if you're doing a lot of the same work and and and, you know, scaling projects is a little complicated.

right? Like, I think we said in some cases, like, to to read all of Versus Code would take, like, a minute. Well,

Wes, they're part of it. Part part partially why. Yes.

we have certain chat apps at Microsoft

We knew that we're porting, and that means garbage collection, automatic garbage collection. We have a code Bos that assumes in August the interesting thing about a type checker is what ideally nothing.

it's

There's bigger out there? Yeah. Yeah. There's definitely

checking that what what happens is correct. Right? But Yep. I'm thinking more like like

and reduce their build times and try to figure out, like, how to how to dig in. And we have a lot of diagnostics tooling there.

It's it's hard. Right? I mean, I think this goes beyond TypeScript

is embarrassingly parallel. We literally start off

Node. On the give it to us, like, when do you foresee timeline wise

And they are dramatically

JIT overhead and we have a more efficient object model and we're compiling straight to native and and so forth. Right? Mhmm. But the other three x that we hear, three to four x, we get from concurrency.

I know it's it's such a mature language where, like, if you were to ask me, hey. What are we missing? Yeah. Yeah. Generics on form data, maybe. You know? Like, not nothing nothing, like, totally crazy.

But, like, if you think about that, right, like, if if you can get thirty minutes out to three minutes, But it's but it's a simple transform. Right? It's not that different in the end of the day. Right? Yeah. If you go back in history, originally, if we were gonna do this because for for years for years, we were being asked, when are you gonna rewrite this thing

into

no communication

So we are working with some of those teams to try to figure out, hey. How do you not spend thirty minutes on a build even on the JavaScript version of TypeScript? Because

Node, is by having interfaces. So we actually have a hybrid model where our AST nodes and also type checker nodes was not too hard. And once we had a scanner and a parser,

slow? I may abuse it a little bit.

It leaked internally to some teams, and they they were immediately, like, give it to us. Yeah. Right. Yeah. Yeah. Wes want the compiler. We're all Did you wear that for the show today? And then the garbage collector says, wow. You've used a lot of memory. Like,

We'll we'll get into the last section real quick of of the podcast where we have, Sick Picks and Shameless Plugs.

It's sort of like functional style JavaScript as opposed to class style JavaScript.

Awesome. I'm I'm really excited about it. So thank you so much.

That's what we do. So the parser building in native code JS opposed to maintaining two code Bos in perpetuity, generates a lot of work. And

You just Sanity 50,000 lines. So I, like, I went to GitHub and opened up checker.s

really, really early language service,

And therefore, they all have to be in the same file.

and we're burning down all of those. None of them crash.

And you've Scott to marshal stuff. And so we got to think about batching instead of the high frequency

method on the Node, which casts that embedded interface to star identifier.

Node, we already have a compiler that is everywhere. Our language service does it everywhere. Our compiler does it everywhere to type check. And so we're we're running around over these trees all over the place. Right? Amazing. Yeah.

There's also the shameless plug. I mean Yeah. I don't know, Anders. Like, is our shameless plug just the new code base? Of course. I mean, please, please go build it. Go go try it out on your Node. See what you think.

because they can recursively evaluate themselves, then you you Scott to like, it it it's

if I'm remembering right, that is sort of a way for library authors to say

that have borne themselves out. And like I said, I said, it might be interesting here to to to talk a little bit about how that is. And and so

And many people will rely on that for API and whatnot. So we still need these teams to scale

having to incur locks and synchronizations which is a thing that we do not have available to ourselves in JavaScript.

But when it comes to give me all the errors in this program, well, now we gotta go visit everything.

that

as I said earlier, that comes with a whole bunch of there are just

probably, we'll be calling it, like, the TypeScript seven point o lineage.

tries the work, tries it on on on their code base as well, as it as it is ready for it. You Node? Once we complete features that that we're we're missing, and now it's now possible for you to use it for your own code, I really Node that people will will do that and then share their experiences with us. And and because, you know, there there will be there will be bugs and stuff that we need to fix in this. And it it certainly helps to have community feedback. We want that to be that conversation to be going as as soon as it can.

and and we have millions and millions of users, and we're not just gonna go Node the boat just to rock the boat and do funny things just because it was interesting. I mean Mhmm. We're gonna obviously track the work that happens in in the ECMAScript standardization committee.

with the Go version, we do and

That is again because it's shared memory. Yes. Yeah. Right. Oh, yeah. So it just had the big

And then we can just come in afterwards and harvest the error messages from each of the type checkers and eliminate the duplicates, and then there you are. That's because it's shared memory? not thread safe or was never engineered to be. It is, in fact, a feature of JavaScript

I mean, if you have a big website

as its native protocol, the language service server protocol that pretty much every language service but TypeScript uses because TypeScript actually predates LSP No. I'll piggyback on on the shameless plug there. But but the stick the sick pick, this is actually Now Because if you think about it, type checking consists of, well,

calculated. Right? And or we can do less work trying to generate the best name for a type and all all this other stuff from the compiler.

a third.

native executable

the optimization points, places where, like, inline caches are not gonna be as efficient. And that's how much is going into this stuff. Right? So, like, on one hand, you have all of our, you know, mental

Node file at a time, visit the entire AST,

we we know that Teams at Netflix and Airbnb has been optimized to run on modern jobs or dungeons. Right? We know about the inter well, like, we're not

or a subtype of, say, type b, But of course, t and k could both be unit types. So really, you're sort of like fanning out in two dimensions, you Node? And very quickly,

bigger than the Versus Code code Bos. Right? To the point where

and it checks everything.

our Node, and it doesn't look completely different. We don't have to go re engineer everything, right? it turns out that

setup, like, thirty milliseconds just on this expression

you know, to some extent, TypeScript itself is trying to do that for a lot of teams. Right? We're trying to say, hey.

whole other things party on those ASTs

a lot of, like, core functionality,

I bet.

where the JavaScript code Bos is gonna continue being the primary thing that people use. Right? Okay. And we're hoping to keep the

jumps around But because you have shared memory concurrency,

Currently, it is sort of,

certain problems in the compiler are what I call And it works. And so now we have a way of porting

best case.

and get, like, a blazing fast. I I Node everyone loves that term. Like, Pnpm extremely fast.

I did. I did. I woke up, and I was like, today's a big day. What t shirt should I wear? I was like, lazy ass is the tee that we gotta wear. Yeah. Okay. I love that. So so yes. It's not just if you run TSC

in your in your terminal. Right? And it's not just, you know, in your CI, and that's not it's also

and you hover over something or you go to definition or you request completions,

Blazing fast. Blazing fast. Oh my gosh. You're wearing the shirt. I love it. Okay. Maybe I guess we should get one of those too. Yeah. Century dot shop. You can get it. It has Syntax label right on it. Yeah. Love it. Oh, that's so funny.

if you start up and you load up a project,

load up enormous

like, the same types of code Bos that powers the compiler also powers that experience. Right? So that means

because TypeScript has always been the thing that powers your language in Rust?

everything from

Welcome to Syntax. We got a really exciting one for you today. A major announcement that I never

thought would would necessarily drop this year or or maybe even ever. I jumped on a call last week with Daniel, and he says, hey. Can't tell anyone, but we're gonna look at having them be more AI driven, because that is just the right thing to do at this point. Yeah. Like like, something as simple as, like, removing unused imports or something like that, is that maybe one that would be better for

this is what we're working on. And I haven't been Node excited in in many Yarn. So I'm super stoked. Today, we have, Anders Heilsberg on. He is the creator of TypeScript,

lead architect of TypeScript amongst

who is the principal product manager of TypeScript. So welcome so much. We'll get right to the point. What's this big announcement?

many other things. You can it's on Wikipedia. You can look it up, and Daniel Rosenwasser,