884: Typescript Just Got 10x Faster

Wes and Scott talk with Anders Hejlsberg and Daniel Rosenwasser about TypeScript’s leap to native code. They discuss the challenges, trade-offs, and the decision to port TypeScript to Go, unlocking faster compilation, better concurrency, and new possibilities for AI-assisted development. Show Notes 00:00 Welcome to Syntax! 00:38 TypeScript compiler goes native 05:24 Challenges in rebuilding TypeScript 08:49 How long has this been in development? 10:32 What does porting TypeScript to native entail? 16:36 Why choose Go? 26:48 The porting process 35:02 Brought to you by Sentry.io 35:27 Type checking and parallel compilation 42:36 Fixing TypeScript’s performance bottlenecks 49:09 Large TypeScript codebases 54:11 What’s the timeline for the new compiler? 58:39 Optimization and AI 01:00:32 New features? 01:04:15 Sick Picks + Shameless Plugs Sick Picks Daniel: pprof-it Anders: USB Hand Warmers Shameless Plugs TypeScript Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. We got a really exciting one for you today. A major announcement that I never thought would necessarily drop this year or maybe even ever. I jumped on a call last week with Daniel and he says, "Hey, can't tell anyone, but this is what we're working on." And I haven't been more excited in many years, so I'm super stoked. Today, we have Anders Hejlsberg on. He is the creator of TypeScript, lead architect of TypeScript amongst many other things. I was on Wikipedia, you can look it up, and Daniel Rosenwasser, who is the principal product manager of TypeScript. So, welcome so much. We'll get right to the point. What's this big announcement?

• 0:44Speaker 01

  Who, you want to let the cat out of the bag?

• 0:48Speaker 01

  Well, the big announcement is that we are porting the TypeScript compiler and toolset to native code. And we are realizing about a 10x performance improvement from that effort. That is the really short message. So, we're 10x-ing the speed of the TypeScript compiler and toolset.

• 1:11Wes Bos?

  Man, that's awesome. And that, to be clear, that is both parsing and type checking of codebases?

• 1:19Speaker 01

  This is lock, stock, and barrel, the whole, yes, scanning, parsing, binding, checking, emitting. The whole pipeline will be native code, yes. Wow. And it's a port, not a start-from-first-principles effort, which means we are literally aiming to have a plug-and-play replacement for our existing toolset that produces precisely the same error messages and behaves in general exactly the same, except 10 times faster.

• 1:52Wes Bos?

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

• 1:58Speaker 01

  That is exactly it. In fact, with the stuff that we open source now, that is what you can do, yes. Wow. Now, of course, it's not done, but, you know, we compile, we take up like a marquee project that everyone's familiar with, this VS Code. And that's, you know, 4700 files, 1.5 million, 1.6 million lines of code. And we compile and everything from...

• 2:28Speaker 01

  Parse, check, bind, submit, the whole thing in about five and a half, six seconds. And that used to take more than a minute.

• 2:37Speaker 02

  And to build on what Enner just said, um, yeah, you, you'll be able to type in T S C and get like a blazing fast. I, I know everyone loves that term, like an extremely fast.

• 2:48Wes Bos?

  Blazing fast, blazing fast.

• 2:50Speaker 02

  Oh my gosh, you're wearing the shirt. I love it. Okay. Maybe I guess we should get one of those too.

• 2:54Wes Bos?

  Yeah, sentry.shop, you can get it as syntax logo right on.

• 2:58Speaker 02

  Love it. Oh, that's so funny. Uh, did you wear that for the show today?

• 3:03Wes Bos?

  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 blazing fast is the t that we gotta wear. Yeah.

• 3:11Speaker 02

  Okay, I love that. So, so yes, it's not just if you run T S C in your, in your terminal, right? And it's not just, you know, in your C I and that's not, it's also because TypeScript has always been the thing that powers your language experience in your favorite editor, like V S and V S Code, right? When you open up a project and you hover over something or you go to definition or you request completions, like the same TypeScript codebase that powers the compiler also powers that experience, right? So that means if you start up and you load up a project, we get right to it and we're able to load up enormous projects in a fraction of the time of what it took in the old compiler.

• 3:57Scott Tolinski?

  That's amazing. And so V S Code naturally will just inherently feel faster all around, right?

• 4:03Speaker 02

  Yes.

• 4:04Scott Tolinski?

  And type checking your entire project in one fell swoop is going to be just endlessly easier, right? Is that, is that the, the whole goal here?

• 4:13Speaker 01

  Well, I mean, once, once you're 10x faster, you know, you, you could, you could potentially not have sub projects or whatever and just make a big mono, mono project out of it if, if you wanted. But I think that, that the thing that I, I'm excited about is just that a lot of people have that compile and type check phase in their, in their inner loop def cycle, right? And that's where all of a sudden, instead of having to sit and wait for like 20 seconds or, or 30 or whatever, you know, your size of your project is, it's basically instantaneous.

• 4:49Scott Tolinski?

  Amazing.

• 4:50Speaker 01

  Yeah. Yeah. I, I think it also, you know, it opens up. Opportunities for rethinking what we do with the language service because it is now so fast.

• 5:01Wes Bos?

  Yeah.

• 5:01Speaker 01

  Especially when it comes to things like AI, you know, and like providing more contextual information for LLMs, you know, on the fly. Checking, semantically checking element, LLM output as it's, as it's being produced by the AI, right? So.

• 5:19Wes Bos?

  Yeah.

• 5:19Speaker 01

  Things that just weren't meaningful before all of a sudden become possible.

• 5:24Wes Bos?

  Man, I didn't even think of that. Like immediately my mind went to, I can now type check my entire project. On maybe even on key down. You know, or on save. Inference is like a lot, there's always this like kind of dance between like a super powerful inference and generating types. So now I assume this means we'll be able to do a lot more crazy inference.

• 5:54Speaker 01

  Please don't.

• 5:59Speaker 02

  This is, this has been one of those sort of funny conversations that we've always talked about regardless of the rewrite is like. Are you all familiar with the, with this concept of induced demand? Um, where like, you know, as you build out more roads, you just end up with more drivers and so traffic doesn't actually get solved. Yeah. So it's sort of like, uh, you know, we, we, we've always been wary of like, well, we're not trying to give more rope, uh, to people. But, but we, 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, uh, 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 turn and complete.

• 6:43Speaker 02

  And, you know, we've had to put in limiters to make sure that when you, when you, you know, you just said, when you do a keystroke in your editor, you want to get errors really quickly. Well. If you're running a program to run a program to figure out the errors.

• 6:58Wes Bos?

  Yes.

• 6:59Speaker 01

  I mean, you've seen, you've seen Doom running in the

• 7:03Wes Bos?

  Yes.

• 7:03Speaker 01

  Type checker, right? And there are like samples like that, like SQL parsers and all sorts of clever ways of using template literals and picking them apart with conditional types and inference and so forth. And of course, that generates a lot of work. And the thing that we are a little bit afraid of is that people will just stop optimizing sooner. And because, oh, it only takes 10 seconds, right? And so now instead, you'll just get to generate 10x more types and stop at 10 seconds as opposed to actually get it down to where it should be, right?

• 7:42Speaker 01

  This is the problem of having a torn complete type system. You are basically, there is no guarantee that anything will terminate.

• 7:53Speaker 01

  That is, that is just an artifact of, of, of torn completeness, right? And so

• 7:57Wes Bos?

  That's interesting.

• 7:59Speaker 01

  So these type constructs we have are incredibly powerful, but with great power comes great responsibility. And, and, and you know, I'm just hoping that the community will continue to be responsible.

• 8:11Wes Bos?

  Well, as someone who has, uh, has hit the limit of template literal types, um, I may abuse it a little bit.

• 8:21Speaker 02

  How, how are you using it?

• 8:23Wes Bos?

  No, I was, I was just curious what the limit was. So I tried to make a type of phone number where every number ever could be a union, but obviously that's, that's

• 8:33Speaker 01

  Well, we read in the union checks, we, we stop after 10,000. And we have not upped those limits and we're not planning to. So you'll, you'll hit the limiter quicker, but it'll be the same limiter.

• 8:47Wes Bos?

  Okay, okay. That's good.

• 8:49Scott Tolinski?

  So how long has this been in development for? And, and has it been difficult to not mention it until now?

• 8:56Speaker 01

  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 faced there. But we've also seen efforts in the in the community to to attempt to port TypeScript, multiple efforts.

• 9:21Wes Bos?

  Yeah.

• 9:22Speaker 01

  That haven't really succeeded. And largely, I think it's because they were never they never set out to port. They set out to build a compatible native code TypeScript compiler. And we knew from from the get go that that is not what we want to do. Because if we're ever going to do this native thing and and move the whole team to, you know, building in native code as opposed to maintaining two code bases in perpetuity, we want something that can be a plug and place replacement for for our existing compiler. And the only way you get that is if you port. Because there are just myriad behaviors that where you could go one

• 10:06Speaker 01

  way or the other way, like often with say type infringes we were just talking about, there are often many correct results. And and yet you may depend on which one gets picked, right? And if you if we were to pick another one, then, you know, problem, right? And and so we really want the same behavior. And so only by porting the code, you get the same semantics.

• 10:30Wes Bos?

  Okay.

• 10:31Speaker 01

  For the same behavior.

• 10:32Wes Bos?

  So when when you say you you ported it, does that mean you literally just took all the different JavaScript functions and and rewrote them in another language? And I promise we will get to what language it is.

• 10:44Speaker 01

  Yeah, yeah, yeah. Kind of, yes.

• 10:47Wes Bos?

  Okay.

• 10:49Speaker 01

  And we started, so we started prototyping, I started prototyping in August 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 one, it's gonna be the same speed, it's gonna be 2X, 5X, 10X, 100X. You know, infinite X faster, you know, people are making all these claims about how much faster and then we felt, okay, let's, let's spend a little time, try to get a baseline for what, what is, what is possible here. And it was pretty encouraging. I mean, the porting effort was not too hard. And once we had a scanner and a parser, you know, we kind of knew that, okay, we could project from this.

• 11:31Speaker 01

  And, and it just held up, you know, because those early prototypes were about 10 times faster and were 10 times faster. Now, there are challenges, mind you, with, with getting to 10X and, and we should talk about that because each phase of compilation has different challenges in getting to 10X because the 10X doesn't just come from native code, half of it comes from use of shared memory concurrency. Which is a thing that we do not have available to ourselves in JavaScript. So, half of our performance gain is from being native code. And the other half is from being able to utilize all those CPUs that we all get.

• 12:13Speaker 01

  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, a microcontroller or something, you know, but like, like desktop CPUs, absolutely. Even your phone, I mean, they have oodles of cores. And so the game is, if, if you can't utilize all of those cores, you're just leaving a ton of money on the table. And JavaScript's 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. It comes with a whole slew of challenges, 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

• 12:58Speaker 01

  way beyond what's meaningful to force on someone writing code in the browser, where, which is the natural affinity of JavaScript, right?

• 13:07Speaker 02

  It's not just, you know, the style of code that JavaScript users would have to write would have to be defensive. And, you know, think about these concerns. The runtimes themselves have always interesting. And, you know, they're working on these sorts of things. They do want to strive to make this accessible for JavaScript users. But, you know, there are a lot of challenges like, hey, your strings internally go through different sorts of representations. And now those have to be thread safe in such in so and so ways because they're supposed, they're made in a way that's good for efficient concatenation over and over and over again. Right? 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 going to be fast all the time.

• 13:49Speaker 02

  So, yeah, I mean, like the runtimes, you know, they're working on it, but at the same time, it will take some time before JavaScript is there, I think.

• 13:59Wes Bos?

  Okay.

• 13:59Speaker 02

  Yeah.

• 14:00Speaker 01

  The TypeScript toolset is very much an outlier in suitability for, for running on the JavaScript platform, right? I mean, JavaScript is affinitized with UI and the browser, but we have an excellent execution environment in node.js, right? But JavaScript was never engineered to be the runtime platform for compute intensive server tools, right? And that's effectively what we are. We do an awful lot of compute and we have no UI whatsoever, really.

• 14:36Wes Bos?

  Yeah.

• 14:37Speaker 01

  We're, we're just this, this thing, you know, either a command like compiler that, that writes to the console or a language service that doesn't write at all, but handles JSON messages in a, in a highly concurrent manner. Right? So we're very much sort of like, don't fit the profile, right? And so it's not, it's not surprising, you know, that, that, that this environment is not optimized for this kind of workload.

• 15:01Wes Bos?

  Yeah. So for as, as long as it's worked, TypeScript is not the best. Language to write TypeScript in, but TypeScript is a fantastic language to write most of the other stuff, applications in this world.

• 15:15Speaker 02

  Well, it's by building TypeScript in TypeScript, right? We have, we have gotten such a good pulse.

• 15:22Speaker 01

  Absolutely.

• 15:22Speaker 02

  And we've been able to make it that great toolset, right? And JavaScript is like pretty fast on a whole, right? For, for the surge of things that needs a model, right? I mean, it's a highly dynamic language in many ways.

• 15:35Speaker 01

  Yeah, I would add, I, I'm actually pretty proud of the compiler we built in, in, you know, like, everyone would tell you, you're absolutely nut bonkers, bad [bleep] crazy for building a compiler in JavaScript, right? I mean, and that's what we went and did, and it, it became one of the most widely used compilers in the world. And honestly, its performance is not bad. It's not bad at all if you compare it to other compilers. It does pretty darn well. But we've always known that we could potentially make it 10 times faster, right? So, so now we're sort of unleashing the beast finally, right? Because

• 16:10Speaker 02

  Yeah.

• 16:10Speaker 01

  We do have an incredibly fast compiler. I mean, the ability to compile one and a half and fully type check one and emit one and a half million lines of code in five seconds. That's fast. I mean, 4,700 files, right? I mean, like, it's, it's really fast. It's, how many megabytes of source code is that? 50 megs of source codes, VS Code, I think, or, yeah. I mean, it's, it's a lot.

• 16:33Wes Bos?

  Unbelievable, yeah.

• 16:35Scott Tolinski?

  Yeah, so I, I guess now might be a good time to say, if, if not JavaScript, then what is it? And why was that choice made?

• 16:44Speaker 01

  We ultimately chose to go with Go, the programming language called Go. And we can get into the reasons for that, of course. We did indeed experiment with many other languages. Everyone, of course, asks about Rust, why not Rust? And, and why not C# since, you know, I've, I have a long history with C#.

• 17:05Speaker 02

  Right.

• 17:05Speaker 01

  And why not my favorite language, X, Y, or Z? If you look at our wishlist, when, when you consider that we're gonna port. Our wishlist includes things like excellent native executable support on all major platforms and native first, I mean not like some ahead of time compile of something that first ran us bytecodes and whatever. We want to like something that is optimized for native on all major platforms, first of all. We wanted a language that could give us great support for layout of data structures. In particular, we want the ability to have struct, which is something that JavaScript doesn't do. In JavaScript, everything is an allocation if you're dealing with an object.

• 17:50Speaker 01

  There is no way of like inlining stuff, which means if you have an array of 100 thingies, you have 100 allocations as opposed to one allocation if you inline them all, right?

• 18:02Wes Bos?

  Yeah.

• 18:03Speaker 01

  So we wanted that level of control. We knew that we're porting, and that means garbage collection, automatic garbage collection. We have a codebase that assumes the existence of a garbage collector. And garbage collection has never been a gating factor for us. It's never been a problem. But it's definitely absolves you from not just implementing a compiler, but also a memory manager and all of the issues that come along with ownership and blah, blah, blah, and dangling pointers or what have you, right?

• 18:36Wes Bos?

  Yeah.

• 18:37Speaker 01

  We didn't want any of that. And we were perfectly happy being garbage collector. So GC was a must. And then finally, we knew that we were leaving all this money on the table on multi-core systems, which now is every system in the universe. And so we wanted great support for concurrency. And then finally, I would say, we wanted a language that's simple and easy to approach and something that has a decent toolset, you know, because our team is going to live in this toolset. And ultimately, with all of those in mind, go one out. In particular reasons why we didn't choose Rust is Rust does not have a GC. You are basically, you're dealing with manual memory management.

• 19:22Speaker 01

  Now, it has the borrow checker that saves you from a whole bunch of problems you might run into like cyclic data structures and whatever. But this supposed saving you from this problem also actually, if you have cyclic data structures...

• 19:40Speaker 01

  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. Or where you where you cheat with the cycles. And our ASTs, I mean, we navigate our abstract syntax trees, right? They are cyclic data structures with parent pointers. And every node has a bunch of child pointers. And you can navigate up and down the tree. And we do that everywhere. Our language service does it everywhere. Our compiler does it everywhere, the type check. And so we're running around over these trees all over the place, right? And having to drop all of that is now you're buying yourself a whole bunch of problems that no one bargained for.

• 20:22Speaker 01

  And so when you sum all of that up, Go just was the it was the natural place for us to go. And I will say also, you know, one interesting artifact of the TypeScript codebase is that it was from the get go written in a very functional style. It's sort of like functional style JavaScript as opposed to class style JavaScript. We have very few classes in there. The type checker, the entire type checker is one function called create type checker.

• 20:52Speaker 01

  That contains like 50,000 lines of code with like a whole bunch of smaller functions inside. And the global state in quotes of the type checker are the locals of the create type checker function. And it then returns an object with a bunch of callback functions on it, you know, so you can call back into the closure and et cetera, et cetera. Now, that style of coding is very, that is precisely how Go works also. Go does not have classes. It's all functions and data structures. And so in that sense, it was also a very natural fit.

• 21:28Wes Bos?

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

• 21:33Speaker 02

  I wanted to see if you were exaggerating.

• 21:35Wes Bos?

  It's not like, oh yeah, once you put it together, all the pieces and all the imports is 50,000. No, literally the file is 53,041 lines long.

• 21:46Speaker 01

  And I'll tell you why. It's because that's the only way that you can you can get closed over state in JavaScript. There are basically, there are two ways of having state in JavaScript. You can either have it in objects. Objects, you can never in JavaScript guarantee privacy in your objects. Well, with later versions of JavaScript, you can get pretty close with symbols and private private fields are a class thing only. But ever since day one, you've been able to create closures in JavaScript where you close over local state and that local state is completely sealed off. No one can access that state other than callbacks that you return out of your function, right?

• 22:30Speaker 01

  But you can't have local functions that aren't in the same file as you.

• 22:34Speaker 02

  Yeah.

• 22:34Speaker 01

  And therefore, they all have to be in the same file. Or else we would have broken checker dot T S into ten files a long time ago.

• 22:44Speaker 02

  The closures are also like much more optimized in 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 a lot faster than like storing it in objects. And with the Go version, we do take advantage of like the ability to have state that doesn't need to be closed over as much. But it's but it's a simple transform, right? It's not that different in the end of the day, right?

• 23:11Speaker 01

  Yeah. If you go back in history, originally, the first, the very first TypeScript compiler that we released was actually written in a more class-like style. And we found that to be not at all efficient on JavaScript. Because what happens with with with classes is whenever you call a method on a class in JavaScript, you're really doing, it's always an indirection. All methods effectively are virtual in JavaScript, right? 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 V M doesn't know where this call is going to go. Because like a couple of instructions later, it might go somewhere else because someone

• 23:55Speaker 01

  assigned a new function pointer here. But with with local functions, the VM does know where the call goes. There's no polymorphism there. And that actually allows VMs to do inlining and plus it makes the calls faster and so forth. And the state access quicker and that so. So virtual style JavaScript actually ends up being more efficient, interestingly.

• 24:17Speaker 02

  Hmm. I want to actually use this as a way to just like point out the amounts that you're hearing about how much we've like looked into all of these different things is how much TypeScript has been optimized to run on modern JavaScript extensions, right? We know about the inter- well, like, we're not full experts on engine internals, but we have dove into a lot about engine internals. We have people on the team who have written like VS code extensions to analyze the the sort of like things that V8 is doing under the hood so that we can try to find the optimization points, places where like inline caches are not going to be as efficient. And that's how much is going into this stuff, right?

• 24:58Speaker 02

  So like on one hand, you have all of our, you know, mental energy going into that. And so, you know, the other side of this would be like, you know, we were talking about different language choices, right? Um, so if you picked something like Rust that that doesn't even have like a garbage collector runtime, right? Well, that's that kind of 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 around, you know, okay, I want to represent all my data structures in TypeScript, all my algorithms in TypeScript the same way. Well, you really can't because you have to rethink every single one of the data structures and how they hold on to memory and the lifetime.

• 25:40Speaker 02

  And that's like the key thing is like you you do think about the lifetime. That's a feature of that language. But if you're trying to port into another language and you have to rethink, oh, well, technically this thing could hold on to that thing and yada 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 the key was If we were gonna do this, because for years, for years, we were being asked, when are you gonna rewrite this thing in Rust? From all sorts of users who were hitting like the scaling issues and the memory issues, out of memory issues. 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 a long time, right?

• 26:25Speaker 02

  Whereas when Anders went off and like started off the first prototype, he was able to port a huge chunk of the parser. I don't even remember how fast you were able to do it from start to end.

• 26:37Speaker 01

  I think that the scanner and the parser, I had it done in like a month or a month and a half. And then at that point, we were getting numbers that that have borne themselves out. And like I said, it might be interesting here to talk a little bit about how that is. And so when porting to Go, you asked earlier, did you, did you literally port function by function? So in the beginning, I was manually porting function by function. Very quickly, we wrote a tool that would take our TypeScript codebase and then just turn all of the TypeScript syntax into Go syntax. Now, 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.

• 27:21Speaker 01

  Now, it's syntactically correct, but it's not gonna compile. Because, you know, these functions don't exist and blah, blah, blah, and, and, and, you know, certain constructs. But, but it's like, 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, that sort of thing, right? Now, that meant that we basically had these,

• 27:47Speaker 01

  we had this codebase 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. And that was really sort of how the port progressed. Now, the one thing that we couldn't copy and paste were all the data structures and the data type definitions. Because the object modeling Go is quite different from JavaScript's object model. Okay. Well, I should say, honest, to be honest, what I should say instead is JavaScript's object model is quite different from any other native code languages object model, right? Because it has like crazy things like expand a property, you can use properties. You just go up to an object and jam a property onto it. Oh yeah, that's fine.

• 28:30Speaker 01

  You can compute the property name, I mean, even, right? With an, as an expression. You could do all these nutty things. Everything converts to everything, you know, there's this. And then the TypeScript type system has union types, right? And these fancy constructs that, you know, you don't really find in other programming languages. So we had to do some serious re-engineering of our data structures. But the code, actually, 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. It has about 300 different kinds of nodes. So probably I should have an interface that represents a node.

• 29:13Speaker 01

  And then I should have interfaces for each of the different kinds and whatever. And we sort of started down that path. That turned out not to be the right way of doing it. And there are a bunch of reasons why, you know, but, and some of them are sort of like reflective 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, where 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. And JavaScript will just give you undefined if they're not there. But in Go, you can't do that.

• 29:56Speaker 01

  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 is by having interfaces. So we actually have a hybrid model where our AST nodes and also type checker nodes embed an interface pointer in a node.

• 30:19Speaker 01

  That points to itself, but gives you the ability to polymorphically treat the node.

• 30:26Speaker 02

  It's really trippy, yeah.

• 30:28Speaker 01

  It is, but it works remarkably well, because now you can implement casts that where 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 as identifier method on the node, which casts that embedded interface to star identifier, and it works. And so now we have a way of porting our code, and it doesn't look completely different. We don't have to go re-engineer everything, right? And that then allowed us to attain a certain velocity in getting there. But what I was gonna get at then with the port was that we get like 3X from being in native code.

• 31:12Speaker 01

  Simply because we don't have JIT overhead, and we have a more efficient object model, and we're compiling straight to native and so forth, right? But the other 3X that we hear, 3 to 4X, we get from concurrency. And it turns out that certain problems in the compiler are what I call embarrassingly parallel. Things like parsing source files and binding source files. All that parsing a source file consists of is load a file into memory, in a string, and then build an AST, i.e. build a cyclic or a data structure that allows you to navigate that source file, right?

• 31:53Speaker 02

  Yeah.

• 31:54Speaker 01

  That requires no communication 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 by having each of the cores. And that's what we do. So the parser is embarrassingly parallel. We literally start off for to parse VS Code, we start off 4,700 go routines, and then we each give them a source file. And then the scheduler just schedules, and off they go to the races. And if you have 16 cores, you go 16 times faster. And then we just wait for all of them to finish, and then now you're done.

• 32:38Wes Bos?

  So someone who has 32 cores on their laptop will see that step?

• 32:45Speaker 01

  Yes.

• 32:45Wes Bos?

  That parsing step is now 32 times faster?

• 32:48Speaker 01

  It would be 32. Well, no, it would be 100 times faster because it's three times faster because of native and 32 times faster.

• 32:55Wes Bos?

  Oh, yeah, yeah, you're right. Because like, if you could run the JavaScript on all the cores, it would be 16 times faster, right? Yeah.

• 33:05Speaker 01

  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, well, now you have a bunch of AST sitting in memory. But because you have shared memory concurrency, they're all sitting in the same memory. And everyone can get at it. Now, the only way in JavaScript to get concurrency is by having web workers. But web workers are by design completely isolated, and you can't communicate between them other than by passing messages and as is JSON, or having shared array buffers, but those are not objects, those are just lidable bits, right?

• 33:46Speaker 01

  And so, we could start off 32 web workers and parse 32 times faster, and then we would have 32

• 33:57Speaker 01

  random collections of source files sitting in separate, isolated memory spaces, and we can't, 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 now you've given it all up. And so that was the problem that we always ran, ran our heads into the wall on with JavaScript, right? Now, that problem simply does not exist in Go, because it has shared memory concurrency, as does most modern native programming languages, but... As I said earlier, that comes with a whole bunch of stuff. Like, your entire runtime has to be thread safe for that even to be possible.

• 34:40Speaker 01

  The entire JavaScript runtime is manifestly not thread safe. Was never engineered to be. And it's in fact, a feature of JavaScript, that there's only one thread, right? So, that was just a thing that, oh my God, we'll just never be able to take advantage of this latent power, you know, that everyone has, right?

• 35:02Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax. 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 sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right. So, when you set out to do this port, did you have the general ideas of where you'd find all of the savings from the start? Or, I'm sure you're still familiar with the codebase in general. Did you say, "All right, let's get the port working first and then I know exactly where I'm going to tackle," or was it a lot more exploration?

• 35:46Speaker 01

  There was a bit more exploration. I will say one thing that, so we know our compiler very well. And the compiler, like I said, is engineered to be, it's sort of a very functional piece of code, right? And which is wonderful, because that means that you can do things like these embarrassingly parallel problems 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, right? And that's what we do for parsing, you know, that builds up the ASTs. And then binding installs simple tables in the ASTs. And then from there on out, we don't modify them. And that means we can now have multiple other things party on those ASTs at the same time

• 36:30Speaker 01

  without having to incur locks and synchronizations or mutexes or what have you. Now, we knew... Upfront, that all of these embarrassingly parallel things like parsing and binding and emitting could be scaled linearly on the number of CPUs you have available on your machine. However, those are the things that also only take about a third. In aggregate, they represent maybe a third of the compile time of a typical program. The two thirds that remain is the check phase, the type checking. And type checking is not so kind as to be embarrassingly parallel.

• 37:14Speaker 01

  Because if you think about it, type checking consists of, well, especially in JavaScript, a language that has global script files, right? That one file over here can reference another file over there and/or modules can import each other. So everything can reference everything effectively. And that means you've got to build up the entire program in a data structure. And then as you start resolving types like, 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've got to go resolve that stuff over there. So everything jumps around everywhere, basically, right? And that's a lot harder to parallelize.

• 37:58Speaker 01

  And we've been scratching our heads about that for a long time, like, what are we going to do? But we have this working theory that... The interesting thing about a type checker is what output does it produce ultimately? Like in a batch compile. So let me back off again. We don't really have a speed problem when it comes to providing language service facilities like hover and statement completion or whatever. Those execute in so little time because a compiler is so lazy that it only resolves a little bit of stuff and then it delivers the answer. So we have no problem responding at less than 100 milliseconds, generally speaking. But when it comes to, "Give me all the errors in this program",

• 38:40Speaker 01

  well, now we've got to go visit everything, right? And this issue of visiting everything...

• 38:48Speaker 01

  While in our current compiler proceeds entirely in serial, serially. One file at a time, visit the entire AST, resolve all the types checked that they are assignable to all these other types or whatever, all the various checks that need to be done, right? But we had this working theory that, the interesting thing about a type checker is what output does it produce when you're, when you're batch compiling? Well, ideally, nothing, but at worst case, it produces a list of error messages, right? That's really its output. Now, we already have a compiler that is lazy by nature and doesn't need to type check the entire program to produce the errors for a, a single file.

• 39:33Speaker 01

  In fact, we have the ability to just type check one file. Now, as we're type checking this file, that, that means we're going to visit the AST, walk down all the nodes in that file and check every, and, and of course, they're going to reference stuff in other files. So we're going to go do some work resolving types over in this other file and that other file, but most of it is local, right? Now, we had this theory, what if we, what if we took the entire program, say it's 4,700 files, and then we, instead of having one type checker, we create four type checkers, say, and then we give each of them a quarter of the file. Well, we give them the whole program, but then we tell each of them to check a quarter of the file. Hmm, mhm.

• 40:17Speaker 01

  And off they go to the races. Each of them might resolve the same type, so some types will be resolved four times, but most of the types are local. 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.

• 40:36Wes Bos?

  That's because it's shared memory?

• 40:39Speaker 01

  That is again because it's shared memory.

• 40:41Wes Bos?

  Oh, yeah, so it just had the big aha.

• 40:44Speaker 01

  So that's the cheat, if you will. Yeah. And it's kind of beautiful because it means that we don't have to go in and make the entire type checker thread safe. Because there's no contention at all. Each of these type checkers are completely isolated. The only thing they share are the immutable ASTs.

• 41:07Speaker 01

  But they build up their own state when it comes to the types. And that means they're running full throttle in parallel, resolving types. Sometimes resolving the same type, but they don't know that.

• 41:20Speaker 01

  But they run fast and they scale, right? Now, 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, all of the built in types in the, in the standard library. We end up resolving N times if you have N checkers, right? Because everyone refers to arrays, so that gets resolved four times, et cetera, et cetera. But, but like I said, by and large, things are local. And so what we see is when we've run with four checkers, which is what's currently hardwired into, into, into the code base. We consume about 20% more memory, but we go two to three times faster.

• 42:03Speaker 02

  And also, how much memory are we saving, right? We're actually using less memory now because 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 way faster. And you're still consuming generally less memory than like the JavaScript version of TypeScript today. So it's, it's an all up win, really. And if you've got more, you can throw more at it as well.

• 42:35Wes Bos?

  And are there, there are parts of TypeScript that are specifically slow? Um, I know we had, we had Ryan Dahl on, he's creator of NoJass and, and he, he was on talking about Dino. Uh, they introduced a, like a no slow types lint rule. Are there specifically parts of TypeScript that are slow and now are they better?

• 42:59Speaker 02

  Yeah, no, no, that's a really good question. And it kind of ties to a lot of like what we were specifically trying to work on in the JavaScript code base before a lot of this, right? So that, that no slow types thing that I think you mentioned. If I'm remembering right, that is sort of a way for library authors to say that when they want to 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. They can be generated a lot more efficiently and faster 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 calculated, right?

• 43:43Speaker 02

  And or we can do less work trying to generate the best name for a type and all this other stuff from the compiler. So so we were trying to work on things like that on on the JavaScript code base, 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 not check, but 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 type checker as little as possible to do certain work like emit. But I I think the the thing that that kind of segues into is that the type checker is the most computationally involved part of our entire system, right?

• 44:25Speaker 02

  I mean, there are definitely these these issues where like you ask someone why something's slow, right? For JavaScript code base at scale, they're going to say, well, 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. That's from us trying to read through your file system, parse, and do a whole bunch of stuff before we can actually serve a request. And that that comes partially because, you know, parsing is literally just like allocating constantly, like going and chomping up your memory. And then the garbage collector says, wow, you've used a lot of memory. Like, do you want to give it back?

• 45:09Speaker 02

  And we say, no, right? Absolutely not. We're not done yet, right? So so a lot of that has been sort of solved by being able to like throw go routines at that at that process, being a little bit faster, having this background GC thread that is just like. Really, really doesn't feel like it's adding any time to the runtime of your program. But I would say for a lot of the other things, like, you know, you ask for completions, 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? That can be pretty heavily, a lot of computation on the type checker, just to try to figure out like, what's the type of each of those things so that I can,

• 45:51Speaker 02

  I can print out a nice name for some of these things, which sounds nuts. But that's where those sorts of things often come up. Where you might have like one of those examples where you've got like, someone trying to parse out SQL like Anderson. 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. And it seems kind of mundane, right? You don't see all that work, you don't, it doesn't tell you like, you know, I spent like 30 milliseconds just on this expression. Because you're just silently saying, yeah, sure, everything worked the way it was supposed to, because you wrote the code and it's been working for the whole time, you know, since you started.

• 46:33Speaker 01

  We have, we have a lot of, you could call them advanced, you can call them esoteric, you can call them whatever, type constructs or type constructors in the language. Constructs that I honestly have not seen in type theory before, like, for example, index access type, the ability to, that are completely generic, where you can have like a T sub K, you know, so on this type, I'm getting the type of this property. But of course, T and K could both be union types. So really, you're sort of like fanning out in two dimensions, you know? And very quickly, those can be computationally incredibly expensive, if not used correctly, right?

• 47:17Speaker 01

  And it can be hard to know when they're expensive. I will grant you that. There are times where I wish we had a type debugger. You know, that would, that would tell you, ooh, ah, 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 want to, may want to look at. I think also, one thing to keep in mind is that. Part of the power of TypeScript type system is that it's structural. But structural type systems are also the most expensive kind that you can implement. Because when you want to know if type A is assignable or equivalent or a subtype of say,

• 47:59Speaker 01

  type B, well, in a nominal language, well, if, let's see, does B derive from A? Yes or no? That's a pretty quick check. And if it doesn't, well, then they're not compatible. Well, in a structural language, that doesn't matter. It's, it's all about the structure. 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 cyclic and recursive and explodes in your face pretty much all the time.

• 48:30Wes Bos?

  That's why we have those nested errors?

• 48:34Speaker 01

  Well, part of it, partially why, yes. 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 again, when you then combine it with, with, with conditional types that are Turing complete, because they can recursively evaluate themselves, then you start to like, it, it's, it can be tricky.

• 49:00Wes Bos?

  Yeah.

• 49:01Speaker 01

  It's, it's super powerful, but it's also super dangerous, right? If you, if, if you get too esoteric.

• 49:07Wes Bos?

  I want to ask you about some of the larger TypeScript code bases 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 people that have it. So VS Code is obviously a large code base. What'd you say is 50 megs? There's bigger out there?

• 49:27Speaker 01

  Yeah, yeah.

• 49:28Speaker 02

  There's definitely bigger, right? We've, and we've talked with companies internal to Microsoft and external, right? So like, we, we know that teams at Netflix and Airbnb and, I mean, if you have a big website 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 greenfields versions of a code base, right? They, they often started as JavaScript and then moved to TypeScript because the scale was so large already. So I, I know. Airbnb has, well, I think this is like, yeah. They've spoken about it in public at conferences and whatnot, but they have a very, very large

• 50:10Speaker 02

  code base that, you know, previously for a while just had like a lot of issues just opening up and things like that. And they've had to adopt project references and whatnot. I know that we have certain chat apps at Microsoft and email clients and data analytics platforms of, you know, trying to slice and dice data and create dashboards and things like that, that are all on the very large scale, right? So like, you know, Outlook and Teams and Power BI and then some, right? So many web projects and like, you know, Electron apps that we've developed are all in TypeScript and they are dramatically bigger than the

• 50:51Speaker 02

  VS Code code base, right? To the point where some builds, right? Like I think we said in some cases, like to read all of VS Code would take like a minute. Well, 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 scaling projects is a little complicated, that can take like over 30 minutes in some cases, right? So we are working with some of those teams to try to figure out, hey, how do you not spend 30 minutes on a build even on the JavaScript version of TypeScript? Because we do think that there's going to be a long period where the JavaScript code base is going to continue being the primary thing that people use, right? And we're hoping

• 51:35Speaker 02

  to keep the native port of TypeScript that we sometimes will call Project Corser, probably will be calling it like the TypeScript 7.0 lineage. And then the 6.0, the current JavaScript code base, current TypeScript code base will continue in sort of the 6.0 like lineage. And many people will rely on that for API and whatnot. So we still need these teams to scale 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. But like, if you think about that, right? Like if you can get 30 minutes down to three minutes, you know, for a very, very big project, like it's not your favorite iteration loop, but it's significant, right?

• 52:19Speaker 02

  It's a huge win for CI, right?

• 52:21Wes Bos?

  Yeah. Yeah, we had Zach, he's like, he's working on RS pack. He works at ByteDance and he said, He said like their thing took like 30 minutes to build or something like that. And he got, they got it down to several minutes. And he says like millions and millions of dollars of just like developer salary and like, like CI, their CI bills went down quite a bit. It's, it's significant when it gets that large.

• 52:51Speaker 02

  It's, it's hard, right? I mean, I think this goes beyond TypeScript as a specific build tool, but it's, it's all about how, you know, I, I, I think if you have a team and you have a person who is very invested in putting together a good setup, like having a good infrastructure person who loves to like make everybody else on your team happy, it goes a long way, right? And, you know, to some extent, TypeScript itself is trying to do that for a lot of teams, right? We're trying to say, hey, we're going to 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 have to do that? So that's part of the native effort, right?

• 53:34Speaker 02

  Like you go for 30, from 30 minutes to three minutes. You go from 30 seconds to three seconds, right? That is so huge. And, you know, some of the stuff that we're doing right now is like a naive port and we're going to get the real stuff with more of the optimizations as well. So there's, there's more money on the table in some cases. And I mean, there's still more for us to do. We're, we're so excited by how everyone else is excited when they hear about this.

• 54:01Wes Bos?

  Yeah.

• 54:03Speaker 02

  It leaked internally to some teams and they, they were immediately like, give it to us.

• 54:07Wes Bos?

  Yeah.

• 54:09Speaker 02

  We want the compiler.

• 54:10Scott Tolinski?

  So, okay, on the give it to us, like, when do you foresee timeline wise, this replacing TSC as we know it?

• 54:19Speaker 01

  It depends on which part of TSC. If you're just talking about the command line compiler, we're pretty, we're pretty close. And we know, for example, I mean, our existing, our, our Go compiler now compiles VS code with, with no errors and it checks everything. I think that we've scraped the top 100 repos. We have to filter them on whether they use JSDoc or JSX because that port is not complete yet.

• 54:45Wes Bos?

  Okay.

• 54:45Speaker 01

  But so we've scraped the top 100 that, that don't and we're burning down all of those. None of them crash. 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. Uh, we have fifty thousand tests that we gradually been, I mean, we're running twenty thousand of them now. Uh, and producing what we call symbol base lines, but we are still working on our type printer. And that means we can't do type base lines exactly identically to how we, we, we did it before. But we can certainly get error base lines going and then start burning down that, uh, that work.

• 55:30Speaker 01

  But we're close, we're really close. I'd, I'd say we're like eighty to ninety percent done and. Amazing. 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 language service, of course, and then there are all of the, then there's the entire tooling ecosystem that builds around our tools. And where we have to, in some cases, come up with a whole new story for how that's gonna work. I mean, our, our existing API, if you will, I'm almost putting it in quotes because the API is effectively, 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. There's the function, right?

• 56:13Speaker 01

  Exactly. And when you can call anything you want, people call anything you want, right? And that means I, our entire implementation is effectively exposed, right? And that's not gonna be the case anymore. Now we're gonna be in a separate process as a native XE that, you know, you can only talk to whatever we expose, right? And so what do we expose and how do we go about exposing that? Because it is also not, it's not in the same process as you, it's in a separate process. And you've got to marshal stuff. And so we got to think about batching instead of the high frequency, you know, API invocations and so forth. Plus, we are.

• 56:57Speaker 01

  Taking this opportunity to re-engineer our language service to use LSP as its native protocol, the language server protocol that pretty much every language service but TypeScript uses, because TypeScript actually predates LSP and was the inspiration for LSP, but we've never done the work to actually adopt it. That we're doing now as well, which makes us more embeddable in a number of situations, 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.

• 57:37Speaker 02

  If we're thinking about like concretely, like actual timelines, we'd like to be able to have something that is at rough parity of the command line compiler without build mode, meaning no project references by, you know, sometime at the end of spring this year. You know, that's aspirational, right? Like we're gonna shoot for it. We can't guarantee things, but like we sure would like to try to aim for that.

• 58:00Speaker 01

  Yeah.

• 58:01Speaker 02

  And then, you know, build mode and a language server with a lot of like core functionality, 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 prom, like this is what we write in every one of our plans, right? It's the same then as it is now. We aspire to do these things. We really wanna aim for that. But hey, like all indicators are pretty good on this so far.

• 58:30Wes Bos?

  Looking good. So maybe could have it in VS Code by Christmas, best case?

• 58:37Speaker 02

  Maybe.

• 58:38Speaker 01

  Probably. You know, we're not gonna make any promises and I also, I, like I said, you know, the, the command line compiler, it's, 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. The new language service may not be exactly, we don't view it, 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? That, and being a different executable and so forth. But there's also, in a sense, a historical gap.

• 59:16Speaker 01

  We are now in the AI era. And a bunch of things we do in the language service, you would do differently today. If you had AI available from the get go. Like a bunch of refactorings that made the way you dream up identifier names, the way you do things. I mean, it's just AI is maybe more suitable there. So a bunch of base level functionality will be the same, but a bunch of the more higher level refactorings and and and quick fixes and what have you. We're going to look at having them be more AI driven, uh, because that is just the right thing to do at this point.

• 59:53Wes Bos?

  Yeah, like something as simple as like removing unused imports or something like that. Is that maybe one that would be better for? I guess that's easy to analyze.

• 1:00:01Speaker 01

  I mean, we, we always have to involve the compiler in in semantically checking that what what happens is correct. Right? But I'm thinking more like, like any refactoring you do that has to introduce new identifier names. 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, you know? Yeah, yeah.

• 1:00:31Wes Bos?

  Does this open us up to any features in TypeScript itself? That you possibly couldn't do before? I know like the, the LSP and and whatnot. Is there, is there anything else where like TypeScript will change because of this new compiler? I know it's, it's such a mature language where like, if you were to ask me, hey, what are we missing? Yeah. Uh, generics on form data, maybe, you know, like not, nothing, nothing like totally crazy.

• 1:01:02Speaker 02

  Well, there, there's a lot of analyses that we, we've often said, well, that's expensive. And, you know, I'm not.

• 1:01:10Wes Bos?

  I don't know, Anders, like you could probably answer this too, but.

• 1:01:13Speaker 01

  Like you say, it's a mature language now. We're more than a decade old, right? Uh, we're and and we have millions and millions of users and we're not just gonna go rock the boat just to rock the boat and do funny things just because it was interesting. I mean, we're gonna obviously track the work that happens in the Ecrascript Standardization Committee. Uh, 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 ES5 and ES6 and then whenever back in, back in the old days where lots of stuff was happening, right? But there's this, like I, I, I keep coming back to, there's this new AI frontier that is, I think, super interesting.

• 1:01:57Speaker 01

  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 consequences? That's, you know, the way I sometimes talk about it is that, what is it that's gonna keep AI honest when you're building agents in this agentic era that we're entering? Well, someone has to be able to check the semantics because, you know, only then do you know that it's verifiably 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, uh, let's see what happens. I mean, that could go horribly wrong. That probably will go horribly wrong, right?

• 1:02:40Speaker 01

  You gotta have some form of verifiability 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 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.

• 1:02:59Wes Bos?

  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?

• 1:03:04Speaker 01

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

• 1:03:38Speaker 02

  Currently, it is sort of a come and build it yourself. 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. 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 really, really early language service extension that we have and just see how fast it builds. And then hopefully we'll make it a little bit easier in the future to get your hands on it and try it out.

• 1:04:13Speaker 01

  Yeah.

• 1:04:14Wes Bos?

  Awesome. I'm really excited about it. So thank you so much. We'll get into the last section real quick of the podcast where we have sick picks and shameless plugs. I don't know if you guys can prepared with either of those?

• 1:04:29Speaker 02

  For the sick pick that I have, it's a tool called, I guess, Pprof and also a tool that we used in JavaScript that someone on our team, Jake on our team, built called Pprof It, which is a really great profiling tool and visualizing tool for leaner profiles. You know, it's helped us optimize the JavaScript codebase, the JavaScript version of TypeScript codebase. And it's also helped us find a lot of great wins as we've ported over the new code as well, because, you know, some allocation stuff is a little different here or whatever. But, but it is given, like told us, hey, You're able to get rid of all the hot paths out of here and now this thing is blazing fast, right?

• 1:05:11Wes Bos?

  This will help you like figure out what is causing performance problems in your Node apps or JavaScript apps?

• 1:05:19Speaker 01

  No, it's just more in our compiler implementation. We've used it in the new command line compiler, the new language service. But yeah.

• 1:05:28Speaker 02

  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. You can also get, 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.

• 1:05:44Wes Bos?

  Cool.

• 1:05:44Speaker 01

  You know, a little anecdote there that it's, I've been writing Go for a long time and you always think, you know, when 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 for surely this is, and then you run a profiler and then it's like, whoa, over there. What the heck's going on over there, right?

• 1:06:09Wes Bos?

  Yeah.

• 1:06:10Speaker 01

  That's actually where the bottleneck is and you, it always surprises you. So profilers in that sense, I think are like, they're just this surprise generator. But then once you listen to them and kaboom, things start going faster.

• 1:06:24Wes Bos?

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

• 1:06:28Speaker 01

  Uh, no, I'll piggyback on the shameless plug there, but, but the sick pic, this is actually, I don't know if it, if this makes any sense, but my, this is a pic that my wife came up with that we've used now. We've used this as gifts to many friends and they all love them. And they're like, USB rechargeable hand warmers. I know this sounds stupid. You buy them for 20.

• 1:06:52Wes Bos?

  No, I'm Canadian. I know all about that. Yeah.

• 1:06:54Speaker 01

  Yeah, yeah, they're awesome. I mean, instead of these chemical things that you have to shake and whatever, and God knows what, how, how good they are for the environment, right? You buy these like little, they're like little bars of soap basically that you recharge and then they go for hours and hours. They're awesome, you know?

• 1:07:13Speaker 02

  I've never heard of this.

• 1:07:14Speaker 01

  Give it to friends to go, "That's the best thing. I put them in my back pocket when I go for a walk and I'm nice and warm the whole time."

• 1:07:20Wes Bos?

  Yeah, there, I've had a couple of friends recommend it because I have a heated vest that I wear often.

• 1:07:25Speaker 01

  Yeah, yeah, yeah.

• 1:07:26Wes Bos?

  Around the house or whatever.

• 1:07:27Speaker 01

  Yeah, uh huh.

• 1:07:29Wes Bos?

  The whole like, being able to produce heat with a battery is, is amazing. I know there's probably a limit to, to how much, but they're great. I should get a pair of these.

• 1:07:38Speaker 02

  Yeah, I usually just use my laptop on a video call.

• 1:07:41Speaker 01

  That's right, yeah. It's getting hot in here, yeah. It's been a long one, yeah.

• 1:07:47Speaker 02

  There's also the shameless plug. I mean, I don't know, Anders, like, is our shameless plug just the new codebase?

• 1:07:53Speaker 01

  Of course. I mean, please, please, go build it. Go, go try it out on your code, see what you think. And ultimately, we're gonna invite you to contribute as well. Uh, right now, though, at 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 this is gonna be an open source project, just like the old TypeScript was, so yeah.

• 1:08:16Wes Bos?

  Beautiful.

• 1:08:17Speaker 01

  Yeah.

• 1:08:18Wes Bos?

  All right. Well, thank you so much for all your work on, on TypeScript over the years, um, to both of you. I'm super excited about this project as well and thank you for all your time coming on and explaining everything to us.

• 1:08:30Speaker 02

  Yeah, thank you so much.

• 1:08:31Speaker 01

  Thanks for having us.

• 1:08:31Speaker 02

  It's been a pleasure.

• 1:08:32Wes Bos?

  All right.