Bun के पास JavaScriptCore में shared-memory threads जोड़ने वाला एक खुला PR है

PR का संदर्भ और दायरा

• यह PR Bun के JavaScriptCore fork में shared-heap threads जोड़ता है, जो पहले प्रकाशित “Concurrent JavaScript” डिज़ाइन पर आधारित है।
• यह upstream WebKit के विरुद्ध नहीं है, बल्कि Bun के अपने, बहुत अधिक संशोधित fork के लिए है।
• लेखक पुष्टि करता है कि PR का विवरण पूरी तरह LLM-generated है और यह बदलाव Bun के हाल के Rust rewrite से भी अधिक जटिल है।

Shared-Memory Threads बनाम मौजूदा JS Concurrency

• कई टिप्पणीकारों का कहना है कि JS में पहले से ही workers, SharedArrayBuffer, और Atomics के जरिए concurrency मौजूद है।
• मुख्य अंतर: आज shared memory opt-in है और केवल data-only है; यह PR पूरे object heap को डिफ़ॉल्ट रूप से shared बना देता है।
• समर्थकों का तर्क है कि इससे “true” multithreading और अधिक ergonomic high-performance patterns संभव होते हैं; आलोचकों का कहना है कि यह mutex-based shared memory को सामान्य बनाता है, जो ऐतिहासिक रूप से bug-prone मॉडल है।

Correctness, GC, और Performance संबंधी चिंताएँ

• prototype chains, property definition, और सामान्य रूप से JS object graphs पर race conditions को लेकर गंभीर चिंता है।
• कुछ लोग कहते हैं कि यह “for the masses” के लिए सुरक्षित नहीं है और JS का single-threaded मॉडल एक protective constraint था।
• GC एक बड़ी चिंता है: वर्तमान version stop-the-world collection का उपयोग करता है, जिसके बारे में लोग कहते हैं कि यह latency को नुकसान पहुँचाएगा और “no single-threaded slowdown” के दावों को कमजोर करता है।
• ऐतिहासिक नोट: अन्य engines में पहले के multi-threaded JS प्रयास GC और interop complexity के कारण वापस ले लिए गए थे।

LLMs, विशाल diffs, और Reviewability

• यह PR लगभग 270k lines का है, करीब 1,800 files में फैला हुआ; कई लोगों को यह व्यावहारिक रूप से unreviewable लगता है।
• लोग LLM-written PR description style की आलोचना करते हैं (बहुत लंबा, “honesty” branding, em-dash heavy)।
• संशयवादी तर्क देते हैं कि LLMs concurrency में विशेष रूप से खराब होते हैं, और LLM code की LLM review भरोसा नहीं जगाती।
• अन्य लोग जवाब देते हैं कि इंसान भी threading में अच्छे नहीं हैं, कि व्यापक tests, TSAN, और stress tests मदद करते हैं, और LLMs महत्वाकांक्षी prototypes संभव बनाते हैं जिन्हें इंसान बाद में refine कर सकते हैं।

Bun पर भरोसा और production use

• कुछ लोग Bun के DX, “batteries-included” tooling, और speed की प्रशंसा करते हैं; अन्य memory leaks, unstable behavior, और unresolved bugs की रिपोर्ट करते हैं।
• Bun का व्यापक AI-driven development (Rust rewrite, issue/PRs संभालने वाले AI bots) कुछ लोगों का भरोसा कम कर रहा है; वे वापस Node पर माइग्रेट करने की योजना बना रहे हैं या Deno पर विचार कर रहे हैं।
• चिंता यह है कि बड़े AI-generated changes और सीमित human oversight Bun को एक भरोसेमंद runtime foundation के रूप में अनुपयुक्त बना देते हैं।

व्यापक विचार: Threads, Databases, और Language Choice

• इस पर बहस है कि क्या JS/TS SQL databases जैसे high-performance, multithreaded systems के लिए अच्छा fit है।
• कुछ का तर्क है कि TS + Bun + threads प्रतिस्पर्धी DBs को support कर सकते हैं; अन्य कहते हैं कि JS की performance tier और memory model इसे C/C++/Rust की तुलना में अवास्तविक बनाते हैं।
• कई लोग message-passing, actors, या process-based models को shared-everything threading पर प्राथमिकता देने की बात दोहराते हैं, maintainability और reliability का हवाला देते हुए।