TypeScript types पर चलने वाला DOOM [वीडियो]

• 1993 का गेम DOOM रनटाइम कोड से नहीं, बल्कि सिर्फ TypeScript type system से boot किया गया और उसका पहला फ्रेम आउटपुट किया गया — यह एक प्रयोग है
• पहले फ्रेम तक पहुँचने के लिए TypeScript type checker ने 12 दिनों में 3.5 ट्रिलियन lines, कुल 177TB प्रोसेस किए, जबकि शुरुआती अनुमान 1.25PB और 3 महीने से अधिक का था
• मुख्य implementation एक WebAssembly virtual machine है जो types से बनाई गई है; इसमें DOOM के लिए ज़रूरी 116 instructions को type-level logic से implement किया गया और 1.8 करोड़ instructions evaluate किए गए
• development के दौरान compiler की recursion, union, tuple और deep type instantiation limits हटा दी गईं, लेकिन अंतिम परिणाम users के चलाने योग्य शुद्ध TypeScript के रूप में रहा
• यह काम सामान्य apps की type check scale से बहुत आगे था, इसलिए मौजूदा developer tools लगभग बेअसर हो गए और 12,364 tests व custom tools खुद बनाने पड़े

---

TypeScript type system के अंदर बनाया गया कंप्यूटर

• DOOM सामान्य JavaScript execution से नहीं, बल्कि TypeScript type system के अंदर ही चलता है
• लक्ष्य था कि किसी चालबाज़ी या दूसरी execution language के बिना, सिर्फ types के सहारे दूसरे programs भी चला सकने वाली WebAssembly virtual machine बनाई जाए
• type-level computer में execution के लिए ज़रूरी बुनियादी घटक types के रूप में मौजूद हैं
  • RAM
  • disk space
  • call stack
  • subroutine
  • memory pointer
  • execution context
  • custom developer tools
• DOOM चलाने के लिए ज़रूरी 116 WebAssembly instructions को TypeScript types के रूप में logic से implement किया गया
• सिर्फ इसी logic से 1.8 करोड़ instructions बने, जिन्हें type checker को एक-एक करके evaluate करना पड़ा, और हर instruction system की एक अलग machine state को दर्शाता है

पहले फ्रेम तक का पैमाना

• पहला DOOM फ्रेम पाने के लिए 3.5 ट्रिलियन lines के types चाहिए थे, और कुल type size 177TB थी
• TypeScript compiler TSC को 12 दिनों तक लगातार चलाकर गेम boot किया गया और पहला फ्रेम प्राप्त किया गया
• शुरुआती गणना के मुताबिक कंप्यूटर को 1.25PB के TypeScript types प्रोसेस करने थे और runtime 3 महीने से अधिक होने की उम्मीद थी
• अत्यधिक optimization के बाद इसे घटाकर 177TB और 12 दिन तक लाया गया
• सामान्य apps में TSC type check आमतौर पर 2 लाख से 5 लाख type instantiations के स्तर पर होता है, लेकिन इस काम में 12 दिनों तक हर सेकंड 2 करोड़ instantiations लगातार होती रहीं
• अंतिम output एक TypeScript object है, जिसमें हर value pixels की एक line को दर्शाती है
  • output frame 320×200 है
  • कुल 128,000 pixels का ASCII frame है
• keyboard input से गेम को नियंत्रित करने का तरीका भी मौजूद है

development के दौरान हटाए गए TypeScript सुरक्षा उपाय

• अंतिम परिणाम users के सीधे चलाने योग्य शुद्ध TypeScript है
• इस प्रयोग को संभव बनाने के लिए TypeScript compiler में बदलाव करके कई limits हटाई गईं
  • type comparison के समय अत्यधिक stack depth limit हटाई गई
  • बहुत गहरी या संभवतः infinite type instantiation limit हटाई गई
  • union और tuple के maximum size को Infinity पर सेट किया गया
  • output truncation limit हटाई गई
  • TypeScript की मशहूर recursion limit हटाई गई
• कंप्यूटर की अपनी stack limit भी बढ़ाई गई
• इन सुरक्षा उपायों के हटते ही type checker आसानी से 100GB memory इस्तेमाल कर सकता था
• इन limits को हटाने की कीमत भी भारी थी
  • import typo जैसी मामूली समस्या भी infinite loop बना सकती थी
  • heap allocation पूरी memory खा कर पूरे सिस्टम को crash कर सकती थी
  • stack traces बहुत विशाल हो जाती थीं, और ज़्यादातर failure बस रुक जाने के रूप में होता था

DOOM चलाने के लिए अतिरिक्त रूप से बनाई गई चीज़ें

• 6 महीने के काम के बाद छोटे C programs चलाए जा सकते थे, लेकिन DOOM चलाने के लिए इससे कहीं अधिक implementation की ज़रूरत थी
• DOOM के सभी components को types में encode करना पड़ा
  • game maps
  • textures
  • sprites
  • sound
  • enemy AI
  • weapons
  • items
  • physics engine
  • audio subsystem
  • in-game text
• type level पर runtime-जैसी क्षमताएँ भी implement की गईं
  • garbage collector
  • L1 CPU cache
  • runtime dead code elimination
  • real-time memory compactor
  • stack underflow protection के लिए depth counting वाला global value stack
  • dynamic dispatch table
  • module-level global variables
  • labeled goto
  • type-level exception handling
  • runtime stack tracing
  • full core dump
• linear RAM को 32-bit address keys और byte values वाले एक विशाल unsortable object के रूप में दर्शाया गया
• type user space में type evaluation को अस्थायी रूप से रोकने का तरीका खोजा गया, जिससे core dump, exception handling और stack tracing संभव हो सके

tool limits और implementation constraints

• file size अधिकतम 1GB तक चाहिए थी, जो Prettier की संभालने योग्य सीमा से बाहर थी
• language server integration या linter तुरंत crash हो जाते थे, और व्यवहार में सिर्फ syntax highlighting ही किसी तरह काम करती थी
• engine का internal implementation string literals में संग्रहीत two's complement binary numbers से बना है
• TypeScript strings को सिर्फ बाएँ से दाएँ traverse कर सकता है, इसलिए सभी binary algorithms को उल्टी दिशा में implement करना पड़ा
• engine के अंदर arrays, objects, strings, booleans नहीं हैं; सिर्फ binary numbers इस्तेमाल होते हैं
• DOOM सिर्फ 64-bit और 32-bit integers का उपयोग करता है, और वे integers न signed थे न unsigned — इसे समझने में ही एक दिन लग गया
• निर्माता को शुरुआत में ज़रूरी ज्ञान का 10% भी नहीं पता था, और उसे अपने tools बनाने पड़े, 12,364 tests हाथ से लिखने पड़े, और कई programming languages नई सीखनी पड़ीं