This guy is nuts (TypeScript Doom)

Welcome to Syntax. Today, we have a really good one for you. We have Dimitry Metropolis here. He is the mastermind behind Doom in TypeScript along with TypeSlayer and a bunch of other it just wizardry, just straight up wizardry. So we're gonna 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 wanna give us a little, rundown of who you are and what you do?

Yeah. I'm a TypeScript developer, whether I like to be or not. I've tried so many times over the years to, you know, go in other directions, but it's so near and dear to my heart. I've been doing this since, like, the Angular one point o days. I used to be die Yarn on that. Multidisciplinary is is the thing that I like to do. So I like trying new things that I've never experienced before. That's we we'll get into it. But the doom and type project came out of that. Like, 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. Hell, yeah. Yeah. Yeah. Are you you from Michigan originally? I sure am. Yeah. I went to Massachusetts for grad school. Sanity well, undergrad. So I have four degrees in things that are not computer science. Crazy. Yeah.

So it's like, definitely like to learn, but, you know Yeah. That's Yeah. Then I came back. I'm from Brighton, Michigan originally. Oh, cool. So grew up in that area. My wife's from Canton. So we yeah. Very 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?

This is literally to preface this, this is absolutely nuts that you did this, and anyone listening should, like, buckle up. So go ahead.

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 it's 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 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 is zero bytes. Yeah. It's no type no JavaScript. All So Scott to be clear, this is this is not you writing, like, a canvas and running Doom in, like, in the browser with No. Like, 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 to JavaScript, but

TypeScript itself, the types, that's its own programming language. Right? 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, 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 one plus one. Is that interesting? Like, I guess to mathematicians somewhere out there, it's interesting. But to me, it's not interesting. Yeah. And I've come to realize actually, skipping ahead to the end, I've come to realize, after I released it, some people educated me a little bit. Doom itself, the game JS 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.

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, you know, pick you know, TypeScript are just 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. And I thought, alright. I'll find a way to show why TypeScript types cannot run, Doom, and that's gonna 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 the the immovable object, you know, the 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.

Man. So, like, what what does that even look like for in TypeScript Wes you wanna show a pixel on the screen and you wanna write a function?

Wes, so taking the first one, we've all seen, like, piss like, pixel art that's turned into text. Like, at 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. Yeah. Yeah. Or UTF art isn't as cool. So people draw pictures with with monospace, characters. And if you think about it, you know, a a monospace character is the the 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, you have white text on a black background. Yeah. 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 black, which is just spaces, and totally white, which, like, there's a character that's like a square. 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 gray scale 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 Wes 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.

Oh, man. And the I watched it, and that that was probably, what, like, eight months ago or something like that. That was what I got. Like, how long did it actually take to,

like, compile it, or, like, what does it actually look like? Yeah. The final run happened in eleven 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, I just want I just wanna, like, start Node. Because by that point, I had run it. I have all the stats. And so, I have to say JS 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'd be 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 Node. 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 basement, and it's, like, constantly doing like, running TSC in a loop doing the type checking. Like Yeah. 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.

Oh, that's hilarious. And with the TypeScript Go, this was before the Type Script Go. So probably by a couple of weeks. But did that speed it up? Have you been able to get it run-in the Type Script Go stuff? 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, it 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. Yeah. You know? It's a closed door. Yes. It's a closed door. Yeah. No. Like, if somebody else wants to do more than than Doom, like, that's that's fine. And some people you Node, 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 encodable. Sound engine all had to be encodable in TypeScript types.

And I did that. Like, one frame of the screen JS it 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. But I'm not if you do a 100 frames, someone might say, why didn't you do a 101? So it's like one is perfect enough for me. Yeah.

And if you want to see all of the errors in your application, you'll want to check out Sanity at century.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 to reduceentry.io/syntax.

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

Your latest project that just dropped in the the YouTube video, we should say, is willfully underviewed right now. It is, TypeSlayer. It was a really cool, you said it's a Tori app that you you put together for all kinds of TypeScript performance diagnostics, 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 wanna get into, like, why does TypeScript performance even matter? Like, why is it something users should care about? 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 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 Wes, like, a 177 terabytes of TypeScript types in the end.

So, like and not all of that was ever stored at one point. You Node? 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 it's prohibitively hard for almost everybody. Like, I I mean, there's a process where you can generate these JSON files, and they're, like, could be hundreds of of I was saying hundreds of megabytes until recently, but now I release TypeSlayer, and people are sending me their five gigabyte type of JSON files, where they have monorepos with 3,000 packages, you know, and they need eight you know, one person, not 80. It Wes, they said they need 60 gigs of memory to type check their project.

Okay? So that's, like, not normal, let's say. How how big are these these projects? Because, like, we had the tech 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, but they're, like, many, many millions of lines of code that takes 60 gigs of RAM to just type check it. Yeah. Okay.

Yeah. Yeah. So the thing is that's interesting. And so I've I've been in the position since I did Doom. You Node? 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 a like, these projects, Textlayer 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 Totally. 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 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 a wheel. And even if it's just a toy, like, you're gonna 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 a hundred seconds off the CI by, basically, a five line fix. Wow.

And how does that happen? And the reason it happens usually, I think one of the big reasons JS, like, you do something accidentally. You you you use some type Wes 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. Mhmm. 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 kinda, 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 TypeScript is let's expose the guts. Let's let's show people what's under the hood. Let's show people what, you know, you wanna see the biggest union in your project, like, it it tells you. You wanna see the type that's most frequently the part of the most number of unions, it'll tell you. You wanna see, like, whatever it JS, you wanna 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.

But So did you get it? Yeah. I certainly

have.

So if you work at a large enough company, like a company like, 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 you can't there's no way right now. There's no way to find it. Yes. Yeah. You'd yeah. Right. But TypeSlayer shows you immediately. Like, the 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 can just go to those files and just see what was happening and, maybe address them. Because what what people don't necessarily 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 Isn't that what we're all after? We're just after removing the red squiggly? But if it has a hundred seconds, would you change that? Or you need a supercomputer to type check your code base? I'll just get a Mac Studio. It just doesn't matter. Yeah. Mac Studio. Yeah. So, yeah, that's that's so there's more to it, but that's the basis of, like, what TypeSlayer is is, it was actually given the name was given to me by someone who commented in the the the t s the TypeScript doom YouTube video. They they said, like and they call him TypeScript because, you know, in Doom Yeah. I think his his name is Doom Slayer is the character's name. Right? Yeah. 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 feel about this. And I was like, oh, man.

Yeah. That's a the the video's a great watch, and, I I was really just kind of jaw agape 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, that comes like, the the web in for Mac WebKit. How how how did you find working in Tori? Because I've built a a couple of apps with Tori v two myself.

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. I think TurboPack 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 CLIs. Finished recording,

podcasts. We're like, what's the hype on TUI's? I love I love a terminal app, but, like So

are good. I previously worked at Vercel, and I worked on Turborepo. And, I didn't do a lot of the work, Chris, my colleague did. But, you know, we implemented a two e in Turborepo. 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, Yac, and, I used to work on Insomnia, which is you Node, but Yac and Insomnia are both kinda like Postman alternatives tools Yeah. Yac is cool. Yeah. Yeah.

So, you know, how is it that I, you know, get my job done with all these CLIs? I I have a trouble with it. So what I did is I made this proof of concept called Instantari. So you can go MPX Instantari anywhere right now, and it opens up Atari 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 wanna stress to people about CLIs that they may not think about is for websites, we discuss 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 Lodash but somewhere else had Lodash, it's like a negative it's like a net net nothing to add this product that uses Lodash. But when you have a 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, and that's very fast to download. Much faster than, you know, MPX, for, you know, some CLI for node modules,

stuff. Yeah. I've I've gone down the whole of just, like, bundling node and and and bundling BUN. And it's Yeah. At the time, it was, like, 200 megs. And I know BUN's got it under 80, I think, now, but, like, Node.

You know? Yeah. Mhmm. That's good. Things that was challenging, though. I mean, that's I've I've liked it. I love rust. So, 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 TypeSlayer that's, like, shelling out to TSC, 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 Sanity, like, been blocked off for thirty years type of thing.

And, 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 Yeah. Which kind of thing the worst of all Wes love? Yeah. Hold on. I'll just try, Jay. I listen.

Clearly clearly, I I I do too, but I I really don't think JavaScript is a good tool for the back end. 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 I don't know. There's just lots of situations Wes, you know, I mean, TypeSlayer 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 and, you know, buffers and things. There's there are ways around it to process stuff, but, like, it's very cumbersome. Rust and and lots of native languages for, you know, Go or whatever. On on the other hand, like, they'll take as much as you have memory. You want 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, TypeSlayer was originally written with a node back end, like a nodes it was a tRPC, that I was using. From there, the next problem is, how to package it. So 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? Yeah. That's a good question. It you just lean on,

the fact that node runs everywhere, I believe. You know? And but that's you get that absolutely massive

bundle. Right? Yeah. You gotta bring in the whole node ecosystem. Yeah. Well, the way that the way that you get around this problem, so 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, TypeSlayer JS the Node of the Npm. But I also grab the organization at TypeSlayer.

And so if you go to that on npm, you'll see at typeslayer slash Tolinski dash 64, at typeslayer slash, you know, Darwin, which is the Node name for Mac, you know, Yarn 64, which is Apple Silicon, and, you know, at typeslayer slash Windows or whatever 64, Win 64.

And the way you do it is this is I pulled this trick from Wes build.

In your CI, you build, you have, like, a a 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 subpackage MPMs, the app types layer ones first. And then if those all complete, in the one that your users actually invoke, you have a little post install script that JS, 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. So you just try to figure out you detect their platform, platform dot OS or whatever, and then you you serve them the right Sanity. 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 a 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.

Yeah. Yeah. Yeah. That Homebrew works like that as well. Right? You you brew install something, and then it will go off and download the actual one that it needs given that you're on Yarn or Intel or whatever.

So I hope people catch on to this idea, and that's I'm I'm gonna hope to make, I'm really focused on getting TypeSlayer released right Node, 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 Yeah. 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. I I'm glad that you're you're you're advocating for GUIs here because we just had this conversation.

I love it. Yeah. GUIs are awesome.

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

Absolutely. And, I mean, this was one of the biggest motivations for the, not performance was the reason for TypeScript, you know, moving to go. Right? But, like, beneath you know, as a subpoint 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. Mhmm. Right? You're gonna be blockaded on your CI by a long type check because you everybody JS gonna, you know, wanna type check before they'll submit, you know, premerge a 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 Node, 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, you know, whatever. And that's not a bad result. But for some projects, you really need that oil change. Totally. Yeah. It's

that's something that I I think people don't understand. It just really how big some of these projects are and the the huge benefits. And and also just, like, the simply how expensive it is to run some of these CIs. 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 CI, 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 wanna type check something. Not to mention the most expensive problem, which is innovation cost. You Node? 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 TypeSlayer, and they go, I don't see anything wrong. It's like, yeah. Because there's there's probably not anything wrong then. Yeah. You Node? It's possible.

Yeah. We had 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 ten minutes. You Node, if your CI takes ten 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 ten minutes, you put in the pull request, you get somebody to review it, you get the thing approved, if you can do that all in under ten minutes, then just, like, the ship fast and and break things, that whole mentality we have right now Yeah. That becomes doable.

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.

Okay.

My personal opinion is it does not.

And the reason JS, 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? Yes. And then Yes. One more lane. Yes. Just one more lane. Yeah. Yeah. One more lane. And, you know, the types I think they even talked to in fact, maybe was it you guys that they that I saw that, you know, the team the TypeScript team talking to about this concept. Daniel brings it up sometimes asking talking about TSCO.

I think that in the short term, it's going to relieve a lot of pressure, and I think it's gonna 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 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 ten minutes, but 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. Yeah. But what's gonna happen is that one minute is gonna become acceptable, and then, like, you know, that's the thing with, like, the exponential growth is that, you know, over time, I don't think it's gonna be long before people are like, oh, TS Go is so slow. It's like yeah. Because Mhmm. It's I think that's why it's important to make like, I think that's what's exciting to me about a tool like TypeSlayer and other tools. There's actually others there. There's there's a TS perf, org that was kind of created. There's a there's a tool called Attest by this guy David Blass.

Attest does, like, a little bit of this, like, trying to tell you information about how slow your tests Yarn, and, like, the types in your tests are, and it kinda measures this with the TypeScript compiler 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 Node too JS another thing. Like, I've had library 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 code base Mhmm. 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. Yeah. So how do you know how well it works? Like, you have your Wes. You know? So it's like you can play with it in your tasks. Using it in a weird way that you didn't expect it, and all of a sudden,

boom, this thing is is crazy big. Right. Well, here's the question JS you obviously love different programming. You're Scott, like, a JavaScript lover.

Yep.

Should, like, should and will there be something after TypeScript? Should there be something new? And and if so, what would that look like? 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 I hope that I hope that this continues, and I I 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. I'm not sure. But I don't know if they do, but I yeah. I don't know. Like an AI thing? Are you is that what you're getting in here? Okay. 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 we don't It's just like the level of abstraction if you look back over the last, like, you know, a hundred years of us trying to mechanize things and, you know, through through computer science, the 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 attached to my head that reads my thoughts. Maybe that's the last programming language, actually, that's my dad. Right. You you think about this all the time. But back when we were first learning how to program,

like, everything felt like, why does this abstraction like, why is there so much Yeah. Friction in learning this this syntax or this abstraction when I can express things more clearly through English? One of my one of my favorite takeaways from the Doom project

is a couple 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. Of course. Yes. 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, 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 Node, it's like, how does that even work? That's like there's no 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.

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 gonna pass to the first function, 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? Yeah. Somewhere, it's a

a a voltage spike that's starting all of this. Right? Exactly. Yeah. Yeah.

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 at the same way, like, we I often think about, like, will there be another TypeScript? And I I don't think so. I I think, like, that's there's there's not gonna 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.

I mean, if 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 TypeScript types project was done by making a Wasm runtime. And, actually, the it can run other things. So if a couple 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 run time in type of device that can run Oh my god. That 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 gonna work. So, like, if your mindset JS, I'm gonna 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 gonna 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 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 thing 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. We'll see. Where where do you go to to stay on top of the WASM stuff? Because it it feels like such a mysterious well for someone like that. I have a bad I have bad news for you.

The only thing that I used was the was the pnpm.

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 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 Wes assembly. So one of the speakers came and talked about that, and that's where I learned more about some of these things. Yeah. Yeah. Let's talk about Squiggle Scott because because that's like a one of the the comps that I always see pop up is being like, wow. I gotta I gotta make it to Squiggle comp Oh, yeah. Sometimes. We'd love to have it. Yeah. Oh, yes. Let's do that. How it how it began is I have a, 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 Sem JS, Southeast Michigan JavaScript. But, you know, we don't write JavaScript anymore, so got a little refresh.

And I had this guy, Josh Goldberg, come out. Josh is the, well known as the maintainer of TypeScript ESLint. And so I pick up Josh in the car from the airport to come speak at my meetup, and, it took it took, like, ten 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 wanna 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. And, it kinda stopped for you know, kind of that was the end. And over the next couple 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 JS nobody's gonna do it. We kept waiting for somebody else. And so, yeah, Squibbokoff was born. That's a how how has that process been throwing a that seems like something that I never ever would wanna get into. That seems like a hard thing to do. Do not recommend.

Yeah. It's it's, it's very it can be very soul crushing. It can 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 kind of we're five zero one c three, and we have open books so people can see what we, you know, spent. But, like, you know, you're 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 Node? It's it's a a lot of logistics and coordination, 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, 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 line language conference too, which is something that's fun for us because, you know, like I said, I worked on Turborepo. Okay. Well, Turborepo is a tool or RS pack for that matter. Right? These are tools written in Rust that target JavaScript. But where does a person go to talk about that? What conference 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 they're it's not they're not that language. If you go to a Rust conference, like, they don't wanna hear about JavaScript at a Rust conference. You know? Node like they're not interested.

So there's a home here at SqigleConf 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 Gleam. Like, he was so excited. He's, 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 ESLint, and they just really wanted to share. Like, other languages could do this exact same thing. There's nothing gleam specific about this. Mhmm. But where can he go? They 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.

Yeah.

Yeah. That rules.

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

I think Zig is I've used Zig only for, like, cross compilation stuff. It's, like, freakyly good at that for some reason.

I'm really happy that Zig exists, but I also kinda wish that it didn't. I don't I don't have any, I I think Zig is way cooler than, JavaScript for that matter. Like, I'm I'm all I'm alright 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 ESLint, and then it becomes JSHint, and then it becomes ESLint, and and then it becomes TypeScript ESLint, which never even really merged, and it was like a whole thing. Or, yeah, we Wes skipped ESLint in the middle. Okay. And then it becomes, like, Biome and OXC. I mean, we're we're talking, like, the 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. Yeah.

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. Mhmm.

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 Zig. I mean, I've written a 100 lines of Zig. You know? Node I 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. Mhmm. It's sometimes it's the one that's the easiest to get started in. Mhmm. Yeah. You know? That's that's why JavaScript is so big. Right? It's it's definitely not the best language. Can I tease can I tease something for you? Yeah. Yes. Yes, please. There JS a secret that I would like to expose in the JavaScript world, and I'm gonna I'll I'll I'll expose it now. It. Yes. But I but I but I wanna I'm gonna make a video with this. I 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 one point o 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 out I I booted up 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 Yeah. Get the image. No. It is challenging.

Then I went even farther to connect it to the Internet, which you need, like, Netscape navigator version two dot zero zero one 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 examexample.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 one point o 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 a raise.

It did not have yes. It does not have undefined.

It doesn't have exceptions.

It doesn't have, like 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's there are so many things that are, like, absolutely critical to everything. It doesn't have switch statements. I mean, it's like what it was in version one point o, if you actually go and use 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 That'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. And Mhmm. There are just so many like, you know, instead of arrays, what do they do? Well, you know, you just you have objects. So, and there wasn't yeah. The the object syntax is, like, missing. But, anyway, you just put, like, a key. Like, you want Deno, you just add a key of zero. Yeah. Yeah. Yeah. That's technically how arrays still work. Yeah. Yeah.

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.

Scott one more random question. Wes don't know if this this will be good enough to make it in, but you seem like a pretty smart guy. You 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.

I'm I'm good with it. I think yeah. I think this industry has grown so much in the last ten Yarn.

And I think that most of us who have been doing it for a couple 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? Yeah. 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 thing like TypeSlayer has a problem with, I don't know. It doesn't work with GLIBC version 2.39 and below because there's some Linux thing. I deeply do not care about learning things like that. Yeah. Yeah. Like, I I really don't wanna 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, it you can, if you wanna learn a new language, but you don't know somebody who knows that language Yeah. 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 gonna be really tough. You know? It's it's only so much fun with Duolingo in in in the closet. Right? You Node, 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. Mhmm. 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 Node? If anybody who's trying to build a computer right now, you know, they're, you know, crucial, for example, that, you know, they just said, we're not making RAM for consumers anymore. Tough luck.

Samsung is stopping their SSD for consumers,

not their Npm or whatever, but their Yeah. Yeah. SSD. Yeah. Yeah. So I think that, there is gonna be some bumpy, you know, some turbulence in the meantime, and I we all need to be ready for that. The the job market Node, I just left, 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 Type Slayers. I had a little, like, couple 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 Node. And, there's, like, strange levels of desperation at the same time as, 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 gonna find out that there's a lot that AI can't do. Actually, advanced TypeScript types, tomfoolery JS 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, so we'll see. I think that can be improved, but looking at the long picture, you know, I read this, the Singularity is Near when I was a kid.

I don't know if you heard Ray Kurzweil, this, like Yes. The Singularity is Near and, the Age of Spiritual Machines. I think the 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 Wes, 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 book, it says it. 2040. Yeah. Unlike, 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.

Yeah. And so I think, like, as as time goes on, we're gonna see how things level, but this is definitely a weird time to be a software engineer in this century.

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. Yeah. 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, kind of Java developers and stuff where there's, like, less turmoil, or Rust or Go or with any other language, they're probably not as used to the amount that they have to kind of, like, keep up Yeah. That Yeah. You know, they're gonna have to they're gonna have to learn. They're gonna have to learn to keep up.

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, podcast, physical item, who knows what, TV show, whatever. And then, shameless plug is anything you just wanna plug.

What I would like to plug is, this guy ESLint McDonald, the ZAUB founder, and David Blass, the Arctype founder, are working on this thing, pull frog, to you know, it's like coding agents in GitHub. They also have, Andurist, 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 Arkype 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 all three of them, and it's been really cool to see them doing it.

It's, you know, we'll see what comes of pull frog. It's it seems to be it seems to be pretty exciting to see all these tools. Like, maybe you've used Devon or, you know, these other agents that can kind of review your PRs for you. Yeah. I I I think it's a cool space to be in. Yeah. Yeah. I didn't realize they're they were working on that. I've been seeing this, yeah, come together, and I've been following it. Yeah. No. That and and, I mean, honestly, to even just talk about archetype, that's a really cool project. I mean David also yeah. I mean, if I have a honorable mention, David released this thing, Yarn Regex, which JS, like, doing That's also nuts. Yeah. Yeah. He JS he has been 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 forty five minutes one night and just, like, told me how to do it, how to how to make the machine chug. Yeah. And 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 ArcRegex is a crazy project because that's like you know, regex regexes are, like, famously very complicated things to do. And making a type safe regex parser purely in TypeScript types, you know, like, well, it does both. Right? So it's a drop and replacement for regex. It's just super cool. So He's so nuts. I can't believe I built that. Yeah. Yeah. I I gotta look at the code behind this thing because it's probably It's clean. And early. Yeah. It's not. Yeah. No. David David has a he has a little different style, I think, but, he's it's, like, very meticulous code. Like, he's not scrappy in the sense of, like, 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.

I love that. Type of person that needs to take on a project to parse a reg Wes whole That's who you want. By the way, you really want you really want a software craftsman to make your regex library. Right? It's, like, very important. Node. You get the right kind of person on that job. Yeah. Holy smokes.

I'll give a plug to, so all this time, we're talking about the Doom thing. I I just the year got away from me, and Squiggleconf took over a lot of time. But on Sunday, January 4 at 1PM eastern, I'll be doing a deep dive with Dylan Mulroy, a friend of mine Yeah. On the, you know Dylan? Yeah. Yeah. Yeah. He just started over at CloudFlare. Right? He was also a Vercel, the CloudFlare guy. Yeah. Yeah. So, yeah, Dylan and I will be will be working alongside each other again, which is gonna be awesome. But, yeah, Dylan, and I are gonna go through soup to nuts, top to bottom, the entire Doom code Bos. Like, how does everything work? It's gonna be at least three hours long. And, 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 gonna be we're gonna be looking at memory addresses from the first ten minutes. Yep. JS that gonna be on the Michigan TypeScript YouTube channel? Yeah. 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 4.

Yeah. It'll be it'll be cool. Yeah. Man, it's so cool to see Michigan typescript, quote, unquote, on the map here. Like, JS somebody who attended that meetup before, it was Michigan typescript for, like Wes. So long. Like, it's pretty cool to see. 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 type they hate enums, and that talk just, like, blew up. Yeah. 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 kinda cool. We should do more stuff like this, and it kinda ballooned. Now we're 400 videos in.

Hell, yeah. Shout out to the Michigan, web dev scene overall.

Thank you so much, Dimitri. Man, you were just This is awesome. A delight in all facets of the warp, man. You're you're so warp. So we gotta 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.

Thank you. Yeah. It's been a pleasure.