Josh Goldberg (3:26)

What did you think you were going to do before you became a software dev?

Dimitri Mitropoulos (3:30)

I went to college because I wanted to be a Latin teacher. I had a Latin teacher, Dr. Steven Rosenquist, who was very impactful to my education and I really looked up to him and I kind of wanted to be like him. So I knew I would be poor. You know, being a Latin teacher is not a lot of those positions left in the US But I knew I would be happy. And to me, that is the trade off that I find myself making very easily, even though it may have dire outcomes. So I went to school for that. But it wasn't long before I realized that actually, to my surprise, the Latin and Ancient Greek stuff, the history and all the archaeology and those kinds of things were not that interesting to me. What was more interesting to me was linguistics. So I picked up a second degree in linguistics. But in my orientation, I wrote a program that instead of going out to parties and trying to make friends and things, I stayed in my room and. And I wrote a program that calculated what the fastest way I could take the course curriculum was to get my Latin and Ancient Greek degree. And I found out that that's a very bad way to go into it with college because there's a lot of fluff built into the course curriculum. They're expecting you to kind of wander around a little bit. And so I was the middle of my sophomore year and I was looking down the line here and saying, oh, wow, I'm going to be done with my Classics degree. I'm going to be done with my linguistics degree and I'm still going to have two years left here. What am I going to do? Because I was like, there's ways you can double dip different levels of requirements, major versus college versus university level requirements. And I wrote another program. This time the program was to calculate what other major I was the closest to having already completed. And it came back speech pathology. So I did the undergrad speech pathology, got involved with a bunch of research. Of course, at college they're dying for, you know, most majors are absolutely just so hungry for people who can do programming because they need to run experiments. And I learned matlab and they need a lot of help for, you know, many professors in different departments, obviously not engineering departments, need people like me to function. So I was offered to teach a neurology class to pay for my master's degree and stay on and do research with linguistics research. And I got my master's in speech pathology. So I have three bachelor's degrees and a master's degree, none in software engineering. I didn't think of myself as a software engineer at the time, despite all of this stuff I'm saying. Yeah.

Josh Goldberg (5:44)

So in a sense, would it be inaccurate to say that matlab was one of your, if not your first work experience?

Dimitri Mitropoulos (5:51)

That's interesting. Actually, VB was my first, I think, like work experience. And even before that, I mean, I was on MySpace making websites before Facebook was a thing. And I wish I had screenshots of some of these websites, you know, in those days, because you could depend on the screen resolution. I think people don't understand how terrible responsive design has been for website design, because if you know how many pixels exactly the screen resolution is, you can make like really engaging experiences. Like video games are today, actually, I think it's like way they are, they're very engaging. They don't have to be responsive though, so they can make really cool stuff. But anyway, yeah, I think that was one of the beginning things, but I did other stuff too.

Josh Goldberg (6:29)

Okay, how did you then transfer from linguistics, feast pathology and so on into software development as a career? What was that first job or internship like for you?

Dimitri Mitropoulos (6:39)

Well, I graduated and I hit a career impossibility. Like basically it's a whole other topic. But speech pathologists do a lot of things and it's a bit of a strange field in that way. And one of the things they do is work with people who have traumatic brain injuries and kind of like very highly medical linguistic problems in a clinical setting, like a hospital setting. And I Wanted to do that because I have my linguistics degree and I'm a very good candidate to do that kind of work. But the way it works in that industry is you're expected, in large part is not true for everyone. But most people are expected to go, like work in a school for like 10 years. You know, you're supposed to climb the ladder and then like after 30 years of experience, then you can go have those highly sought after jobs in the hospitals to do that kind of stuff and do research and those things. But I just wanted to start there. So I succeeded a lot in my life by forcing my way through. And I failed so hard to get the jobs that I wanted or the job that I wanted. And yeah, I went broke, basically. I had like, I don't remember the exact number, but it was like maybe 2 or $300 left in my bank account. And a friend of mine said, hey, Dimitri, like, here's the deal though. I'm a software engineer and anytime I have a question I ask you and you seem to know the answer, it makes me think that you might be able to do this. I know you want to be a speech pathologist and you're very excited about this, but what are you going to do next week? You're like, you need money and it takes time to get a job and get on the payroll and all that. Just come work with me temporarily and make some money, and then you can keep applying for jobs as a speech pathologist and do whatever you want to do. So that's what I did. Visual Basic, that was all VB, VB6. That company embraced Visual Basic before. Net happened. And so it was all Visual Basic and COBOL were the two languages mostly that we used.

Josh Goldberg (8:21)

How many years ago was this?

Dimitri Mitropoulos (8:22)

I think it was like 2013. Yeah.

Josh Goldberg (8:25)

Okay.

Dimitri Mitropoulos (8:26)

Wow.

Josh Goldberg (8:26)

So you've been doing this temporary side of programming for over a decade now, and now you're at Vercel, is that right?

Dimitri Mitropoulos (8:32)

Yeah, yeah. It's a long arc.

Josh Goldberg (8:35)

What are you doing, Vercel?

Dimitri Mitropoulos (8:37)

Well, a lot of things. One of the things I'm proudest of, that I am excited about is I've worked on turborepo. I love Monorepo stuff in general. So that's been fun. Right now I'm working. Well, I can't. It's funny, I realize I don't think I can say what I'm working on. Actually. I'm working on a new thing that Vercel is doing. It's not like a huge new product, it's just a new piece of functionality within the offering that I think is very exciting. I can say it's something different for Vercel. I think one of the reasons people like Vercel's products is it's a there's kind of like a way to do things, like a way to move quickly in the Vercel ethos about pushing to production and just having things being really fast and really immediate. And I'm doing something that it's a different venture for Vercel as far as like the philosophical side. And I'm excited to be at a company that's figuring out how to make a product that doesn't just suit startups, but suits a wide range of different use cases that may have different needs than Now Now Now. So I don't know, maybe that's too big of a hint. I'll find out if I'm fired on I won't be. I'm just joking.

Josh Goldberg (9:34)

But once this podcast releases, I do want to talk about that a bit. Just to prep us for talking about Doom and Typescript, the banner of this episode, because you've been very passionate for a very long time. It's very clear from all your activities and your posts online about dev tooling. And now you're working at a company that in many ways is largely a dev tooling or dev tooling adjacent company. What is it about working for or with or around developers that excites you so much?

Dimitri Mitropoulos (9:58)

Yeah, easy answer. Actually, this is a great segue. Maybe you don't know it, but that ties so well into the speech pathology stuff that I was saying a second ago. One of the reasons I think I was excited to work in that field is because when you work with people who are experiencing like a traumatic brain injury from a car accident or something, and they lose their ability to speak or, you know, not all stories are success stories, so there's definitely heartbreak there. But the feeling of helping people is so exciting to me and I enjoy it so much that it drives me to do a lot of things. And I feel like I'm missing that a lot. As a software engineer, I've never worked for one of these kind of companies, but I have friends who have worked for large companies and they tell me that you wonder whether the code you're writing is going to be used in a drone strike later. You wonder where this is all going 10 years from now, because you leave the company, but the work you did stays there with the company and you don't have control over what it does next. And that sense of Hopelessness is hard to overcome, I think, for a lot of people in software engineering. But when I work on dev tools, I feel the feeling. It's a bit similar to the feeling I got from working with, like kids, I think is the best example. I worked in a preschool for a while as one of my placements as a speech pathologist. Despite not wanting to work in schools broadly, I did quite enjoy working in preschool because you see the growth over a very short span of time and you see someone go from zero to hero over just a few months with you working with them. When kids are very young, they can learn very quickly some things and if they have a professional that knows the tricks to teach them. And I think that dev tools is a lot like that, that you end up taking a person who maybe didn't feel empowered to be able to do something like make a website or publish their thing to the world, and you give them this tool that kind of walks them through it and suddenly they're able to do this amazing thing. And the like, empowerment that they get from that is so cool. And you may not even know them. That's a way in which software engineering is so exciting to me. You may not even ever know that they exist ever. And they're just out there. And it's cool to go and meet people in person and hear stories. But I like the idea that there's this force multiplier when you work on something like dev tools, that you're changing the world in some kind of positive way that. Yeah, I mean, the other side of the fence is true. To go back to the drone strike thing. They could be writing drone strike software, I guess. I don't know. So, I mean, both sides are possible. But I think in large part I feel like I'm putting smiles on faces when I work on dev tooling. And it's a lot more smiles when you're working on something systemic that everybody uses rather than making a product. There's lots of products I could work on that end users use directly and I would feel good about that. But it just feels so much bigger on DevTools.

Josh Goldberg (12:28)

So let's finally get to it. How does this all relate to DOOM and the typescript types? Before we actually talk about what that is, how did you and why did you do this thing?

Dimitri Mitropoulos (12:36)

How does this all relate? I mean, I don't know. I guess it doesn't. It's a pointless project. I think in a lot of ways there's no reason to do a thing like this necessarily. And it's a love of the game, I guess. I think tinkering has a lot that it can offer you as a professional. And I learned way more. I mean, I said it in the video, the announcement video, but I learned more working on this project than in the prior 10 years. Working very hard professionally, I might add. I mean, I tried to push myself quite a lot at work, and I've done some great things I feel very good about. I've worked with some really cool teams, which I feel even better about, but nothing compares to what I personally learned working on a project like the Doom and Typescript types project.

Josh Goldberg (13:18)

Sure, when you say pointless, there's of course no direct professional point to it, but the actual benefits, the consequences of the project beyond Internet fame and amusement, is, yeah, that you've learned a lot, that you've built tools that perhaps other people may use. It sounds like it was quite a productive point. Full project.

Dimitri Mitropoulos (13:33)

It's shocking how often Doom has come up. Like, I'm so glad that it's out now that I can tell my colleagues because there were a lot of times at work where they'd be like, how do you know this? Like, it'd be like debugging some TypeScript performance thing. And I'm just like showing people. I did a brown bag session at my company trying to teach people how to step through and break through the TypeScript compiler. So it's kind of like, I think fairly advanced, like strange thing to do or need to do. And a few people were like, but. Or even start learning to do something like this. And what I couldn't tell them at the time, but now I can say is like, I learned how to do this because I had to do it to get Doom to work. And there's lots of things like that where it's not just Typescript type stuff, where there's learning how C works and how to do cross compilation and how to do, I don't know webassembly. I know way more about webassembly than I could have ever imagined because I had to implement a webassembly runtime from scratch. And guess what? When you're at a company that's doing interesting things, these type of, not just mine, but lots of companies like these things come up. But you may not realize they're coming up unless you have the expertise and unless you can say, hey, wait a second, I see the problem that we're facing and I know a thing that could help with that. Why don't we go take a look? And there's not really a way to be in a position to make a statement like that at your company to better what the overall company is achieving, other than side projects, as far as I know, anyway.

Josh Goldberg (14:52)

Yeah, all right, we've buried the lead quite enough. Dimitri, I'm going to give you a small time span of about 30 seconds. I know what JavaScript is and nothing else. Tell me, what did you do?

Dimitri Mitropoulos (15:03)

Programming languages have a concept called types. You can set variables, and the variables have a certain type. Types are like numbers. And then programmers have this thing called strings, which is like a bunch of characters, like a list of characters. Well, in TypeScript you can set a static string as a variable type. So you can say this type is only allowed to have red or blue, and no other strings are allowed. Or the numbers 7 and 13 and no other numbers are allowed, stuff like that. And just based on that, just based on the ability to set a literal type, you can create other types that operate on those types. So now I can say I'm going to take red, lowercase r, e, d, and then make it all uppercase. I can create a type that will take an existing one and change it. And I made a type that will take the innards, the source code of doom, if you will, and by type checking it, which is a way that the TypeScript type checker will validate that your source code hasn't done the wrong thing, I made a type that will create a frame of doom by checking the type. The result of checking the type is a frame of doom, just like you can create a type that will operate on lowercase red and give you uppercase red. I made a type that will operate on the source code of doom and return a frame of the screen. How'd I do that? Probably wasn't 30 seconds.

Josh Goldberg (16:24)

It was a minute, minute and a half. But it's an absurd thing. So just to confirm, there's an old continuous joke people do of can doom run on this? People put doom on the TI84 calculator and all these microcontrollers and stuff, and you got Doom running in the TypeScript type system. That seems like an inherently impossible task at first because the type system is not the programming language runtime itself. It's a way of describing types. So how is it possible that you can run a logical piece of C code in a type system?

Dimitri Mitropoulos (16:54)

Well, I think I can answer this with something somebody said on. I think it was on Reddit or maybe it was on Twitter. Whatever somebody said. Well, all programs need a main function, which is like the entry function that it calls. And this guy may have done most of the work in TypeScript types, but TypeScript types don't have a main function. So there's no way that he could have actually done it. And the response I gave to that is like, I had the same feeling going into this. I never thought this. We haven't gotten into this part, but I think like an important thing to mention we can talk about in a second is I never thought this would work. I never expected this would be possible. I was very sure of the opposite actually. So typescript types can operate on anything. If you can create the abstractions. And it turns out that a main function is just an abstraction. There is stuff beneath the main function. But like if you write C, you just don't get to look at it. You don't get to see what's going on. Like, okay, so there's a main function, but what calls the main function? Well, you don't see that part. C handles that for you. And you know, an executable, whatever. All this stuff that we have handles that for you. But so I had to piece that apart as well. That's the way in which to answer your question, that I was able to get something to actually execute is I had to kind of dig into all that and find out how it works, which was news to me. I had no idea about any of this stuff. Capital One's tech team isn't just talking about multigentic AI.

Josh Goldberg (18:12)

They already deployed one.

Dimitri Mitropoulos (18:13)

It's called Chat Concierge and is simplifying car shopping using self reflection and layered reasoning with live API checks. It doesn't just help buyers find a car they love. It helps schedule a test drive, get pre approved for financing and estimate trade in value.

Josh Goldberg (18:26)

Advanced, intuitive and deployed.

Dimitri Mitropoulos (18:28)

That's how they stack. That's technology at Capital One.

Josh Goldberg (18:32)

But taking a step even further back, you're talking about being able to determine the entry point of an application and how to bootstrap it. But what I mean is, logically, when people use the phrase Turing complete or Turing completeness, Referring to the TypeScript type system, what does that mean?

Dimitri Mitropoulos (18:47)

Nothing. Turing complete to me means nothing. Basically, I think it's a useless concept. And I'm sorry to mathematicians who are sneering at me, but the thing is that there are known Turing complete systems that can't do anything useful, like let's say one plus one before the heat death of the universe. I think it is interesting mathematically, maybe, but I don't really care. And I think One of the things that spurred me to do this project is I felt for a long time that Turing Completeness is not that exciting. So it's been known for those listening, I think, Josh, you probably know, but Typescript's type system has been known to be, quote, unquote, Turing Complete for a while.

Josh Goldberg (19:21)

Which means.

Dimitri Mitropoulos (19:22)

Yeah. Which means that you could theoretically compute anything given enough time and resources. In fact, given infinite time and resources. And by the way, I learned a lot about Turing Completeness. There's a very important thing about Turing Completeness I never hear people talk about, which is that the definition of Turing Completeness doesn't include the ability to loop. Like, I think printf in C, there's Printf debugging. You know, Printf has been shown to be Turing Complete, but the definition doesn't mean that there's a way to have it kind of recurse and do constant loops. It may be required that you have some external force that's constantly pushing at you, saying, okay, now do another thing. Okay, now do another thing. Okay, now do another thing constantly. And that external thing is considered outside the definition of Turing Completeness, which I think is like, another thing. That's kind of baloney. Right. I learned that Doom itself is Turing Complete. The Doom engine, the Doom game. You can create Turing Completeness inside of Doom. And so my proposal, programmers, my proposal to you, stop talking about Turing Complete. Start talking about Doom Complete.

Josh Goldberg (20:25)

Can it run in Doom?

Dimitri Mitropoulos (20:27)

Can it run in Doom? Is a way more interesting mathematical observation of a system than whether or not it's mathematically, like, theoretically Turing Complete. Because if it can just run one frame of Doom in a human lifetime, I think that separates lots and lots of known Turing Complete systems.

Josh Goldberg (20:44)

There you go.

Dimitri Mitropoulos (20:45)

Sorry, that's my rat. This is like. I was hoping to prove this point with the project that I was hoping to demonstrate how just because Typescript, like the starting thesis is kind of was. Just because Typescript types are Turing complete doesn't mean that you can do, like, run a frame of Doom. Yeah, that was the idea.

Josh Goldberg (21:02)

And then in your video, you mentioned that kept you going through the whole.

Dimitri Mitropoulos (21:05)

The whole thing. Yeah, I never lost track of that. And it's not. I'm not being dramatic. I genuinely never believed at any point that it would work until the very second that it was on the screen in front of me, and I couldn't deny it anymore.

Josh Goldberg (21:17)

Sure. So we will cover a lot of the stuff you did in the type system, such as making a webassembly runtime, all the tooling you wrote around it. But for folks who are working in typescript day to day, perhaps not building a video game, but describing their rich functions or making third party utility libraries. What are some of the TypeScript type system features just within TypeScript that you think fit folks would be most interested.

Dimitri Mitropoulos (21:38)

In or find useful about the Doom project?

Josh Goldberg (21:42)

Just Typescript in general.

Dimitri Mitropoulos (21:43)

Oh, Typescript in general, okay, sure. I mean, I think that TypeScript has a lot of dangers that you can run into. I think that largely there are very important things that you can do. Like strict mode is one that I think some people miss in the very beginning. Typescript without Strict Mode is not TypeScript in my mind. It's some kind of like compatibility mode for migrating projects. You really need to have strict mode on. You know, go into your tsconfig and look for strict true in that or a TS config that it extends from. It's very important. I think that the larger point with TypeScript is not about making it perfect. I think some people get very hyper focused on. There's this concept of type soundness and making 100% sound programs. It's not all it's cracked up to be. And if you're not sure about that, you should try writing Rust. I love Rust. I would describe myself as a Rust shill. But Rust makes it very hard for you to do scrappy things, to just try out an idea. It's like not very easy to do because it puts a lot of constraints. We don't want TypeScript to be something like that, I think. So what are the features? I mean, to be honest, there's not a lot that I think a normal program really requires. If you find yourself writing very long types, and long for most people probably means like 10 line types or something like that, or five line types, you're probably in a position that requires you to take a step back and take a breath and think about what the constraints are that you're really working with. I've seen situations where people try to introduce type safety where it doesn't really exist. And sometimes what you need is like a validator. You need Archetype, or you need Zod, or you need AJV or some JSON schema or something. Instead of trying to make a Typescript type that's like really, really perfect, sometimes you need to just understand that we're working with imperfect systems where, yeah, maybe today the API returns the response you want, but next month the API can change. Someone might change it. You kind of need to write software that can handle that. And I think that's where dynamic programming languages like TypeScript really shine.

Josh Goldberg (23:44)

So just to be clear, the guy who got Doom running in the TypeScript type system is telling us that in most cases we perhaps don't need very rich, complex Typescript types.

Dimitri Mitropoulos (23:52)

Basically in all cases. Yeah, I think I am not a TypeScript type level programming evangelist, which I think is kind of funny sometimes for people to hear. Actually, I wouldn't even describe myself as a TypeScript evangelist. I think TypeScript should be used in a lot fewer places than it is today. There's a place where it's really awesome and I would like to see more but in the front end is like to say it quickly I think is the one but Backend JavaScript I am very much not on the train of I know that it can work for some people sometimes, but I'm basically not a supporter of using TypeScript at all on the backend. If there's any other way to avoid it. That's just my feeling. But reasonable people disagree on this, don't they?

Josh Goldberg (24:28)

Yes, I do wish we had the three hours to discuss whether and when full stack JavaScript is applicable. What a Full Stack Engineer means, perhaps in a subsequent episode. But okay, let's say that I'm on a web platform team or a front end team or some such. I'm writing React or angular or whatnot components and I'm finding myself in the position where I have a kind of generalized function. It takes in a bunch of different things, maybe a polymorphic component, and it returns something different based on the input. What is kind of your theology of trying to determine whether I should use fancy type system features or rewrite the component in that case, I think it's.

Dimitri Mitropoulos (25:03)

Situational on a few factors. So I can't tell you when, but I can tell you the factors. So one of the factors is the team. So I think that people who are excited about software engineering, like clearly you and I are, and perhaps people listening to this, I think that if you're really excited about something, some aspect, just to make fun of it, let's use functional programming. So maybe we've all experienced engineers that are really excited about functional programming. Okay, the analogy is Typescript types, but let's make fun of programming. I love functional programming, so it's easy. I'm one of the boys, I'm in the in crowd, so I can make fun of it. So what happens a lot is you notice people who are very passionate about advanced features will kind of push it on their colleagues and this creates A immune response among the team that can sort of reject the input even if it's the right thing to do. And I've seen this happen with typescript types just as much as functional programming or other things that people get nerdy about and excited about. And I think that looking around you to see how your colleagues feel and if they're comfortable with adding advanced types that do advanced things is highly critical and often overlooked. Of course you can't know who's going to be taking on the code base in the future after you. But that's one of the biggest factors I think, is a social one. Is your team down to go down this path? And if not, even if it's probably the right technical choice, you shouldn't do it. I think that's a veto card that you need to be able to pull on behalf of your colleagues if you want to be a kind of leader on your team or you want to make cool software. Another factor I think is the general health of the code base itself. So if the code base is not in good health and we can kind of wax and wane about how to define what that means, it means different things to different people. But maybe it's a performance problem like you see type checking is taking a long time, or there's lots of TS ignores and tsexpect errors kind of overriding the type system all over the place. I think that's a very objective sign of unhealth. If you see that situation, you should try to focus on those things first before adding advanced TypeScript types that do very amazing, impressive things. It's important to level out the code base because if you haven't done the basics, you don't want to do the advanced stuff. Make sure the basics and the bases are covered first mode on. Like I was saying before, don't have any tsignore or ts. Expect error in your project. Not even one, even one is unacceptable, I think. Well, the only time when it is acceptable, in my opinion, is type level testing when you're trying to validate that a type that's exposed on your API will in fact error. That perhaps is the one. But that's a whole other topic that I think most people are not even aware of. So don't worry about it. But these are the factors, I think the two main factors that I think about when deciding whether or not to use advanced stuff. I try very hard not to bring any of the advanced stuff to work. To be honest, in most jobs that I'm at, I've been doing this kind of typescript stuff for a while and it's usually not a good idea, to.

Josh Goldberg (27:47)

Be honest, I have so many follow ups. This is great. Thank you. Yes, the social aspect, I think, is drastically underestimated. A lot of people will take a look at a problem and think, oh, this is the right way to look at it or the right way to solve it. But if your team around you does not know something, the cost of training them all up on this particular solution you want might be significantly greater than the cost of just letting it be slightly incorrect or off, in your opinion.

Dimitri Mitropoulos (28:11)

And the cost can be to you socially, not just the cost on the code base. It can also be that, like, people hate working with you because you're forcing them to do things that make them uncomfortable. And of course, there are ways to solve that and give them that comfort and show them. And you can pair a program with them and walk them through it, but at the end of the day, if they're not down for the experience, then you kind of have to work with that.

Narrator/Host Introduction (28:33)

Feeling the AI anxiety. From questions to job security to cybersecurity and everything in between, it's easy to feel overwhelmed with the rate of AI innovation. Enter aia, the enterprise AI orchestration and security platform built to boost your confidence. With aeria, you don't have to compromise between speed and innovation or security and governance. Quickly deploy AI without cutting corners on compliance. Give your teams the confidence to adopt AI. With ARIA ready to eliminate your AI anxiety, visit Airia.com to get started for free today. That's a I r I a dot com.

Josh Goldberg (29:11)

You mentioned an interesting point that there should be no TS ignores or tsexpect errors. I have a type that is hard to work with in existing code and TypeScript's given me a complaint. I don't have the 13 hours to go fix this one particular complaint in old code. What should I do, Dmitri, instead?

Dimitri Mitropoulos (29:27)

You could use it. I mean, it's a tool. It's there to be used. I mean, one of the things. Actually, maybe you don't know this, Josh. One of my only contributions to TypeScript ESLint was I'm the person who added the change to the ban. What is it called? It's called the Typescript directive. The thing we're talking about TS, ignore and tsexpecterror. And I put a thing into TypeScript ESLint, where you have to write a description of why you are doing this verboten thing that you shouldn't do. So I think the first step is if you have to do it. You have to do it. I mean we're here to crack some eggs and make some omelettes, right? So sometimes that's how it goes. The best thing you can do first is in that exact moment describe why it has to be there, why you think it has to be there, because you might have missed something and someone might come along later and go, oh well if that's the reason, actually that problem doesn't exist anymore or I know the solution to that. So sometimes these things can sort of self heal by the beautiful nature of working on a team and you can get a long way with that. Love it.

Josh Goldberg (30:24)

Yes. That's the ban ts comment rule.

Dimitri Mitropoulos (30:26)

Yeah.

Josh Goldberg (30:26)

TSLink.

Dimitri Mitropoulos (30:27)

Yeah.

Josh Goldberg (30:27)

And the allow with description option. Great one. I use that.

Dimitri Mitropoulos (30:30)

Thank you.

Josh Goldberg (30:31)

Yeah, thank you for contributing. But okay, so you also mentioned using strict true, trying to avoid tsignore and expect errors, perhaps linting. Before we move on to the rest of doom and Typescript, what are some other tips you have for folks trying to write enterprise grade high quality typescript on large teams?

Dimitri Mitropoulos (30:47)

So you really nerd sniped me here. There is one super unknown feature of Typescript that I think is absolutely unacceptable to not use for a library or for basically I think everyone should turn it on and it's called exact optional property types. I'm going to making some point in the next year, probably a video on this because it's one that I think is missed by a lot of people. But basically without describing what it does, I'll tell you the effect of it. It's a thing that users may turn on. End users of your code your library may turn on to increase their type safety. But if you don't have it on in your library, there are kind of type conundrums that you can thrust your users into that they can't get out of without lots of kind of nasty workarounds. And if you would just be so kind as to turn it on in your code base, then people who are not using this feature, which is most people probably because I think like I said, a lot of people don't know about doesn't affect them. There's completely. It's a complete no op. It's the same for them, but it only increases the life and the experience of users that do have it on and keeps them from having to do very nasty workarounds. And I think also it just makes for better software which is why people turn it on. So I guess if I had to pick one, that'd be my one that I wish I heard more people talking about, but that's one of the reasons Michigan TypeScript exists. That's why I started it and that's why we have people on talking about this kind of stuff is I just, I would love to share those kinds of things as I come across them and hear from other people what theirs are. So yeah, that's mine.

Josh Goldberg (32:11)

Exact optional property types in TypeScript. What is the definition of that? What does it actually do?

Dimitri Mitropoulos (32:16)

I'll read you the blurb here. Let's see, with exact optional property types enabled, TypeScript applies stricter rules around how it handles properties on types or interfaces that have the question mark prefix. So basically it's separating the situation where is the property there or not? So it's like one situation in an object. So is the property physically there? And then there's this other weird thing in JavaScript where the property is there but the value of the property is undefined. Usually in native, like kind of standard TypeScript. Without this option, this exact optional property types turned on, you can't really distinguish at a type level between those two things. The property being absent is indistinguishable from the property being present, but the value is undefined. But those are kind of different things. Like if you do object keys, you're going to get an array back with very different results, right? Depending on those two states. And it's kind of nice to be like, I personally feel, you know, I don't want to say the TypeScript team has done something wrong or something like they're kind of holy to me, I respect them so much, but I personally feel like this should be in strict mode. I think it's like it's no argument that this has to be in strict mode, but it's a little annoying to solve because you have to start thinking about this difference. And in a lot of situations in JavaScript, it doesn't matter if you're trying to access the property, you'll get undefined back whether or not, you know, state A where the property is not there, and state B where the property is there but the value is undefined. In either case, if you try to access it, you'll get back undefined in JavaScript and so it looks the same. And I think that's where this kind of comes from. People are used to it being the same.

Josh Goldberg (33:50)

But yeah, sure, it's a good point. Back to Doom and TypeScript, so we've covered that. Just to recap, you are able to write logic in the TypeScript type system. We haven't named the features explicitly, but logical types and then map types and such. And then we've covered a lot of the real world uses or areas around how those might or might not be relevant and applicable for teams. But I do think we do by user demand, need to cover. You wrote a webassembly runtime in the type system. What does that sentence actually mean?

Dimitri Mitropoulos (34:19)

Right? So the name that people use is type level programming. To describe this kind of way of doing programming where you're just operating only on types. So you have types as inputs, types as outputs, types as transformers, so kind of functions. And basically. So I didn't know anything about webassembly. When I start, some people ask me, why did you use webassembly for this? Is it because of this? Is it because of that? Is it because of this other thing? And the answer is I didn't. It was like the second thing I tried, I, I didn't know any better and I had never used webassembly before. So ignorance. In webassembly you have this concept of instructions. And instructions are like very simple, very, very simple units of work where you say like add two numbers together or subtract this number from that number, or do the bitwise and of these two numbers, right? There's these operations that you can do and webassembly, the semantics of webassembly handles a lot of the higher level abstractions for you. So you don't really have to think about it. So there's no arrays. It's kind of surprising to people here, like there's no arrays. Well, there aren't in webassembly. It's just numbers basically. There's not even strings or booleans in Webassembly's kind of quote unquote type system. It doesn't actually have a type system, but it has webassembly values which could be 32 or 64 bit units of numbers. And then you can have these operations that will operate on those numbers, but through lots of abstractions. You can represent basically anything with numbers, right? I can, I can just say, you know, arbitrarily, the numbers of the Alphabet are, you know, these numbers. A is 1, B is 2, C is 3. Like that'd be an encoding, right? So you can create an encoding for lots of things. And then now look, they're numbers, but you know, trust me, bro, they're strings. And so you can create these kind of structures and abstractions. And webassembly does exactly that. It builds abstractions one over the other. Over the other, over the other until you can kind of do whatever you want. So it's kind of like we were talking about before with Turing Complete. It's a very kind of practical application of this idea, but with a lot more knobs and buttons that you can push. So a webassembly runtime takes as its input webassembly instructions and then it does some work. That's the runtime part. And then as an output, it returns. It's kind of like returns from a function, right? It's like the, you have a function and it returns some result. Most of the time in webassembly the result is actually a function that you gave it that it will give some byte values to. So normally when you call webassembly programs, they just give you back a pointer. And that pointer, you also have access to the webassembly memory and you go into the memory and you do something with that pointer. You're supposed to know what to do with that pointer. So it might be a string. So there's this convention, I didn't know about this either. There's this convention called C style strings where you have the sentinel value, this special value which is all zeros of byte value, so eight zeros. And you just read from memory. So they give you a pointer, you go, great, you go to that pointer in memory, you just read bytes out, you take those bytes and you convert them into known ahead of time values because they're mapped in a certain way. So that's like ASCII encoding and UTF8 and these things. So everybody knows in advance what the encoding is. So you take that knowledge, you turn those numbers into strings, you build up the string, and then someday, suddenly you hit a zero and you go, oh, okay, that must be the end of the string. I'm all done now. And then, now you're in JavaScript. Now you've converted something over the boundary. And that system is exactly how the type system stuff works. Where the input is TypeScript type, which is basically just the webassembly instructions, but they've been transformed into a form that TypeScript can understand, which is just like, it's stuff that you would think. It's like an object where it says like kind add and then there might be some operands, and then it's just an array of stuff like that. That's the instructions list. The webassembly runtime does all the work. And then the result is, you know, an object in this case is a string. We could just say a string Of a screen of doom. Yeah.

Josh Goldberg (38:18)

How long does it take for such a project to come to be? How many hours or how many months of work do you think went into it?

Dimitri Mitropoulos (38:25)

I struggle so much to answer this question. So. By the way, maybe I should apologize to people who watched the video. There was some debate about. So I made this comment in the video that it was like a year of 18 hour days. And some people took that to mean that I repeatedly, without any pause, spent 18 hours of every day. So, like, I basically did nothing else other than work on this for a full year. And I didn't mean that. I wasn't trying to be imprecise, but there were many literal 18 hour days and there were many days that were more like greater than 24 hour programming spans where I would, you know, see the sun rise, see the sunset, see the sun rise. It'd be midday and I'd go, I think I'm supposed to sleep now or something. I better step away for a moment. Also, there were times when I was like kind of never stopped thinking about this problem. So there were times when I was like driving, you know, for an hour to go from point to point. And the whole time it's like I was in a daze almost. I'm glad I didn't get into any accidents. I was just thinking about this, like trying to figure out how to solve a particular problem. And so it's kind of consumed me, I think, for quite a while. I never really put it down in a lot of ways. Yeah. But it was start to finish from the day that I kind of had the idea until the video. The announcement video, we could say is like one of the end points was a year and a half. But I say a year because I don't, I don't want to overestimate. It was a year of, you know, very, very constant effort. And there were large swaths of that year where basically no code got written because I would just try things and fail and try things and fail. And I just couldn't figure out how to get past certain roadbloc.

Josh Goldberg (39:53)

Sure, let's talk about those roadblocks. So how do you actually, you said that in webassembly there's no array concept or strings on top of that. Objects really, it's all just bytes, bits. How do you work with that in the type system then? How does that actually function?

Dimitri Mitropoulos (40:12)

I don't know. It's hard for me to reason about the pieces. I mean, I think the answer concretely is an extremely, extremely overdone test suite. So the real hero of this project is the test suite. Because I, from the very beginning, from the first keystrokes were tests. I wrote excessive, and I knew they were, but I wrote excessive, excessive tests. I did fuzz testing, which is a, where you kind of create random inputs and validate them so that you know, you're not succumbed to the things that you can only think of, you know, you might hit. And I did actually the fuzz testing caught a few things. So it was good. But I was really, really careful to be very, very sure about having tons and tons of tests for every single action at every single point. And that became brutal because I actually did have to rewrite the engine three times. Well, the third time was the. I didn't rewrite it three times, I rewrote it twice. There were three versions of the engine. So like it all uses binary numbers, for example, under the hood, and the numbers are stored as strings. But I didn't want to do that. I just really didn't want to do that. It seemed very complicated and I don't know a lot about binary arithmetic and stuff. Like, I just thought there might be a way to cheat and get by without having to do that. Because after all, like I said, all I was looking for is the reason this can't work. So if I can find some other core problem that it hits, I won't have to go through all the trouble of doing the binary numbers. So I know this is like a non answer to your question, but I don't think there were any specific things that I can point to to say this is the project. Because really what it was is just tons and tons of small building blocks. Like we were talking about the main function abstraction. Like that's one of them, right? Figuring out how to call that main function. So let's spent a couple days on that and then it was done. And then that's it. I never really had to fix that one again. But there was just tons and tons of little problems that kind of fanned out. Every time I solved one, it would create five more. Then I would solve those and they would each create five more. And then eventually, if you just keep trucking away, sometimes it just works.

Josh Goldberg (42:08)

So talking about one of those problems, you have to do some kind of binary arithmetic in this system, right? Like you're manipulating the numbers used internally to the webassembly runtime. How does that work then? In types?

Dimitri Mitropoulos (42:22)

So the whole engine is built off of three things, and they're very simple things. Number one is the ability to Add a character to a string. Number two is the ability to remove a character from a string. And number three is the ability to look through the current values in a string and change them. That's it. That is all I needed to be able to do this. Everything is built off of that. And there's lots of tricks that I didn't come up with that are, you know, like, it turns out that. And this, this sounds really funny when you first hear it. It sounded funny to me anyway, that you don't have to do subtraction because you have addition and you have a way to make a number negative. So if you want to subtract, you just add like A plus negative B. And that is subtraction. So but you didn't actually have to implement some kind of subtraction routine. So the subtraction code, that's all it does, it just uses the addition code. And then there's a way to make a number negative. It uses that code. There you go. Now you've done subtraction. How about that? So I think like that's the concept is like you're kind of looking through, you can imagine in your mind a bunch of zeros and ones stuffed next to each other in a string and you're kind of looking through them and doing some kind of work exactly the way that we were taught to do math in like grade school, elementary school. So, you know, that's one of the reasons the numbers all had to be reversed is because if you're thinking about how you add two numbers together, well, you know, if you have a carry, because you hit the limit of your binary versus decimal anyway, you hit the limit of the, whatever how many digits you have in the number system that you're counting with, whether it's 10 for decimal and 2 for binary. So you go from one side to the other. And it's just how it works.

Josh Goldberg (44:06)

But yeah, okay, so like let's take up an example of this then. Let's say you're writing a type to do one of these very foundational pieces of the logic. What is the type taken then?

Dimitri Mitropoulos (44:16)

Yeah, so let's use a specific example. Let's use a four bit number. So 0, 0, 0, 1. That's one in binary, right? And you have four bits. So 0, 0, 0,. If you want to add another number to that, you would take a second type parameter. So you have A and B. So 0, 0, 0, 1 and then 0, 0, 0, 1. So we're adding 1 and 1. One plus one we know equals two but in binary you don't have two. Actually, you would have to. If you add those, you know, think of putting those numbers over each other, then what you're going to do is you're going to carry. So the rightmost digit is going to be a zero now and the next digit is going to be a one. So the result is 0, 0, 1, 0. Yeah, you got it. So what you're going to do is you're going to take A and in your type you're going to loop through the values of A. So the first value of A now we were reversed now. Okay, so the first step is actually to reverse both numbers. So you have to do that. So now we're already into some weird territory because now the number as far as what the typescript is being fed is 1, 0, 0, 0. Everything is in reverse. Now we're in reverse land. We're in the Stranger Things upside down. So we take that one and we also inside of it we nest another loop where we're looping through the characters of B. And then inside of that we compare values and we make choices. So we're going to be fed. There's another function that just gets one character at a time from each side. And it's going to in the beginning get the number one from A and the number one from B. And then it's going to say, okay, I know I've been told, I've been pre coded to say that when I get those two there's only four combinations anyway. So I actually just made a lookup table of the results. I'm going to get those two values, I'm going to return this result, I return a zero, and then there's some special way that I can communicate that I have a carry. And then the greater loop that's going to return and the greater loop's gonna go, okay, great, I have my first digit, it's zero. I'm gonna recurse, I'm gonna loop again, but I'm gonna tell it that from the last time I had a carry. And so next time it's gonna go through A is 0, B is 0, but it has a 1 because there's a carry from last time and so it knows how to work with that. And it will return, it will pass that to the the function again, same one, and it will return the value one. So we did zero. Now we did one. We'll do the next part again because there's no carry and both values are zero. So zero, zero. Now we have zero, one, zero, zero, but it's still reversed so we have to reverse it again. So now we reverse it again and we have 0010, which is 2 in binary. So now we have completed the routine and we can return to whatever asks us to compute these two values.

Josh Goldberg (47:04)

And it's that times a million. A large set of those instructions comprise this engine that you've written per the webassembly assembly spec. Right.

Dimitri Mitropoulos (47:13)

The number we just gave has 4 bits, but a 64 bit number. I mean it maybe sounds like trivial to say this out loud, but a 64 bit number has 64 bits. And I don't know if anyone has done this, but like on your keyboard, just like type 64 characters, it's a lot of characters actually. It's like kind of overwhelming to me that when I first started working with them that like, wow, that's a huge number of characters just to store the value one. But yeah, that's how it works.

Josh Goldberg (47:40)

Wow, that's quite technically deep. I don't want to go too deep here because you have released a video not a time of recording, but a time of release. Diving into all this stuff that you went through with this, what you just described here, all the tooling you wrote around it, I would really encourage people to ideally watch that video, at the very least see the announcement video that you posted because it really is a fascinating piece of work just to list all the features. But in our last remaining minutes in the in view, I want to take a further step back away from the technical side and talk about kind of the context around it. So you referenced releasing videos and being the founder of Michigan Typescript before and you've talked a lot about the technical side of helping developers. How does Michigan Typescript in your mind help developers in the non technical or the information sharing world?

Dimitri Mitropoulos (48:25)

I was angry for many years because I was trying to write Typescript libraries and do fancy things and I felt like I was working on stuff that was kind of cutting edge and there was like no resources for me. The TypeScript docs are explicitly like written without that use case in mind. They do mention a few for like a sentence for some very advanced features, but it's not the audience of the typescript docs. And then I love to watch videos and stuff and there's no creators making videos for advanced of types typescript stuff. And I kept really, really wanting somebody to do that and nobody would do it. I thought this is weird because TypeScript is sufficiently mature at this point. There's been enough there are people writing TypeScript for 10. I mean, I'm one of them in a way. You know, I've been writing TypeScript since 1.0, right? So there's enough of this typescript code in existence now that I think there's a place for people who are doing advanced stuff to get some resources to help them to learn from other people how they do it. Right. And I just really, really badly wanted that to exist and no one would do it. So I did it. I didn't want to do it. I still am looking. If somebody listening would like to take it over. I'm very interested. I will keep doing. I love doing it. It's fun for me, but it's not something that I. It wasn't in my bingo board, I guess, for my life to be doing this kind of stuff. And I don't consider myself a YouTuber. Michigan TypeScript has very, very few videos that are just me. I think there's only like, it's just the Doom videos. Basically this is the Doom videos. And like one other video we have other people that we're kind of interviewing and I, you know, play the, the interviewer to do that. And somebody needs to. But I view it more as like a collective personally. Like, I think it's. There's a lot of people who have helped out with it by nature of the fact that we have like, I think in 20, like last year or year and a half ago, we had like 60 people on the channel. I counted in one year. So that's a lot of people. Not me, you know, 60 non Dimitri people. So I think that motivates me to continue. But I don't know, I. I found out actually for anybody thinking of doing a similar thing in your own. It doesn't have to be typescript, but I think you have to go into it with the right reasons if you're going to do service the other end of the industry, that is to say like not beginners. Because if you think of like a funnel, like a marketing funnel, there are far, far, far fewer people who really will sit down. Like everyone says and thinks that they would sit down to watch a one hour, like blow your mind, you know, technical deep dive. But the reality is almost no one will, including me. By the way, there's lots of stuff on my wish list that I would love to sit down and watch and learn about, but I just literally can't. So in a way, I'm not a target audience either, I suppose you could say, because I don't have the time to watch some of the, you know, we have many hour long videos doing very advanced deep dives. But I like the idea that it exists. I like the idea that someone can learn that if they want to. And it's motivating for me. You know, we have a video that I'm proud of on distributive conditionals and I'm not going to explain what it is here, but it's a very advanced typescript feature that has basically nothing blog posts. It's like basically nothing written or done about it. But if you're a library author, I think you kind of need to be aware of what's going on and how this works. It's a thing that I've shown to people and they've said, wow, I knew that was something weird there. I hit that before but I couldn't figure out what was going on. It just seemed weird. It seemed unpredictable. It's like, no, it's not unpredictable. Everyone knows this about software. You know, that software is not unpredictable. However, where would someone go to learn this? And so I'm very proud that we have a video about like step by step teaching. It's only eight minutes long, so it's I think very consumable in that way. Teaching how to make sense of these things. And yeah, I find that very motivating to have that up there. But I personally don't enjoy the spotlight. It's fun to talk about these things, but if I could go back, I think I would have first learned to, you know, operate a, like a puppet and maybe I would have done the vtuber thing or I would have had like a puppet talking instead of my face because I don't care to be personally known. I don't want a legacy in the typescript world or something like that. I just want this stuff to exist. It doesn't matter to me who makes it.

Josh Goldberg (52:15)

Yeah, it is interesting. All the Michigan typescript. Me too. Metropolis Branding online. There is no mention or no visualization of your face. The closest thing is Cookie Monster this one. Yeah, but what's coming next? What are you going to do now that doom is, you know, out there?

Dimitri Mitropoulos (52:34)

Nothing. Yeah, I think I'm just going to, going to take a break. I don't think this is going to be something, something that I can ever do. Some people have asked me like, oh, what's your next project? And it's like, yeah, it's not going to be anything like this. This is a lightning in a bottle situation. I, I think I happen to be in the right place at the right Time. And that's really what this comes down to. You know, I knew a bit about advanced type level programming, enough to make me think I could figure out the reason why it wouldn't be possible. And I didn't know enough about any of the other parts of this to ward me away. If I knew what I knew now, I would never try. So I think my career is definitely downhill from here. I can't imagine any other way. I will say there's two projects that we're going to be working on next with Michigan Typescript that are going to be a bit different. One of them is with Dan Vanderkam. So Dan has a book called effective typescript and the subtitle of the book is 83 specific ways to improve your typescript. And I saw that and I ordered the, I pre ordered the book and I was very excited and I know Dan and I think you do too. He's a wonderful, wonderful person. So I was like, Dan, this is, I reached out to him, was like, this is perfect. We gotta make a video series on each of the 1,83 ways. We'll make like a shorts series. So it's not gonna be long form, you know, hour long content. But he already did all the work of compiling all that stuff and it's like perfect format to translate into videos where we can say, here's the, you know, item number 55, item number 62. So Dan and I are going to be making videos on that sometime. The next project that I'm going to be working on is actually sort of similar. So maybe people are going to get tired of Michigan Typescript because it's. These are both longer. 83 is a lot. And then also there's this other one, Andrew Branch and I are, I'm not trying to make an announcement, but the plan is right now to make a video for each TS config option. I think this is something that advanced users need to understand really deeply. But there's a lot of stuff going on with the TS config and there's a lot of options. I don't know, dozens and dozens. I don't, I don't think it's a hundred, but maybe it is. Maybe it's close by now. It feels like 100 some days and so we're going to make a video. Andrew is on the Typescript team and he's a world expert and one of the hardest parts of JavaScript and TypeScript, which is module resolution. And he's going to help, I think a lot of people by he's already done some such, you know, such great work. He has long documents he's put together. But we're going to be doing some work on explaining what all of these things are in a format that I think you can reach out and access if you're facing it. So if you get some error and you think it's about some particular tsconfig option, you'll have a place where you could just go watch a video that explains what that is in like two or minutes or something like, you know, two or three minutes. That is going to be handy to just have on access. So yeah, I think that's going to be exciting. And I like content like that too because it's kind of like it doesn't require a lot of planning because the work has already been done by their book author or Typescript team in these two cases. So that's what's up next.

Josh Goldberg (55:21)

I would love to keep talking with you and dive more into all the fun parts of Typescript and Doom and Michigan Typescript, but unfortunately we're about to run out of time. One last question, area before that. In the video, you have a split second view of you playing musical instruments. Did you yourself record the Doom video music?

Dimitri Mitropoulos (55:43)

I did, yes, but it's not the one that doesn't end up in the video. So what's funny, maybe I'll release it sometime. All the music on Michigan Typescript is open source and that means you can go on our GitHub and find there's a music repo and all the music we use until that video was like literally every sound effect and everything was created just for Michigan Typescript because I'm very paranoid of, you know, copyright strikes and stuff and you know, hosing the whole channel. I have friends, I have a friend that had thousands of videos and he was doing it for 10 years and the channel got taken down because he did like a cover of an Eagles song like Hotel California or something like that. And yeah, they just shut down his channel, deleted every video and like his life's work is just destroyed. So I'm very nervous about that. Anyway, I did create it and I did record it and make a little kind of like music video. And I thought I would fit that in. But you know how it goes in software projects. Something, you know, scope has to get cut and despite the fact that I've recorded, I think it's like 85% of the song. I mean almost the whole song. And it sounds really good. I'm very happy with it and I, you know, recorded all the instruments and did video, like recorded myself playing all the instruments and everything else. It just, you know, time. It's like the extra 15% it would have taken. I really needed to just get the video released. And I decided that I would cut the scope the moment I found out that Bethesda, the owner of that track. So that track is made, it's from Doom Eternal. It's a doom music. And Bethesda has a specific written policy that you can use that music in the context that I used in that video. So I can't just publish the music with like, you know, a static art and then like as music. But I can use it in the context of some other video that has commentary and stuff, which obviously it does. And when I saw that, I thought, okay, well I can't. If there's a copyright strike, I can just point to that license that I've been granted and everything will go away and it'll be okay. And I deleted from the video my homemade track. But that's how it goes, I guess, sometimes. And then the video was already there of me, because that's the joke in the video. I say I didn't do this because I have no other way to play Doom. And the joke is I'm literally physically playing the Doom music, you know, so that's, that's why it's there where it is. And yeah, it's a little kind of visual double entendre. So, oh well, maybe I'll put it out someday. I don't, I don't know why anyone would care because the original is so awesome. But yeah, that's why it's there.

Josh Goldberg (58:04)

Completely unrelated to typescript, you were in a metal band at some point. Is that where you learned to play all these different parts of the song?

Dimitri Mitropoulos (58:11)

Yeah, I've been in many bands. I was in a Tom Petty cover band as well at one point. I don't even like Tom Petty, but it was a fun band to be in. You know, I think doing other things and having other pursuits in life is a very important element to being proficient in a specific thing. I think that people who go deep in a particular area often, I think get hamstrung eventually you are going to be restricted at some point if you keep pushing. It's important to do other things to, you know, people say touch grass. Well, I, I, I think there's a lot you can do that doesn't involve grass. I don't think. I, I think we hyper fixate on being outdoors and some people are really Great. Actually, Dan Vanderkam is a great example. Dan is a very, you know, established hiker and he has like a hiking blog. And it's very, I mean, he's like, really goes for it. It, it's amazing to read his, you know, see pictures of mountaintops that he's been on and stuff. So I have nothing against that. I've done some hiking myself and I love it. But I think that doing completely other things in life, having totally separate hobbies, can create synergies that you just can't predict. And it's worth it to do other things. It will make you a better software engineer. If you learn to cook or if you learn to knit or whatever. It doesn't have to be something. These are, you know, hiking, cooking and knitting are, you know, prototypical hobbies. But it doesn't have to be hobbies. You know, it can be volunteering at a nursing home near you, which I personally have grown. You know, I worked, also worked in a nursing home as a speech pathologist for six months. And those experiences that I got come to my mind. Still, it's been a decade or more, I guess, and it put a lot of perspective in my head that I think I use as a software engineer. I think it's very important to do those kinds of things, do other stuff in your life.

Josh Goldberg (59:51)

So. Yeah, absolutely. Well, Dmitri, we're out of time, but this has been a wonderful interview. Thank you so much for coming on. If people want to learn more about you, Michigan Typescripts, any of the stuff you work on, where would you direct them? On the Internet.

Dimitri Mitropoulos (60:03)

Thank you for asking, but I'm not really accessible on the Internet. I think I'm on the Michigan Typescript Discord, so I guess you can find me there. But I don't have any social media or any other things. Never have. But if you're interested in Michigan Typescript and you want to learn more about advanced type level programming and those kind of things, definitely it's just Michigan Typescript. Most places on Twitter, I think it's MI TypeScript and you know, it's easy to find. I hope there's not a competitor in the SEO. So if you just search Michigan TypeScript plus whatever place you want to find us, I think that Discord Michigan TypeScript.com is an easy way to get to the Discord if you want to chat. And oh, also squiggle conf. We didn't talk about squiggle conf, which is kind of funny, but I'm very passionate about dev tools. Like we talked about and we have a conference, so you can come to Squiggle Conf. And the joke being, of course, that, you know, we're the people who make squiggles, right. The people who make dev tools. Often, the result, the output of our dev tool is a squiggle in somebody's editor or in their CI or something. So, anyway, that's another cool way to connect. And it's been very exciting experience doing that. I think a lot of people have enjoyed it. I've enjoyed it. So, yeah, those are the main ways.

Josh Goldberg (61:08)

Absolutely. Well, thank you again. For Software Engineering Daily, this has been Dimitri Mitropoulos and Josh Goldberg. Thanks for listening, everyone. Cheers.

Dimitri Mitropoulos (61:16)

See you later.