Skip to main content
Software Engineering Daily

Running Doom in TypeScript with Dimitri Mitropoulos

60 min episode · 2 min read
·
Dimitri Mitropoulos

Episode

60 min

Read time

2 min

Topics

Software Development, Product & Tech Trends, Crypto & Web3

AI-Generated Summary

Key Takeaways

  • TypeScript strict mode: Enable exact optional property types in tsconfig to distinguish between absent properties and properties with undefined values. This prevents type conundrums for library users and improves code quality without affecting users who don't enable it, making it essential for enterprise codebases.
  • Type system complexity limits: Avoid writing types longer than five to ten lines in production code. Complex type-level programming creates team friction and maintenance burden. Use runtime validators like Zod or AJV instead of attempting perfect compile-time type safety for dynamic data like API responses that can change unpredictably.
  • WebAssembly runtime fundamentals: WebAssembly operates only on 32-bit and 64-bit numbers without native arrays, strings, or booleans. All higher-level abstractions use encoding schemes like C-style strings with zero-byte sentinels. Understanding this enables debugging performance issues and implementing cross-compilation solutions in production environments.
  • Binary arithmetic implementation: Build computational systems using three primitives: add character to string, remove character from string, and transform existing characters. Subtraction becomes addition with negation. This approach enabled implementing 64-bit arithmetic operations entirely within TypeScript's type system using reversed binary string representations.
  • Test-driven type development: Write excessive test suites with fuzz testing before implementing complex type-level logic. Random input validation catches edge cases human thinking misses. This methodology enabled three complete engine rewrites while maintaining correctness, proving essential for projects pushing language boundaries beyond documented capabilities.

What It Covers

Dimitri Mitropoulos explains how he ported Doom to run entirely in TypeScript's type system using 3.5 trillion lines of types, requiring 90GB RAM and one year of eighteen-hour programming days to complete.

Key Questions Answered

  • TypeScript strict mode: Enable exact optional property types in tsconfig to distinguish between absent properties and properties with undefined values. This prevents type conundrums for library users and improves code quality without affecting users who don't enable it, making it essential for enterprise codebases.
  • Type system complexity limits: Avoid writing types longer than five to ten lines in production code. Complex type-level programming creates team friction and maintenance burden. Use runtime validators like Zod or AJV instead of attempting perfect compile-time type safety for dynamic data like API responses that can change unpredictably.
  • WebAssembly runtime fundamentals: WebAssembly operates only on 32-bit and 64-bit numbers without native arrays, strings, or booleans. All higher-level abstractions use encoding schemes like C-style strings with zero-byte sentinels. Understanding this enables debugging performance issues and implementing cross-compilation solutions in production environments.
  • Binary arithmetic implementation: Build computational systems using three primitives: add character to string, remove character from string, and transform existing characters. Subtraction becomes addition with negation. This approach enabled implementing 64-bit arithmetic operations entirely within TypeScript's type system using reversed binary string representations.
  • Test-driven type development: Write excessive test suites with fuzz testing before implementing complex type-level logic. Random input validation catches edge cases human thinking misses. This methodology enabled three complete engine rewrites while maintaining correctness, proving essential for projects pushing language boundaries beyond documented capabilities.

Notable Moment

Mitropoulos never believed the project would succeed until seeing Doom render on screen. He deliberately sought to prove TypeScript types couldn't run Doom, arguing Turing completeness means nothing without practical computation speed, proposing Doom completeness as the new benchmark for programming language capabilities.

Know someone who'd find this useful?

Episode Transcript

Doom has seemingly been ported to every electronic device imaginable, including picture frames, lamps, and coffee machines. The meme of it runs doom has become so widespread that it spawned the r slash it runs doom subreddit. Recently, Doom made headlines again for being ported to TypeScript. The project involved representing Doom entirely in TypeScript, three and a half trillion lines of types, 90 gigabytes of RAM to run, and a full year to complete. Dimitri Mitropoulos is the engineer who carried out this heroic feat. He's also a developer at Vercel, the founder of Michigan TypeScript and a cofounder of SquiggleConf. Dimitri joins the podcast with Josh Goldberg to talk about what it took to pull off one of the most mind bending TypeScript projects to date. This episode is hosted by Josh Goldberg, an independent full time open source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of The O'Reilly Learning TypeScript Book, a Microsoft MVP for developer technologies and a cofounder of SquiggleConf, a conference for excellent web developer tooling. Find Josh on Blue Sky, Fostodon, and .com as Joshua k Goldberg. With me today is Dimitri Metropolis, founder of Michigan TypeScript, cofounder of School Conf, and an all around interesting TypeScript individual. Dimitri, welcome to Software Engineering Daily. Hi. Thanks for having me. Excited to have you on, Dimitri. Just to start off, can you tell us how did you get into coding? Oh, I love it. Right with the deep questions. I've been programming since I was very young. I had my first email address when I was six, which I think even for these days is kind of cutting edge, but I don't think anyone really knew what the Internet was back then. I remember running to school and telling my friends, there's this website called Ask Jeeves, and you can just type in a question. It will give you the answer. It's so cool. Just go ask Jeeves, and it's like a butler there. My mom was in real estate, and I watched her do they weren't Excel. I think it was QuarkXPress formulas, and I think that was my first real I hope that's the name of the spreadsheet. It was some kinda, like, off brand Excel spreadsheet for technology. And I saw her writing formulas, and it was so interesting to me. And I think that was, like, the first exposure that I had to software engineering. And through my life, I did more and more stuff like that. I got interested in video games, and that interest propelled me to become interested in technology. I started building computers when I was, like, maybe nine or 10 to play, I don't know, Quake three Arena, or I'm not sure exactly. I don't remember all the games, DOS games in some cases. And that propelled me into high school where I started doing …

Get the full transcript (13,236 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all Software Engineering Daily transcripts →

You just read a 3-minute summary of a 57-minute episode.

Get Software Engineering Daily summarized like this every Monday — plus up to 2 more podcasts, free.

Pick Your Podcasts — Free

Keep Reading

Books, tools, and gear mentioned in this episode

SignalCast may earn commission on purchases via these links.

Tools

  • AJVRecommended
    Use runtime validators like Zod or AJV instead of attempting perfect compile-time type safety for dynamic data like API responses that can change unpredictably.
  • ZodRecommended
    Use runtime validators like Zod or AJV instead of attempting perfect compile-time type safety for dynamic data like API responses that can change unpredictably.

More from Software Engineering Daily

We summarize every new episode. Want them in your inbox?

Similar Episodes

Related episodes from other podcasts

Explore Related Topics

This podcast is featured in Best Cybersecurity Podcasts (2026) — ranked and reviewed with AI summaries.

Read this week's Software Engineering Podcast Insights — cross-podcast analysis updated weekly.

You're clearly into Software Engineering Daily.

Every Monday, we deliver AI summaries of the latest episodes from Software Engineering Daily and 192+ other podcasts. Free for one show.

Start My Monday Digest

No credit card · Unsubscribe anytime