Running Doom in TypeScript with 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.
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.
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 — FreeKeep Reading
More from Software Engineering Daily
A Rust Framework to Simplify Distributed Systems
Sep 10 · 50 min
Syntax
969: This guy is nuts (TypeScript Doom)
Jan 12
More from Software Engineering Daily
SED News: The NVIDIA-Hugging Face Deal, China’s Proxy Economy, the Open Weight Surge
Sep 8 · 52 min
Syntax
959: TypeScript on the GPU with TypeGPU creator Iwo Plaza
Dec 1
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?
A Rust Framework to Simplify Distributed Systems
SED News: The NVIDIA-Hugging Face Deal, China’s Proxy Economy, the Open Weight Surge
Moving Beyond RAG with Precomputed Context
The Death of Online Anonymity
TypeScript 7 and What Comes Next
Similar Episodes
Related episodes from other podcasts
Syntax
Jan 12
969: This guy is nuts (TypeScript Doom)
Syntax
Dec 1
959: TypeScript on the GPU with TypeGPU creator Iwo Plaza
No Priors: Artificial Intelligence | Technology | Startups
Jul 31
Building an Autonomous Enterprise for Real-World Services with Netic Founder Melisa Tokmak
Latent Space
Jul 21
🔬Causal Models Need Causal Data - Xaira’s X-Cell model for Drug Discovery (Bo Wang & Ci Chu, Chief Discovery Officer & Chief AI Scientist)
Eye on AI
Jul 7
The Biggest AI Security Problem Isn't the Model. It's This. | Devvret Rishi
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 DigestNo credit card · Unsubscribe anytime