969: This guy is nuts (TypeScript Doom)

Scott and Wes sit down with Dimitri Mitropoulos to explore the wild edges of TypeScript—from running Doom in the type system to building tools like Typeslayer. They dig into Turing-complete types, performance limits, and what the future might hold for TypeScript and programming languages as a whole. Show Notes 00:00 Welcome to Syntax! 00:27 Dimitri Mitropoulos Introduction 01:29 What is Doom in TypeScript? 03:10 TypeScript Types and Turing Completeness 04:06 Project Overview and Challenges 04:57 ASCII Art and Visual Representation 06:50 Performance Issues with TypeScript 09:27 Brought to you by Sentry.io 09:51 Typeslayer Tool Introduction 16:19 Building in Tauri 20:54 Challenges around packaging 24:03 Future of TypeScript and AI 27:40 Is the Go-based compiler significantly faster? TSperf 30:23 Should there be something to follow Typescript? 36:27 Staying up to date with WASM. 37:08 SquiggleConf Overview 38:26 Hosting a conference 40:45 What are your thoughts on Zig? 45:07 Vibe coding as an end goal 50:01 Sick Picks & Shameless Plugs Sick Picks Dimitri: pullfrog Shameless Plugs Dimitri: Michigan TypeScript on YouTube 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:00Scott Tolinski?

  Welcome to Syntax. Today, we have a really good one for you. We have Dimitri Metropolis here. He is the mastermind behind Doom in TypeScript, along with Typeslayer and a bunch of other wizardry, just straight up wizardry. So, we're going to be getting into all kinds of TypeScript topics, but even getting into local meetups and just a lot of cool stuff. Dimitri is incredible. So Dimitri, do you want to give us a little rundown of who you are and what you do?

• 0:32Speaker 01

  Yeah, I'm a TypeScript developer, whether I like to be or not. I've tried so many times over the years to go in other directions, but it's so near and dear to my heart. I've been doing this since the Angular 1.0 days. I used to be diehard on that. Multidisciplinary is the thing that I like to do, so I like trying new things that I've never experienced before. We'll get into it, but the Doom in TypeScript project came out of that. So many of the things that were necessary for that, I had no idea about before I started. And I live in Michigan. Yeah, love the cold weather.

• 1:03Scott Tolinski?

  Hell, yeah. Yeah. You from Michigan originally?

• 1:06Speaker 01

  I sure am. Yeah, I went to Massachusetts for grad school. Well, undergrad. So I have four degrees in things that are not computer science.

• 1:13Scott Tolinski?

  Crazy.

• 1:14Speaker 01

  So, definitely like to learn, but you know.

• 1:17Scott Tolinski?

  Yeah.

• 1:18Speaker 01

  Then I came back.

• 1:19Scott Tolinski?

  I'm from Brighton, Michigan originally. So, grew up in that area. My wife's from Canton. So, we're Michigan people. My parents are still over there. Love to get to Ann Arbor anytime we can. So Doom in TypeScript, for people who may have not seen this, can you explain what the hell that means?

• 1:35Wes Bos?

  This is literally, to preface this, this is absolutely nuts that you did this. And anyone listening should buckle up.

• 1:43Speaker 01

  I wake up sometimes in the morning and I think to myself, like, it's been a year since that was complete, more. And I sometimes think, wake up and I think, I wonder if it's possible. And that's probably the best way to explain it. It's a thing that you would think something like that about. You just like, I had this nagging thought, I wonder if it's possible. And actually, almost, I mean, basically, the entire time, I thought it wasn't possible. So, what's the what? The what is?

• 2:10Speaker 01

  Doom is a game, you know, it shows pixels on your screen. You type, you push keys on your keyboard and things happen inside the game engine. Okay, like abstractly, that's what it is. And TypeScript is, you know, people have to separate type, the type system and the runtime language we call JavaScript. So like, when I say TypeScript, I'm talking about the thing that's running on top of JavaScript, the types. So the, the question is, can Doom, the game, run in TypeScript types? Just the type system? No, absolutely no JavaScript whatsoever. Not a single line. The, the DTS file is zero bytes. Yeah, it's no type, no JavaScript, all.

• 2:49Wes Bos?

  So, so to be clear, this is, this is not you writing like a canvas and running Doom in like, in the browser with JavaScript. The TypeScript, I don't think a lot of people understand this. TypeScript is a language, right? It's not, obviously, it's something that converts to JavaScript, but TypeScript itself, the types, that's its own programming language, right?

• 3:09Speaker 01

  Yes, so the, the type system has been known to be like mathematically Turing complete for many years. And this is something I have a big issue with, actually. So people talk about this concept of like, uh, mathematical Turing completeness. And I think it's baloney. I think, like, imagine I told you, I have this thing and it's Turing complete, except it takes longer than the heat death of the universe to calculate 1 plus 1. Is that interesting? Like, I guess to mathematicians somewhere out there, it's interesting, but to me, it's not interesting.

• 3:41Wes Bos?

  Yeah.

• 3:41Speaker 01

  And I've come to realize, actually skipping ahead to the end, I've come to realize, uh, after I released it, some people educated me a little bit. Doom itself, the game, is Turing complete. Like, there's a way you can set up a level with like, different doors and gates and things that you can make a Turing machine. Um, and so like, actually Doom complete is the better metric, because if it's Doom complete, it's also Turing complete. But we're getting in the weeds. The big picture is, how do you even show, uh, you know, pics, you know, TypeScript is like strings and text. How do you even show it? And so these are the questions that I had in the beginning that I'm like, oh, okay. People say that, you know, oh, it's well, it's Turing complete, so it should be, you know, it can run anything. And I just think that's wrong. I think it's like, it can't run Doom.

• 4:24Speaker 01

  And I thought, all right, I'll find a way to show why TypeScript types cannot run Doom. And that's going to be the project. So I thought it'd be like a two-week project. I didn't think it would be this long, like, year-long, like, section of like, my life. But I thought I would just, I would quickly arrive at the immovable object, you know, the unstoppable force that we would hit to show why it's not possible. And that was the mindset that I started off into this project with, including how to even show it on the screen. Like, that was one of the first things I had to figure out.

• 4:55Wes Bos?

  Man, so, like, what does that even look like for in TypeScript? Where you want to show a pixel on the screen, and you want to write a function?

• 5:05Speaker 01

  Yeah. Well, so, taking the first one, we've all seen like pixel art that's turned into text, like, you know, people call it ASCII art. I've also learned it's not technically ASCII art because you use characters outside of the ASCII 128, whatever. I call it ASCII art.

• 5:21Wes Bos?

  UTF art.

• 5:21Speaker 01

  Yeah, yeah. UTF art isn't as cool. So, people draw pictures with monospace characters. And if you think about it, you know, a monospace character is, the aspect ratio of that rectangle is roughly like two blocks high and one block wide. And so if you take two of those, then you have like a square. Okay? Now, think again, okay, well, like, different things I could put in those two boxes constitute like an average number, like an average color. Like, if you have white text on a black background, there's like an average color. And so like, from there, you can kind of calculate, like, okay, I'm gonna create, like, shades. I'm gonna create pixels of, you know, going from totally

• 6:06Speaker 01

  black, which is just spaces, and totally white, which, like, there's a character that's like a square, and you can just put them next to each other. And then, I'm just gonna create like a gradient in between there. And now I have like, you know, 256 colors, like a grayscale picture, that I can start to draw. If you kind of like zoom out far enough, you can see an image. And, yeah, that's, that's the basic, you know, getting TypeScript to show that is a whole other thing. But yeah, that's the basic idea. And in fact, the first week that I started on the project, like, the first thing I did that I thought, oh, this is not gonna work, was to try to draw a little ASCII art picture. I drew a little heart, actually. Just to see, like, can I, can I control this with types alone? And yeah, the answer was yes.

• 6:47Wes Bos?

  Oh, man. And the I watched it and that was probably what like eight months ago or something like

• 6:55Speaker 01

  Yeah, it was a while ago.

• 6:56Wes Bos?

  Like, how long did it actually take to like compile it? Or like, what does it actually look like?

• 7:02Speaker 01

  Yeah, the final run happened in 11 and a half days. It was actually the night of Halloween. My kids were like, you know, come on, Dad, we gotta like, let's go. And I'm like, Yeah. one, I just want to like, start one. Because by that point, I had run it. I have all the stats. And so I have to say, as a preface to this, I'm been working on it forever, but I've been very busy with other things. But I'll be putting out a video explaining the whole story. It can be like, a very long video. But I had been running it and failing constantly and constantly failing. So like, there were multiple runs that lasted many days before the final one. And I was able to figure out roughly how long it would take. And my my cutoff was a month. I was like, as long as it takes less than a month. I had a computer in my

• 7:44Speaker 01

  basement. And it's like, constantly doing like, running TSC in a loop, doing the type checking. Like, as long as it takes less than a month, I think it's cool. So that was the final run. Took a year and a half leading up to that point, though.

• 7:59Wes Bos?

  Oh, that's hilarious. And with the TypeScript Go, this was before the TypeScript Go stuff, probably by a couple of weeks. But did that speed it up? Have you been able to get it run in the TypeScript Go stuff?

• 8:11Speaker 01

  So I'm sure it would run, because it doesn't use it actually. The funny thing is, people look at it and think like, oh, they must be doing lots of tricks. And there are a couple tricks, but like, not more than five or 10. It's actually like, very simple things built up in like, Lego blocks. For TypeScript Go, it would work. I'm definitely, I have made a promise to myself, I will never touch that project again.

• 8:33Wes Bos?

  It's a closed door.

• 8:34Speaker 01

  It's a closed door. Yeah, like, if somebody else wants to do more than than Doom, like, that's, that's fine. And some people, you know, one of the top questions on the video when I announced it was like, well, how come you didn't show gameplay? And it's like, well, you know, I don't really find that very interesting. Like, the whole point of the project was to really boot the game. To boot, because you know, you gotta think there's like a physics engine. There's like a map drawing system. There's like a sprite system. There's a character. There's texture mapping. There's, there's like item inventory management. There's panels on the screen. There's like, all this stuff had to be encodeable. Sound engine, all had to be encodeable in TypeScript types. And I did that. Like, one frame of the screen is like completely rendered is enough to prove that you did that. And all that it would take to do more is just like letting it continue run.

• 9:19Speaker 01

  But I'm not, if you do 100 frames, someone might say, why didn't you do 101? So it's like, one is perfect enough for me.

• 9:26Scott Tolinski?

  Yeah. 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. Your latest project that just dropped in the YouTube video, we should say, is woefully under viewed right now. It is Typeslayer. It was a really cool, you said it's a Tori app that you put together for all kinds of TypeScript performance diagnostics.

• 10:08Scott Tolinski?

  And this thing is another incredible deep well of just magic. So can you talk a little bit about what Typeslayer is, first and foremost? And then I want to get into like, why does TypeScript performance even matter? Like, why is it something users should care about?

• 10:24Speaker 01

  Totally. Typeslayer is a tool, like you said, for diagnosing TypeScript performance problems. And again, when I say TypeScript, I don't mean like JavaScript. I mean the type system. And it was born directly out of the Doom project. So in order to do that, make that Doom project happen, the hardest part was performance. The hardest part is like, how do you even, it's like a lot of data. It's, you know, like, I think it was like 177 terabytes of TypeScript types in the end. So like, and not all of that was ever stored at one point. You know, it's in memory on my computer and like, I have to clear it and there's like things I had to do. But when I started looking more about how you even go about diagnosing what TypeScript is doing under the hood, it's really hard. I mean, it's prohibitively hard for almost everybody.

• 11:09Speaker 01

  Like, I mean, there's a process where you can generate these JSON files and they're like, could be hundreds of, I was saying hundreds of megabytes until recently, but now I released TypeScript and people are sending me their 5GB JSON files, where they have monorepos with 3000 packages, you know, and they need 80, you know, one person, not 80, it was, they said they need 60 gigs of memory to type check their project. Okay, so that's like, not normal, let's say.

• 11:38Wes Bos?

  How, how big are these, these projects? Because like, we had the TypeScript folks on and they, yeah, they, they told us, like, they're allowed to talk about some of the projects, and then off camera, they tell us about some of the other big projects, that there are like many, many millions of lines of code that takes 60 gigs of RAM to just type check it. Okey.

• 12:02Speaker 01

  Yeah. So, the thing is, that's interesting, and so I've, I've been in the position since I did Doom, you know, like, I have to stress to people listening, it's all fun and games with the Doom project, but what I really hope that people take away from, like, these projects, TypeScript is one of them, personal projects are so, like, so overpowered for creating knowledge that you can apply in a very expert way at work. Like, you just, you cannot, you can, like, definitionally cannot get the experience that would really push you and propel you forward at work, because at work, your job is to take things off the shelf. I mean, you, you should not be reinventing the wheel. But in order to really understand the wheel, sometimes you do need to go into the woodshop and make

• 12:44Speaker 01

  a wheel. And even if it's just a toy, like, you're going to come out of that with knowledge. So, I came out of the Doom project with a lot of knowledge and I applied it at my company, and it was interesting, like, I found problems that solved, like, you know, would take, like, one of them, I took 100 seconds off the CI by basically a five-line fix.

• 13:03Wes Bos?

  Wow.

• 13:03Speaker 01

  And how does that happen? And the reason it happens usually, I think one of the big reasons, is like, You do something accidentally. You you you use some type fest utility or some I'm not trying to pick on type fest, but like you use some abstract TypeScript type level modifier and you don't really realize what it's doing and or maybe it's just not good under the hood. And it creates this explosion of types. You have your like usually there's like a matrix multiplication of two types that creates this like runaway train. And you know, TypeScript has to go do all that work to kind of like figure all those combinations out. And it doesn't show you that, though. It's all under the hood. So like the the thesis with types layer is let's expose the guts. Let's let's show people what's under the hood. Let's

• 13:47Speaker 01

  show people what, you know, you want to see the biggest union in your project like it tells you. You want to see the type that's most frequently the part of the most number of unions, it'll tell you. You want to see like whatever it is, you want to see. And a key thing it also does, the last feature that I'll highlight. We've all seen this problem where you have errors in your code base and it's like, you know, TypeScript has reached an infinite this or that, you know, excessive depth recursion, something, something. And you're like, not sure what to do about it. And you may have at times done a little TS expect error or TS ignore on top of that. Some of us, yeah. I certainly have. So if you work at a large enough company, like a company like,

• 14:30Speaker 01

  you know, like, like Century, actually, I mean, Century has a nice, large, open source code base. Like, if you're in charge of trying to make sure that that code base is is healthy, how would you know if somebody went in somewhere, they got that error, the complexity limit error, that means TypeScript is working really hard on something so hard, in fact, that it gave up, and they ignore it, how would you find it? You can't, there's no way right now. There's no way to find it. Yeah, right. But types layer shows you immediately, like if there's a screen, you just pop in there and it shows you all of the errors of that sort that were hit in your project. And then you could just go to those files and just see what was happening and maybe address them. Because what what people don't necessarily

• 15:11Speaker 01

  know, and that I really want people to understand is when you TS expect error diagnostic, all you're doing is hiding the diagnostic. You're hiding the red squiggly in your editor, you're you're preventing it from stopping on the CI, right? But you're not actually

• 15:25Scott Tolinski?

  Isn't that what we're all after? We're just after removing

• 15:28Speaker 01

  Well, but if it adds 100 seconds, would you change your mind?

• 15:30Wes Bos?

  Yeah, or you need a supercomputer to type check your codebase.

• 15:33Scott Tolinski?

  I'll just get a Mac Studio. It just doesn't matter.

• 15:36Speaker 01

  Mac Studio.

• 15:37Scott Tolinski?

  Yeah.

• 15:37Speaker 01

  So, yeah, that's, that's, so there's more to it, but that's the basis of like what Type Slayer is, is, um, it was actually given, the name was given to me by someone who commented in the, the, the TS, the TypeScript Doom YouTube video. They, they said like, and they call him Type Slayer, cause you know, Doom, I think his, his name is Doom Slayer is the character's name, right? Um, and I just, for a long time had it in my mind, we're like, oh man, that's such a good name, but I'm not the type to have a moniker. What should I do with that name? And then I thought about this. It was like, oh man.

• 16:05Scott Tolinski?

  Yeah, that's, the, the video's a great watch and, uh, I, I was really just kind of jaw gape the whole time. And especially because we deal in such smaller type systems many times here, just that like the types of issues and problems that people are facing. So you built this thing in Tori, which we've talked about on the show before. Tori is a toolkit for building desktop apps using the native browser, uh, that comes like the, the web, in for Mac WebKit. How, how did you find working in Tori? Cause I've built a couple of apps with Tori V2 myself.

• 16:40Speaker 01

  I think it's been awesome. I mean, I wasn't sure if it would work. I mean, there's something that's emerging now that I, I'm seeing more projects do this, like Redwood JS has this, um, I think TurboPak just released something where you run a CLI and it opens up a, a local host tab in your browser to show you some like fancy UI about your app. And I'm, I'm really excited that people are kind of catching on to this idea because I just do not like CLIs at all. I've actually been on CLI teams.

• 17:09Wes Bos?

  Finished recording a podcast, we're like, what's the hype on 2Es? I love, I love a terminal app, but like

• 17:14Speaker 01

  So, you know, I previously worked at Vercel and I worked on Turbo Repo and, um, I didn't do a lot of the work, uh, Chris, my colleague did, but you know, we implemented a 2E in Turbo Repo and a lot of people were very excited about it and I'm happy for them, you know, but can they be happy for me too? I'm not excited about these things. And so I've always been a user of like GitKraken. I've always been, I use like Yak and, um, I used to work on Insomnia, which is, you know, but Yak and Insomnia are both kind of like postman alternatives tools.

• 17:43Scott Tolinski?

  Yeah, Yak is cool.

• 17:44Speaker 01

  Yeah.

• 17:44Scott Tolinski?

  Yeah.

• 17:45Speaker 01

  Um, so, you know, How is it that I, you know, get my job done with all of these CLIs? I have a trouble with it. So what I did is I made this proof of concept called Instant Tari. So you can go MPX Instant Tari anywhere right now and it opens up a Tari app. And it's just a nice little, it's like nine megabytes. Okay, it's not, these are not big apps. And something I think I want to stress to people about CLIs that they may not think about is for websites, we discussed this concept of bundles a lot. We're like, oh, if I, if I, if I bundle the app and you might have lots of other things. So if you, you pull in a dependency that has low dash, but somewhere else had low dash, it's like a negative, it's like a net, net, nothing to add this product that uses low dash.

• 18:28Speaker 01

  But when you have a, a thing like a CLI, all of the node modules come in. It becomes like this, this black hole and, you know, very massive situation. But with Tari, you deliver to your end users a static binary and that's all. They just run the binary. There is no other junk in there. And so it's like nine megabytes for everything. That's very fast to download, much faster than, you know, MPX for, you know, some CLI for node modules.

• 18:55Wes Bos?

  Yeah, yeah, I've, I've gone down the hole of just like bundling node and, and bundling Bun. And it's, at the time it was like 200 megs and I know Bun's got it under 80, I think now, but like nine. You know?

• 19:09Speaker 01

  Yeah. One of the things that was challenging though, I mean, that's, I've, I've liked it. I love Rust, so, um, you know, I have to say that I'm a bit of a fanboy and have been for many years on the, the Rust train. I'll admit that, but that was one of my biggest reasons. Another reason is that there's just stuff that you can't do in the browser. So if you have a tool like, like types layer, that's like shelling out to TSC, uh, you know, TypeScript compiler, or, you know, calling native things on your computer, you just will never be able to do that in the browser. It's like security, like been blocked off for 30 years type of thing. And, um, the alternative is something like Electron, but then now you have, now we're talking about a big thing that you have to install. And worst of all, you're still using JavaScript.

• 19:52Wes Bos?

  Yeah.

• 19:52Speaker 01

  Which kind of stays.

• 19:54Wes Bos?

  Is that the worst of all? We love.

• 19:55Speaker 01

  Yeah, hold on.

• 19:58Speaker 01

  Listen, clearly, clearly, I do too, but I really don't think JavaScript is a good tool for the backend. And I know that's a hot take to some people. I'm sorry for you if you disagree, but like, if you're trying to do multi-threaded things, if you're trying to do, I don't know, there's just lots of situations where, you know, I mean, TypeScript is a good example. Actually, we're talking about this big JSON files. JavaScript cannot hold in memory a string larger than like 600 megabytes. So to get around this, you do streaming and buffers and things. There's, there are ways around it to process stuff, but like, it's very cumbersome. Rust and lots of native languages for, you know, Go or whatever. On the other hand, like, they'll take as much as you have memory. You want,

• 20:40Speaker 01

  you have 64 gig of memory, they'll take 64 gigs of, you know, file in. And so there are just problems that you hit. And I was hitting those problems. Actually, TypeScript was originally written with a node backend, like a nodes, it was a TRPC that I was using. From there, the next problem is how to package it. So Wes, when you did this stuff before, how did you package, like, how did you target Windows and, you know, Apple Silicon and all that stuff?

• 21:05Wes Bos?

  Yeah, that's a good question. It, you just lean on the fact that node runs everywhere, I believe, you know? But that's, you get that absolutely massive bundle, right?

• 21:18Speaker 01

  Yeah, you got to bring in the whole node ecosystem.

• 21:20Wes Bos?

  Yeah.

• 21:20Speaker 01

  Well, the way that, the way that you get around this problem, so you have a problem on your hands, we have a binary. And it's like, a binary is just like a single file executable. And, you know, you can't run a Linux binary on Windows and you can't run an EXE file on a Mac, right? So what do you do? And the trick is, so I publish, TypeScript is the name of the MPM. But I also grabbed the organization @typeslayer. And so if you go to that on MPM, you'll see @typeslayer/linux-64, @typeslayer/ darwin, which is the codename for Mac, you know, arm64, which is Apple Silicon, and, you know, @typeslayer/ windows or whatever, 64, win64. And the way you do it is, this is, I pulled this trick from ES Build.

• 22:05Speaker 01

  In your CI, you build, you have like a runner build each of these things natively. So you have an Apple Silicon GitHub Action Runner. You have a Windows GitHub Action Runner that they're compiling in Windows, compiling in Apple Silicon, whatever. So you're cross-compiling now. And you publish all of those MPMs, those sub-package MPMs, the at-typeslayer ones first. And then if those all complete, and the one that your users actually invoke, you have a little post-install script that is like 30 lines long. It doesn't do a lot. Okay, we're very scared of post-install scripts these days, perhaps for good reason. And you just select the optional dependency of the platform that the person is on.

• 22:47Speaker 01

  So you just try to figure out, you detect their platform, platform.OS or whatever. And then you serve them the right binary. So at that point, they would download the right binary, which keeps you from having to download, like imagine your, let's say your thing is 100 megabytes. Well, like if you're targeting five platforms, if somebody, if you didn't do this trick, people would have to download 500 megabytes instead of 100.

• 23:07Scott Tolinski?

  Yeah.

• 23:07Wes Bos?

  Yeah. Yeah, that homebrew works like that as well, right? You brew installs something and then it will go off and download the actual one that it needs, given that you're on ARM or Intel or whatever.

• 23:18Speaker 01

  So I hope people catch on to this idea. And that's, I'm gonna hope to make, I'm really focused on getting Typeslayer released right now. But, you know, and out to the public, so to speak. It's kind of in a preview. But I really want people, CLI makers, to understand that this is a viable option, that they can pull up an app. And there's lots of apps out there, like even think of something like Webpack type of things, or ES Build, or Bundlers, Linters. Like, how cool would it be if you ran Biome or OXC? And it popped up a window, kind of showing you the files it's looking through. You could sort of see your config and where everything is. Like, you could interact in a much more intuitive way, I think.

• 23:54Scott Tolinski?

  I'm glad that you're advocating for GUIs here, because we just had this conversation. I love it.

• 24:02Wes Bos?

  GUIs are awesome. I do want to talk about the performance of TypeScript a little bit more. And how important that is in the age of AI. Because, like, let's say You have an absolutely massive code base. And part of the way that AI knows what code you want to write is it runs inference on a lot of your functions. And if that's slow, I'm assuming that means that your inference is much slower, your AI is much slower. Do you think that having performant TypeScript so that the AI can just rip through your code base and understand what it looks like is important?

• 24:42Speaker 01

  Absolutely. And I mean, this was one of the biggest motivations for the not. Performance was the reason for TypeScript moving to go, right? But like beneath, you know, as a sub point beneath that, why does performance matter? You know, there's really three things. The first two, everybody's familiar with. Number one is how long it takes to run your CI, right? You're going to be blockaded on your CI by a long type check because you, everybody is going to, you know, want to type check before they'll submit a, you know, premier PR. The second thing is how it works in your editor. Like, you know, we've all had this experience where you're trying to like, you hover over something and it feels like you'd need to go get a cup of coffee before it'll come back, you know? Like, that's a very painful experience and slows you down. The third thing is the new one.

• 25:24Speaker 01

  This agentic programming situation where you have agents going out and doing work on your behalf. And they, just like you and your editor, and just like on your CI, are beholden to the speed at which TypeScript can deliver them back information. And so it becomes a whole new world if the, you know, it's like almost instantaneous loop that you go through. And that's why it matters. And, you know, to some, some projects, it doesn't matter because they don't have a problem. And so I have to stress with a tool like this, you know? You may take your car to the mechanic and they say, it looks fine to me. And, you know, you just need a new oil change or whatever. And that's not a bad result, but for some projects, you really need that oil change.

• 26:02Wes Bos?

  Totally. It's, that's something that I think people don't understand. It just really how big some of these projects are and the huge benefits. And, and also just like the simply how expensive it is to run some of these CI's, you know? Like, if you can cut out, I've, I've heard stories of people just cutting days and days or months off their. Which is is a lot of money if you're paying to keep servers running or having to spin up new servers every time you want to type check something.

• 26:34Speaker 01

  Not to mention the most expensive problem, which is innovation cost, you know, like you're you're suffering all your developers in your company are even if it's not a large project, you know, I think some of the smallest projects need to go the fastest, too. If you can't move quickly, it's a huge issue. And like I said, some projects they don't have a, you know, they pull up types layer and they go, I don't see anything wrong. It's like, yeah, because there's probably not anything wrong then.

• 26:56Wes Bos?

  Yeah.

• 26:57Speaker 01

  You know, it's possible.

• 26:58Wes Bos?

  Yeah, we had Zach on from RS pack. He's making like a Rust version of Webpack and he works at ByteDance, a TikTok. And he's just like, he's like, under, he's like, once things pass, I think he said about 10 minutes. You know, if your CI takes 10 minutes, then people, people click away and they do something else. And that really slows innovation down at the company. So if you can get that, that like, PR under 10 minutes, you put in the pull request, you get somebody to review it, you get the thing approved.

• 27:31Wes Bos?

  If you can do that all in under 10 minutes, then just like the ship fast and break things, that whole mentality we have right now, that becomes doable.

• 27:40Scott Tolinski?

  Does the, does the new go based compiler, though, change the landscape here and how much faster it's going to be? I haven't even gotten to personally really feel that.

• 27:51Speaker 01

  Okay. My personal opinion is it does not. And the reason is over time, these kinds of problems will come up again. Have you heard of this thing where you like add a lane to the freeway?

• 28:05Scott Tolinski?

  Yeah.

• 28:05Speaker 01

  And then.

• 28:06Scott Tolinski?

  He has one more lane, yes.

• 28:07Speaker 01

  Just one more lane.

• 28:08Scott Tolinski?

  Yeah.

• 28:08Speaker 01

  One more lane. And, you know, the types, I think they even talked, in fact, maybe was it you guys that they, that I saw that, you know, the team, the touch of team talking to about this concept, Daniel brings it up sometimes asking, talking about TSGO. I think that in the short term, it's going to relieve a lot of pressure and I think it's going to make open a lot of opportunities. There are things like higher kind of types that are exciting and sort of interesting little tricks you can do in TypeScript that are not super duper feasible. Like, I think Effect has sort of figured it out, but it's not, it's not a great thing right now. But TypeScript Go kind of lowering that upper threshold is going to allow some cool new innovations in. But if you have a matrix multiplication that's creating hundreds of thousands of union members and it takes 10 minutes, but

• 28:53Speaker 01

  it's 10 times faster, so now it takes one minute, but it should be zero seconds because it was just wrong. Like, is that really a win? It is a win.

• 29:02Wes Bos?

  Yeah.

• 29:02Speaker 01

  But what's going to happen is that one minute is going to become acceptable and then like, you know, that's the thing with like the exponential growth.

• 29:09Wes Bos?

  Yeah.

• 29:10Speaker 01

  You know, over time, I don't think it's going to be long before people are like, oh, TSGO is so slow. It's like, yeah, because I think that's why it's important to make, like, I think that's what's exciting to me about a tool like TypeScript and other tools. There's actually others. There's a TS perf org that was kind of created. There's a, there's a tool called Atest by this guy David Blass. Atest does like a little bit of this, like trying to tell you information about how slow your tests are and like the types in your tests are and it kind of measures this with the TypeScript compiler or API. So as we get more visibility, then we can start to see like solutions come about and people, like, I think a lot of libraries don't know too, is another thing. Like, I've had library

• 29:53Speaker 01

  authors this week contact me and say, I had no idea. I had no idea that I was doing this thing that, you know, in a user's codebase is causing problems. And this is a big issue that library authors have in general. If you think about it, like, in your library's code, it doesn't use your library most of the time.

• 30:10Wes Bos?

  Yeah.

• 30:11Speaker 01

  So how do you know how well it works? Like, you have your tests, you know, so it's like, you can play with it in your tests.

• 30:16Wes Bos?

  People using it in a weird way that you didn't expect it and all of a sudden, boom, this thing is, is crazy big. Well, here's a question, is...

• 30:26Wes Bos?

  You obviously love different programming. You're not like a JavaScript lover.

• 30:32Wes Bos?

  Should like, should and will there be something after TypeScript? Should there be something new? And if so, what would that look like?

• 30:40Speaker 01

  I'll shout out my friend Dan Vanderkam. I got his book behind me here, Effective TypeScript. Dan and I were talking the other day, and he said something that I just could not, I cannot get out of my head. And I was, so I said to him, I just hope that TypeScript is not the last language. I hope that Rust is not the last language. Like, I hope that, I hope that this continues. And I don't, I don't want TypeScript to be the only thing forever or anything. And he said to me back, I think we know the last language. And I was like, what is that? He said, English. And I think like, I don't know, I didn't know what to make of that when he said it, but it was very, I don't know. I don't, I'm not on social media. Maybe this is like not interesting and people say this all the time.

• 31:17Scott Tolinski?

  No, I don't know if they do, but I, yeah.

• 31:20Wes Bos?

  Is that like an AI thing? Or is that what you're getting at here?

• 31:22Speaker 01

  Yeah, that like ultimately, ultimately, you can imagine, you know, five years from now, we might not be, just like, we don't work with machine code a lot. Just like we don't work with assembly a lot. Just like, it's just like, the level of abstraction, if you look back over the last, like, you know, 100 years of us trying to mechanize things and, you know, through computer science.

• 31:44Speaker 01

  I don't know anything about metallurgy, right? But that doesn't stop me from being able to use a computer. I don't need to know anything about metallurgy. And as you keep going higher and higher in levels of abstraction, like, where could that, like, if you think of the logical conclusion of that, where, where does it end? I mean, I guess, actually, not English. It ends with like a thing that I attach to my head that reads my thoughts. Maybe that's the last programming language, actually.

• 32:04Scott Tolinski?

  Yeah, right. You think about this all the time, but back when we were first learning how to program, like, everything felt like, ah, why does this abstraction, like, why is there so much friction in learning this, this syntax or this abstraction when I can express things more clearly through English?

• 32:24Speaker 01

  One of my, one of my favorite takeaways from the Doom project is, a couple of people complained, and one guy really went far with it, that they were like arguing, I think it was on Reddit, because there's a lot of arguing on Reddit for some reason.

• 32:35Scott Tolinski?

  Of course, yes.

• 32:36Speaker 01

  And Someone was saying, "It's all in TypeScript types." And this guy responded back, "It's not possible that it's all in TypeScript types." There is a JavaScript function somewhere because Doom is running in C. And, uh, you know, C has a main function and something somewhere has to call the main function. And I just love that this guy said that because I thought the same thing. I mean, there was a day when I was like, "Yes, but, you know, Doom has a main function." And I don't have a, how am I, you know, it's like, how does that even work? That's like, there's no, that's the beginning point of your program. You can't go deeper than the main function in C. That's like, that's where it starts. It turns out, the main function is an abstraction too.

• 33:17Speaker 01

  There is stuff beneath the main function, but you don't, as a programmer in C, get access to that. But, but there are things in there. There, there is like, there is stuff going on. And if you get in there, and I had to do this, you know, and learn, how does that actually work? How does that abstraction? Like, there was a day when I was looking around like, "Okay, so I have this like abstract definition of a computer that can run a thing." How do I turn it on? How do I power up my TypeScript type computer? And I had to create a, like a thing that would kind of like boot the computer. There's, there's a bootstrap initialization routine that at the very beginning of the, of the thing will like, start the computer. And it does the thing that the main function does. It like sets up the first arguments that you're going to pass to the first function.

• 33:59Speaker 01

  And it like gets memory initialized and it like does all the stuff to like turn on the computer. And it's just very eye-opening to me because like that guy, I mean, I also, I relate to him so much, you know?

• 34:12Wes Bos?

  Yeah, somewhere it's a, a voltage spike that's starting all of this, right?

• 34:16Speaker 01

  Exactly. Yeah, yeah.

• 34:20Wes Bos?

  Oh, that's, yeah, that's, that's a, that's a good way to think, you know? Just, just peeling it back, all these different layers. But then, uh, uh, at the same way, like we, I often think about like, will there be another TypeScript? And I don't think so. I think that's there's not going to be like a better typescript that everybody moves to. There's going to be another abstraction level that sits on top of it that we all all use. And then you can do consulting for all these old legacy typescript systems.

• 34:50Speaker 01

  I mean, if it's anything, it's I would say it's probably Wasm. I'm definitely very big on the Wasm train type. We, you know, we didn't get into the architecture, but the the Doom and typescript types project was done by making a Wasm runtime. And actually, the it can run other things. So a couple of people have told me, you know, Dimitri, you really sold yourself short here by just talking about Doom so much. You built a full WebAssembly runtime in types of types that can run.

• 35:13Wes Bos?

  Oh, my God.

• 35:15Speaker 01

  It can run other programs, too. I just, you know, because of my mindset, I never thought Doom would be possible. And so like, people have asked me, why did you go from nothing like this ever having been done, not even close, to like, all the way straight? You drew a straight line to Doom. You didn't do like, you could have done Tetris, and then like Pokemon, and you could have built up in smaller pieces. How did you go from nothing to Doom? And the reason is because I didn't think it was going to work. So like, if your mindset is, I'm going to find the thing that breaks all of this, why would you play around with with Tetris, or Pong, or something, right? You just go straight to the thing that's going to be the hardest to show why it would fail under pressure. And so like, WebAssembly has a lot, I think, to offer. And there were reasons in the past not to use it. But in

• 35:57Speaker 01

  this past October, we had a release where WebAssembly got a lot of stuff added to it. It has 64-bit memories, multiple memories. You can do things that you like were completely infeasible before, shared shared processes and other things, exception handling. And I think that the the cat is out of the bag now. WebAssembly is ready for you. Imagine, you know, a thing like Photoshop being, you know, delivered in a WebAssembly format. It's it's ready for that now. It's just a matter of people adopting it, I think.

• 36:27Scott Tolinski?

  Where do you go to stay on top of the Wasm stuff? Because it feels like such a mysterious well for someone.

• 36:34Speaker 01

  I have a bad, I have bad news for you. The only thing that I used was the, was the spec. And it's written with like, you know, fancy functional programming characters that show you ways to apply things. I just did it instruction by instruction and I wrote lots and lots of tests. How I heard about that is actually because, you know, I run this thing SquiggleConf is a conference for dev tools we can get into. But one of the speakers came this year and talked about, we like to have people come and talk about WebAssembly. So one of the speakers came and talked about that. And that's where I learned more about some of these things. Yeah.

• 37:08Scott Tolinski?

  Yeah, let's talk about SquiggleConf because that's like a, one of the comps that I always see pop up as being like, wow, I gotta, I gotta make it to SquiggleConf.

• 37:16Speaker 01

  Oh, yeah, thank you. We'd love to have you.

• 37:17Scott Tolinski?

  Yeah. Oh, yes. Let's do that.

• 37:19Speaker 01

  How it, how it began is I have a meetup that I've been running here in Michigan, Michigan TypeScript. There are a bunch of us here taking charge of it. And if you're from Michigan, it used to be called SEMJS, Southeast Michigan JavaScript. But, uh, you know, we don't write JavaScript anymore, so we got a little refresh. And I had this guy Josh Goldberg come out. Josh is the, well known as the maintainer of TypeScript Island. And so I pick up Josh in the car from the airport to come speak at my meetup. And, uh, it took, it took like 10 minutes before he and I were both like, why is there not a dev tools conference? Why is there not a conference for people who are just interested in tooling and want to share and like cross pollinate, populate ideas about tooling? And he came and did his talk. It was very cool, you know, very good talk.

• 38:03Speaker 01

  And, uh, it kind of stopped for, you know, kind of that was the end. And over the next couple of months, we kept in touch. We kept talking to each other more. And one day Josh came to me and said, dude, let's just do it. Let's, let's just do it. Let's just make a conference. Let's start it. Nobody else is, nobody's going to do it. We kept waiting for somebody else. And so, uh, yeah, SquiggleConf was born.

• 38:26Scott Tolinski?

  That's amazing. How has that process been throwing a, that seems like something that I never, ever would want to get into.

• 38:32Speaker 01

  That's terrible. It's like a hard thing to do. Do not recommend. Um, yeah, it's, it's, uh, it's very, it can be very soul crushing. It could be very uplifting. It can be, there's lots of ups and downs. You know, these days people, I guess it wasn't like this before the pandemic, but I, it's apparently very, very common for people to wait until the week before, the day before, like right before the conference to buy their ticket. You have to imagine, you know, we published all this about our, we're 501(c)(3) and we have open books, so people can see what we, you know, spent, but like, you know, you're talking about losing potentially tens of thousands of dollars in a single year if people don't show up. And it's very scary to do that. You know, you're flying speakers from all around the world. You know, it's, it's a lot of logistics and coordination,

• 39:17Speaker 01

  and you want people to have a good experience. You know, there's lots of ways that a conference can go, you know, go poorly, and there's only a few ways that it can go excellently. So you have to really make sure that you keep it on, you know, keep the train on the tracks and make sure that everybody has a good experience. And you can't do everything right, but we try to make sure that the core deliverables are there and, you know, people have a great experience. And it's a cross-language conference, too, which is something that's fun for us. Because, you know, like I said, I worked on Turbo Repo. Okay, well, Turbo Repo is a tool, or RSPAC for that matter, right? These are tools written in Rust that target JavaScript. But where does a person go to talk about that? What conferences do you submit to? Because if you go to a JavaScript conference, well, like, you can't talk about any of the cool Rust things that you're doing, because it's, they're, it's not, they're

• 40:02Speaker 01

  not that language. If you go to a Rust conference, like, they don't want to hear about JavaScript at a Rust conference. You know, like, they're not interested. So there's a home here at SquiggleConf for these kinds of people. And every year, we've had people from, you know, representation from Go and Zig, and, you know, this past year, we had someone from Glean. Like, he was so excited. He's a, you know, he works on this boutique language that not a lot of people are using yet, because it's still a smaller language. And he had this thing that they figured out how to do with their snapshot testing. And they just really wanted to share, like, other languages could do this exact same thing. There's nothing Glean-specific about this. But where can he go? They're not big enough to have a conference of their own. And I just love the idea of having a platform for people to share these ideas and, you know, get together.

• 40:43Scott Tolinski?

  Yeah. Yeah, that rules. What do you, quick, quick, quick hit. What are your thoughts on Zig?

• 40:50Speaker 01

  I think Zig is, I've used Zig only for like cross compilation stuff. It's like freakily good at that for some reason. I'm really happy that Zig exists, but I also kind of wish that it didn't. I don't, I don't have any, I think Zig is way cooler than JavaScript for that matter. Like, I'm, I'm all, I'm all right with it. It's not like a problem, but I do get a little bummed when I see, there's like a trauma that comes with being a long-term JavaScript developer. Where like, you see JS lint, and then it becomes JS hint, and then it becomes ES lint, and then it becomes TypeScript ES lint, which never even really merged, and it was like a whole thing. Or yeah, we skipped TS lint in the middle. Okay. And then it becomes like biome and OXC. I mean, we're, we're talking like, the

• 41:33Speaker 01

  wheel just keeps being reinvented over and over. And I feel so bad for people who poured out all their energy and effort to making a tool that only was really used for two or three or four years.

• 41:43Wes Bos?

  Yeah.

• 41:45Speaker 01

  And that's kind of the way I feel about like, languages in general. I think small languages are cool, but I don't think there should be that many, like, I think like Rust and Go have definitely carved out a home for themselves. Zig is a weird intersection of, of all the things that are nice about Go and all, and some of the things that are nice about Rust. And maybe that's what makes it strong, and that's why people love it so much. But I've never written much, I've written 100 lines of Zig, you know, and I didn't, haven't done much. But I do worry about like, the, it is natural and normal. There's like a natural selection process that happens with languages. But as we've seen, it's not always the best language that wins. It's, sometimes it's the one that's

• 42:30Speaker 01

  the easiest to get started in.

• 42:32Wes Bos?

  Yeah.

• 42:33Speaker 01

  You know?

• 42:33Wes Bos?

  That's, that's why JavaScript is so big, right? It's, it's definitely not the best language.

• 42:38Speaker 01

  Can I tease, can I tease something for you?

• 42:40Wes Bos?

  Yeah.

• 42:41Speaker 01

  Yes, yes, please. There is a secret that I would like to expose in the JavaScript world, and I'm gonna, I'll, I'll expose it now. Expose it, yes. But I, but I wanna, I'm gonna make a video with this. I'm, actually, I was talking to, I won't say who, but I was talking to someone you'll, you'll all know about coming out and doing a video with this. JavaScript 1.0 is well-known to have been kind of like, quote unquote, written in seven days. I don't think, I got curious one day and I spent way too much time finding a, I booted a Windows 95 VM, which is really hard to do on modern hardware, by the way. I thought it would just be like you open up VirtualBox and get the image. No, it is challenging. Then I went even farther to connect it to the internet,

• 43:22Speaker 01

  which you need like Netscape Navigator version 2.001 Gold or something. And I found like the first version of Netscape that shipped with the first version of JavaScript. And I booted, and of course, like no web page runs. Like I think example example.com I could get to come up because it's got like, you know, one HTML tag. But the point was, I wanted to see what I could run in JavaScript, to see like, what is JavaScript 1.0 really like? Like, what is this thing that we've all heard was written in seven days? And can I tell you? There is almost nothing there. It did not have arrays. It did not have, yes, it does not have undefined. It doesn't have exceptions. It doesn't have like,

• 44:03Speaker 01

  it doesn't have lots of things that we think of as being completely core to the language. It doesn't have first-class functions. You can't pass a function to another function. There's, it's, there are so many things that are like absolutely critical to everything. It doesn't have switch statements. It is like, what it was in version 1.0, if you actually go and use it, was actually very close to nothing. I'm not trying to throw shade. I think it's, it's actually awesome that it started at such humble beginnings. But I think like, it's really cool to like, so I got a whole dev environment going up where you have like notepad open, because of course there's no like ID. It's amazing. And you can like run, I got the loop working where I could like save it and like run the file and we could see what happens.

• 44:40Speaker 01

  And there are just so many, like, you know, instead of arrays, what did they do? Well, you know, you, you have objects. So, uh, and there wasn't, yeah, the, the object syntax is like missing. But anyway, you just put like a key, like you want zero, you just add a key of zero. That's technically how arrays still work. So yeah, it's it's interesting. So yeah, that's a that's a fun thing I hope to do on a on Michigan typescript in the future is a little video highlighting that just for fun.

• 45:07Wes Bos?

  I got one more random question. I don't know if this this will be good enough to make it in, but you seem like a pretty smart guy. We seem to love learning and going in getting into the weeds. I'm curious if you have any thoughts on people who are are just using AI to poop out all of their code right now and not continuing their skill set into learning more things.

• 45:31Speaker 01

  I'm good with it. I think, yeah, I think this industry has grown so much in the last 10 years. And I think that most of us who have been doing it for a couple of years have worked with someone and you you've had the thought about them that like, do you really love this? Or you just did this because somebody told you you would make a lot of money?

• 45:51Wes Bos?

  Yeah.

• 45:52Speaker 01

  And I think that like, in the long term, I don't know if we need more software engineers than we have now. I think we need software engineers to be more capable. We need more like, so I look at AI as a capability enhancer. It allows me to do things like, Type Slayer has a problem with, I don't know, it doesn't work with Glib C version 2.39 and below because there's some Linux thing. I deeply do not care about learning.

• 46:16Wes Bos?

  Yeah, right. Yeah.

• 46:17Speaker 01

  Yeah, I really don't want to do that. And I'm not someone like, as evidenced by the doom thing, like, I will take the time to learn things if the situation arises. It's not like that. But I think that sometimes we don't have the power to pick and choose. And I also like that it gives you a chance to to learn things that are outside of your range. Like, you can, if you want to learn a new language, but you don't know somebody who knows that language.

• 46:41Wes Bos?

  Yeah.

• 46:42Speaker 01

  How do you, even like, human natural languages, right? It's the same way. Like, if you don't have someone to speak with, it's going to be really tough. You know, it's only so much fun with Duolingo in the closet, right? You know, sitting in the dark with, you know, so I think if you can come out into the open world and And engage, it becomes a little easier and AI gives you that opportunity. I think there are a lot of ways in which it's made life worse too, that I think we're starting to see now. You know, if anybody who's trying to build a computer right now, um, you know, there, you know, crucial, for example, that, you know, they just said, we're not making RAM for consumers anymore. Tough luck.

• 47:15Scott Tolinski?

  Yeah. Samsung is stopping their SSD for consumers, not their NVM or whatever, but their SSD.

• 47:23Speaker 01

  Yeah. So I think that there is going to be some bumpy, you know, some turbulence in the meantime, and I, we all need to be ready for that. The, the job market side, I just left a previous company and I'm, you know, going to my next one in January, which is the window that I had to, that's why I'm doing types layer is I had a little like couple of weeks here to, what, what can I do at this time? But in that process, I've, I've learned a lot about like where the industry is at right now. And, um, there's like strange levels of desperation at the same time as, um, you know, I think it's like more aloof. Employers are more aloof than they used to be for hiring. It's like less of a priority now. And I think that we're going to find out that there's a lot that AI can't do.

• 48:06Speaker 01

  Actually, advanced TypeScript types, uh, Tomfoolery is something AI is totally terrible at. It is horrifically bad at like type level programming, like of the sort that the Doom thing was made with. But, you know, um, so we'll see. I, I think that can be improved, but looking at the long picture, you know, I read this, uh, the singularity is near when I was a kid. I don't know if you heard the rake hurts wild, this like.

• 48:32Scott Tolinski?

  Yes, the singularity is near and, uh, the age of virtual machines. I think that I read the age of spiritual machines when I was in high school and I think that book completely changed my mind, like completely blew my mind at the time. But it was like, at the time that all felt so abstract that by the year 2040, things would be like this. And now that things are actually becoming like that.

• 48:53Speaker 01

  It's gonna be before 2040.

• 48:54Scott Tolinski?

  I'm like, this is scary as hell. Yeah. I was like, you know, when it was so abstract and far away, it was all like, this is magic. And now it's like, oh my God, it's overwhelming.

• 49:05Speaker 01

  Yeah. And so I think like as, as time goes on, we're going to see how things level. But this is definitely a weird time to be a software engineer in this century, um, you know, and. I'm not sure exactly where it's headed, but whatever it is, I don't, I'm not, I don't feel threatened by AI because like then like my job is to just become very attuned to harnessing it, so to speak.

• 49:28Scott Tolinski?

  Yeah.

• 49:28Speaker 01

  And it, it becomes a thing that I'm like, I, I'll always stay on top of it, you know, like I have to, so it does put pressure on us, but you know, I'm a JavaScript developer. We got things changing all the time, every, you know, all the time everywhere. Anyway, like I, I can imagine that, you know, other industries like Java developers and stuff where there's like less turmoil or Rust or Go or any other language, they're probably not as used to the amount that they have to kind of like keep up.

• 49:54Scott Tolinski?

  Yeah.

• 49:55Speaker 01

  That, you know, they're gonna have to, they're gonna have to learn, they're gonna have to learn to keep up.

• 50:00Scott Tolinski?

  Beautiful. Well, now's the part of the show where we get into sick picks and shameless plugs. A sick pick is just anything you're loving in life, enjoying, could be anything, podcasts, physical item, who knows what, TV show, whatever. And then a shameless plug is anything you just want to plug.

• 50:17Speaker 01

  What I'd like to plug is this guy Colin McDonald, the Zod founder, and David Blast, the archetype founder are working on this thing, PullFrog, to, you know, it's like coding agents in GitHub. They also have Andrist, who's a well-known TypeScript contributor. And I think it's really cool to see the stars align and see these guys getting together. You know, Zod and archetype are kind of like, like direct competitor products and they're both super, super smart. I, I've, you know, gotten the chance to know all of, all three of them and it's been really cool to see them doing it. It's a, you know, we'll see what comes of PullFrog. It's, it seems to be, it seems to be pretty exciting to see all these tools. Like maybe you've used Devin or, you know, these other agents that can kind of review your PRs for you.

• 50:59Scott Tolinski?

  Yeah.

• 50:59Speaker 01

  I, I think it's a cool space to be in. Yeah.

• 51:03Scott Tolinski?

  Yeah.

• 51:03Speaker 01

  I didn't realize they were working on that.

• 51:05Scott Tolinski?

  I've been seeing this, yeah, come together.

• 51:07Speaker 01

  You should have mine.

• 51:07Scott Tolinski?

  Following it. Yeah. No, that, and, and I'm honestly, to even just talk about archetype, that's a really cool project.

• 51:12Speaker 01

  David also, yeah, I mean, if I have an honorable mention, David released this thing, Arc Rejects, which is like doing. That's also nuts. Yeah. He is, he is, you know, David helped me actually. David never committed a line of code on. Doom, but I have a T-shirt and his signature on it with the Doom project because I was super stuck in the mud. And he sat down with me for 45 minutes one night and just like told me how to do it, how to, how to make the machine chug.

• 51:39Wes Bos?

  Yeah.

• 51:40Speaker 01

  That guidance from him was so critical to making the project happen. So I, I think without him, it probably would have failed just on my own abilities. So Arc, Arc Rejects is a crazy project because that's like, you know, reject, reject is are like famously very complicated things to do. And making a type safe reject parser purely in TypeScript types, uh, you know, I was like, well, it does both, right? So it's a drop in replacement for reject. It's just super cool. So.

• 52:04Wes Bos?

  It's so nuts. I can't believe he built that. Yeah. I, I gotta look at the code behind this thing. Cause it's probably gnarly.

• 52:11Speaker 01

  It's not. Yeah. No, David, David has a, he has a little different style, I think, but, um, he's, it's like very meticulous code. Like he's not a scrappy in the sense of like, uh, he'll get stuff done, but the code is very, is very thought. It's like very thought out, you know, you can tell someone put effort into it. He's a craftsman, you know, he's, he's a software craftsman.

• 52:33Wes Bos?

  And the type of person that needs to take on a project to parse a reject.

• 52:37Speaker 01

  Yeah. That's who you want. By the way, you really want, you really want a software craftsman to make your reject library, right? It's like very important. You get the right kind of person on that job.

• 52:46Wes Bos?

  Holy smokes.

• 52:48Speaker 01

  Um, I'll give a plug to, um, so all this time we're talking about the doom thing. I, I just, the year got away from me and squiggle conf took over a lot of time. But on Sunday, January 4th at 1:00 PM Eastern, uh, I'll be doing a deep dive with Dylan Mulroy, a friend of mine.

• 53:04Wes Bos?

  Yeah.

• 53:05Speaker 01

  The, uh, you know, Dylan? Yeah.

• 53:06Wes Bos?

  Yeah. Yeah. He just started over at Cloudflare, right? He was also a Versale, the Cloudflare guy.

• 53:11Speaker 01

  Yeah. Yeah. So yeah, Dylan and I will be, will be working alongside each other again. It was gonna be awesome. But yeah, Dylan, uh, and I are going to go through soup to nuts, top to bottom, the entire doom code base. Like how does everything work? It's going to be at least three hours long and, um, you know, most people I think don't care and won't be interested. But I think for like historical purposes, while I still kind of have it in my mind, it's cool to show people all the different things that had to be. Put in place all the chips that had to be stacked in order to make it happen from a very, very technical level. So we're going to be, we're going to be looking at memory addresses from the first 10 minutes. Yeah.

• 53:45Scott Tolinski?

  Is that going to be on the Michigan TypeScript YouTube channel?

• 53:48Speaker 01

  Thank you. Yeah, I didn't even say where. Yes, Michigan TypeScript on YouTube. We'll, we'll be live streaming it there. Yeah. So look, look to that January 4th. Yeah, it'll be, it'll be cool.

• 53:58Scott Tolinski?

  Yeah, man, it's so cool to see Michigan TypeScript quote unquote on the map here. Like as somebody who attended that meetup before it was Michigan TypeScript for like so long, like it's really cool to see.

• 54:09Speaker 01

  We never intended to make it a YouTube channel, really. What happened was we were just recording the talks and we put them online and someone gave a talk about how much they hate Enums and that talk just like blew up.

• 54:19Scott Tolinski?

  Yeah.

• 54:19Speaker 01

  And suddenly, you know, all the TypeScript people started making videos about it as a result of that. And we got thinking like, oh, this is kind of cool. We should do more stuff like this. And it kind of ballooned. Now we're 400 videos in.

• 54:30Scott Tolinski?

  Hell yeah. Shout out to the Michigan web dev scene overall. Thank you so much, Dimitri. Man, you are just a

• 54:37Speaker 01

  Awesome.

• 54:37Scott Tolinski?

  A delight in all facets of the word. You're, you're so sharp. So we got to have you on again sometime. I feel like we could ask you a billion questions and just, just nerd out on some stuff. So thanks so much for joining us. It's been, it's been awesome.

• 54:51Speaker 01

  Thank you. Yeah, it's been a pleasure.

• 54:53Scott Tolinski?

  Thanks.