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.
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
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
Syntax
Jan 12
969: This guy is nuts (TypeScript Doom)
Syntax
Dec 1
959: TypeScript on the GPU with TypeGPU creator Iwo Plaza
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
The Diary of a CEO
Jun 29
Women’s Fitness Expert: What You NEED To Know About Dieting & Exercise | Dr. Stephanie Estima
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