Running Doom in TypeScript with Dimitri Mitropoulos

November 25, 2025

60 min episode · 2 min read

Dimitri Mitropoulos

Episode

60 min

Read time

2 min

AI-Generated Summary

Published Dec 25, 2025

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?