Bun, JavaScript, और TCO

मूल लेख ↗ Hacker News चर्चा ↗

JavaScript में tail call optimization — खासकर ECMAScript spec द्वारा अनिवार्य “proper tail calls” — पर फिर से ध्यान जा रहा है क्योंकि Bun (JavaScriptCore के माध्यम से) इसे support करता है जबकि V8 और SpiderMonkey जैसे बड़े engines इसे बड़े पैमाने पर नहीं करते। Commenters recursion-heavy या functional styles के लिए इसके व्यावहारिक लाभों (जैसे stack overflows से बचना, CPS, state machines) की तुलना debugging कठिन होने, stack semantics बदलने, और JS array operations तथा mutation के साथ जोड़ने पर खराब performance जैसे drawbacks से करते हैं। यह चर्चा व्यापक सवालों को भी छूती है: क्या JavaScript को functional paradigms की ओर और झुकना चाहिए, engines को spec का कितना पालन करना चाहिए जब वह observable behavior बदलता है, और Bun में काम करने वाला code Node या Deno में fail या धीमा होने का जोखिम कितना है।

“TCO” का अर्थ और शीर्षक से अपेक्षाएँ

  • इस संदर्भ में, TCO = Tail Call Optimization (या “proper tail calls”) है, न कि Total Cost of Ownership या कोई अन्य संक्षिप्त रूप।
  • कई पाठकों ने शुरुआत में Bun/JS के लिए Total Cost of Ownership पर लेख होने की उम्मीद की थी और वे थोड़ा निराश हुए, लेकिन फिर भी उन्हें functional angle दिलचस्प लगा।

Recursion, TCO, और JavaScript semantics

  • Tail-call optimization को केवल एक “optimization” से अधिक के रूप में प्रस्तुत किया गया है: जब यह guaranteed हो, तो यह tail calls के लिए stack growth को रोककर language semantics बदल देता है।
  • Proper tail calls ECMAScript spec में strict mode के लिए अनिवार्य हैं, लेकिन अधिकांश बड़े engines (V8, SpiderMonkey) इस हिस्से को अनदेखा करते हैं। WebKit/JSC और Bun (जो JSC का उपयोग करता है) इन्हें implement करते हैं।
  • कुछ लोगों का तर्क है कि TCO की कमी expressiveness को सीमित करती है (जैसे CPS, mutually recursive functions, tail-calling functions के रूप में encoded state machines)।

Major JS engines TCO से क्यों बचते हैं

  • मुख्य रूप से cited issue: developer experience. TCO stack frames को elide कर देता है, जिससे stack traces, debuggers, और error-reporting tools वास्तविक call structure के प्रति कम faithful हो जाते हैं।
  • security/realm-boundary complications और implementation complexity का भी उल्लेख है।
  • दूसरे लोग counter करते हैं कि debuggers shadow stacks या metadata बनाए रख सकते हैं; Scheme और Lua दिखाते हैं कि यह हल किया जा सकता है।
  • कुछ इसे आंशिक रूप से “political” या anti-functional, न कि केवल technical resistance मानते हैं।

Performance और code style पर बहस

  • एक बड़ा अंतर इस बीच बताया गया:
    • Tail-recursive लेकिन allocation-heavy code (जैसे हर call पर spread के साथ नए arrays बनाना), जो TCO होने पर भी asymptotically खराब है।
    • Imperative loops या mutation-based versions, जो JS engines में बहुत तेज़ और अधिक memory-efficient हैं।
  • कई प्रतिभागियों को recursive/ternary उदाहरण एक simple loop की तुलना में पढ़ना कठिन लगता है; कुछ इसे “clever but illegible” कहते हैं।
  • अन्य लोग functional style का बचाव करते हैं और कहते हैं कि जो लोग इसके अभ्यस्त हैं उनके लिए यह पूरी तरह readable है, लेकिन मानते हैं कि JS की arrays और GC naive functional patterns को inefficient बनाते हैं।

JS में TCO का दायरा और व्यावहारिकता

  • कई लोगों का तर्क है कि purely functional languages में TCO आवश्यक है, लेकिन multi-paradigm, mutable language में, जहाँ loops idiomatic हैं, यह कम critical है।
  • चिंता: Bun/JSC TCO पर निर्भर code Node/Deno में stack-overflow कर सकता है; runtime checks या comments की सलाह दी जाती है।
  • Python का जानबूझकर TCO न होना (इसी तरह debugging/readability कारणों से) एक समान उदाहरण के रूप में उल्लेखित है।

Bun- और engine-specific नोट्स

  • Bun एक special $vm interface के माध्यम से tail calls के लिए JSC intrinsic expose करता है, लेकिन इसका misuse process crash कर सकता है।
  • Bun की speed की प्रशंसा की गई है (जैसे dependency installs); Node/Next.js app router के साथ runtime parity अभी पूरी नहीं है, लेकिन roadmap पर है।
  • AWS Lambda के लिए, Bun custom runtimes/containers के माध्यम से उपयोग किया जा सकता है, लेकिन Node जैसी cold-start optimizations के बिना।