React Compiler को Rust में पोर्ट करें

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

React Compiler का उपयोग और वास्तविक‑दुनिया का प्रदर्शन

  • कई टिप्पणीकार बताते हैं कि वे React Compiler का प्रोडक्शन में उपयोग कर रहे हैं (जैसे, बड़े ई‑कॉमर्स/मीडिया साइट्स, Unifi UI, मध्यम रूप से बड़े ऐप्स)।
  • बताए गए लाभ: रेंडर प्रदर्शन में स्पष्ट सुधार, अधिकांश memo/useMemo/useCallback को बिना रिग्रेशन के हटाने की क्षमता, और कम से कम एक मामले में पहले के Preact सेटअप से बेहतर प्रदर्शन।
  • कमियाँ: बिल्ड समय में वृद्धि, हालांकि कुछ लोग आधुनिक bundlers के साथ स्वीकार्य compile times देखते हैं; कुछ libraries (जैसे, MobX) के साथ असंगतता ने कम से कम एक कंपनी को rollback करने पर मजबूर किया, क्योंकि उन्हें मौजूदा codebase पर कोई स्पष्ट perf gain भी नहीं मिला।

Automatic memoization और safety

  • कुछ लोग subtle performance regressions और hidden dependencies के जोखिम के कारण automatic memoization के प्रति skeptical हैं।
  • अन्य लोग अच्छे अनुभव बताते हैं: ESLint lints गैर‑optimizable या non-hook-compliant code को flag करते हैं, incompatible libraries अपने-आप exclude हो जाती हैं, और compiler-generated memoization manual patterns की तुलना में अधिक granular और कम error‑prone है।
  • online compiler playground जैसे tools का सुझाव दिया जाता है ताकि देखा जा सके कि code कैसे transform होता है।

Rust क्यों, और port कैसे काम करता है

  • मौजूदा compiler TypeScript / Flow में था; Rust को speed, native binaries, आसान parallelization, और JS runtimes से independence पाने का तरीका माना जाता है।
  • memory safety को एक plus माना जाता है, लेकिन अधिकांश लोग raw performance और startup time को मुख्य प्रेरणा मानते हैं।
  • Arenas का उपयोग GC replacement के रूप में किया जाता है; कुछ लोग इसे अतिरिक्त complexity की बजाय वैचारिक रूप से सरल मानते हैं।

AST design: Babel बनाम Oxc

  • कुछ लोग सवाल करते हैं कि Rust port Babel-like AST को क्यों बनाए रखता है, जबकि Oxc के AST को क्यों नहीं अपनाता।
  • बचाव करने वाले तर्क देते हैं: कई consumers हैं, टीम ने पहले ही Babel की representation के आसपास logic बना लिया है, और वे केवल एक complex AST→HIR conversion को बनाए रखना चाहते हैं। पूरे ecosystem की सफाई बाद में की जा सकती है।

LLM-assisted Rust port: trust, tests और maintainability

  • कई लोग मानते हैं कि port बड़े पैमाने पर LLM-assisted था और इसे मजबूत test suite होने पर mechanical rewrites के लिए अच्छा मेल मानते हैं।
  • समर्थक: यदि यह हज़ारों tests (साथ में नए tests) पास करता है, और public APIs नहीं बदलते, तो यह एक व्यावहारिक जीत है; LLMs iterative “compare results, fix, repeat” में उत्कृष्ट हैं।
  • संदेहवादी: 120k-लाइन PRs इंसानों के लिए लगभग unreviewable हैं; “tests pass” gaps छिपा सकता है; future feature work जोखिम भरा हो सकता है यदि बहुत कम इंसान code को गहराई से समझते हों।
  • “cognitive debt” और उस trend को लेकर चिंताएँ जहाँ codebases प्रभावी रूप से केवल LLM मदद से maintainable बन जाती हैं।

Process, reviews और व्यापक विचार

  • कुछ लोग limited visible review और अतीत के React milestones की तुलना में कम public RFCs वाले बड़े PRs को लेकर चिंतित हैं।
  • अन्य लोग जवाब देते हैं कि language choice एक implementation detail है, और React का public contract स्थिर रहता है।
  • व्यापक बहस: dynamic बनाम static languages, Java/.NET बनाम Go/Rust native tools, और क्या LLMs Rust जैसी complex languages को उपयोग करने की बाधा कम करते हैं या “हटा” देते हैं।