Bun प्रोजेक्ट ने मई 2026 में Zig से Rust में एक बड़े कोड माइग्रेशन को पूरा किया, जिसमें 11 दिनों में 10 लाख से अधिक पंक्तियों के परिवर्तन और 6,778 कमिट्स हुए। माइग्रेशन के लिए 64 Claude इकाइयों का समानांतर उपयोग किया गया, जिससे 165,000 डॉलर की API लागत हुई। माइग्रेशन के बाद मेमोरी लीक समस्या का मूल स्तर पर समाधान हुआ, 2,000 बिल्ड्स के बाद मेमोरी 6.7 जीबी से घटकर 609 मेबीबाइट हो गई, प्रदर्शन में 2% से 5% की वृद्धि हुई, और बाइनरी फ़ाइल का आकार लगभग 20% कम हो गया। हालाँकि, कोड में लगभग 13,000 unsafe कीवर्ड हैं, जो समान प्रोजेक्ट्स की तुलना में 178 गुना हैं, 19 ज्ञात रिग्रेशन समस्याएँ मौजूद हैं, और 10 लाख पंक्तियों के परिवर्तन को मानवीय रूप से प्रत्येक पंक्ति की जाँच करके संभव नहीं है। वर्तमान में Bun को Anthropic द्वारा अधिग्रहित कर लिया गया है।

लेखक, स्रोत: InfoQ

मई 2026 में, बन प्रोजेक्ट ने सॉफ्टवेयर डेवलपमेंट के इतिहास में लगभग अद्वितीय एक बड़े पैमाने पर कोड माइग्रेशन पूरा किया।

इस स्थानांतरण को 3 मई को शुरू किया गया और 14 मई तक मुख्य शाखा में विलय किया गया, जिसमें केवल 11 दिन लगे। कोड लिखने में केवल 6 दिन लगे और पूरी प्रक्रिया खुली रही। हालाँकि, जैरेड समनर ने ब्लॉग पोस्ट लिखने में लगभग एक महीना लगाया, जो कोड लिखने के समय से कहीं अधिक है।

इस JavaScript रनटाइम में मूल रूप से 535,496 पंक्तियाँ Zig कोड थीं, टिप्पणियों को छोड़कर; इसके अलावा, लगभग 20% कोड C++ में लिखा गया था और कई C/C++ पुस्तकालयों को एम्बेड किया गया था। इसे Rust में AI की सहायता से पुनः लिखने की प्रक्रिया में 10 लाख से अधिक पंक्तियों के परिवर्तन, 6,778 कमिट्स शामिल थे, और Claude Code में लगभग 50 डायनामिक वर्कफ्लो चलाए गए।

समनर द्वारा प्रकाशित डेटा के अनुसार, इस पुनर्लेखन ने API स्तर पर 59 अरब अनकैश्ड इनपुट टोकन, 690 मिलियन आउटपुट टोकन और 720 अरब कैश्ड इनपुट टोकन पढ़ने में 165,000 डॉलर का खर्च किया।

समनर ने कहा कि यह वर्तमान तकनीक की सीमा है। उनका अनुमान है कि अगर 3 पूरी तरह से बन कोडबेस से परिचित इंजीनियर इस स्थानांतरण को हाथ से करें, तो लगभग एक साल लगेगा, और इस एक साल के दौरान, टीम लगभग नए फीचर्स, बग फिक्स और सुरक्षा फिक्स पर काम करने में सक्षम नहीं हो पाएगी।

इस पुनर्लेखन के बाद, Bun v1.3.14 अंतिम Zig संस्करण होगा, और Bun v1.4.0 पहला Rust संस्करण होगा।

1 परिणाम: 6.7 जीबी मेमोरी लीक से 609 एमबी स्थिरता तक

Bun शुरू में एक Zig प्रोजेक्ट था जिसका क्षेत्र बहुत व्यापक था: यह एक JavaScript और TypeScript ट्रांसपाइलर, बंडलर, पैकेज मैनेजर, टेस्ट रनर, मॉड्यूल रिजॉल्वर, HTTP और WebSocket क्लाइंट के साथ-साथ Node.js API स्तर को भी लागू करता है। इसी उत्पाद की विस्तारित प्रकृति के कारण Bun के CLI की मासिक डाउनलोड 2.2 करोड़ से अधिक है, और इसे Vercel, Railway, DigitalOcean, Claude Code और OpenCode जैसे प्रोजेक्ट्स या कंपनियों द्वारा समर्थित किया जाता है।

लेकिन इसी चौड़ाई के कारण बन को कुछ चुनौतियाँ भी आईं।

Bun v1.3.14 में, एक लंबे समय से चल रही समस्या थी: लगातार Bun.build() कॉल करने पर, मेमोरी लगातार जमा होती रहती और कभी रिलीज़ नहीं होती। प्रत्येक बिल्ड के लिए लगभग 3MB की मेमोरी लीक होती है, जो थोड़ी सी लगती है, लेकिन अगर आप एक डेवलपमेंट सर्वर चला रहे हैं जहां प्रत्येक रिक्वेस्ट एक बिल्ड को ट्रिगर करता है, तो मेमोरी धीरे-धीरे खा जाएगी और प्रक्रिया क्रैश हो जाएगी।

वास्तविक परीक्षण में, 500 बार बिल्ड के बाद मेमोरी उपयोग 1.9GB है, 1000 बार के बाद 3.5GB, 1500 बार के बाद 5.1GB, और 2000 बार के बाद 6.7GB तक बढ़ जाता है।

यह केवल कई मेमोरी समस्याओं का एक छोटा हिस्सा है। v1.3.14 की बग फिक्स लिस्ट में, समनर ने एक लंबी सूची दी:

zlib मॉड्यूल में .reset() को कॉल करने पर, यदि एक असिंक्रोनस .write() थ्रेड पूल में अभी भी निष्पादित हो रहा है, तो प्रक्रिया "हीप के बाद उपयोग" के कारण अवरुद्ध हो जाती है; http2 मॉड्यूल में नेस्टेड JavaScript कॉलबैक द्वारा हैश टेबल का पुनः हैशिंग होता है, जिससे आंतरिक स्ट्रीम पॉइंटर अमान्य हो जाते हैं; UDPSocket.sendMany() के दौरान पुनरावृत्ति करते समय, यदि उपयोगकर्ता कोड द्वारा valueOf या toString कॉलबैक के माध्यम से सॉकेट की कनेक्शन स्थिति बदल दी जाती है, तो बाहरी लिखने की समस्या होती है; crypto.scrypt में आउटपुट बफर के आवंटन में विफलता होने पर, कॉलबैक और सुरक्षित पासवर्ड बफर कभी मुक्त नहीं होते;......

इन बग्स की सामान्यता स्पष्ट है—वे लगभग सभी एक ही मूल की ओर इशारा करते हैं: एक ही सॉफ्टवेयर में GC और हस्तांतरित स्मृति प्रबंधन को मिलाना।

आधुनिक इंजन जैसे JavaScriptCore (और V8) अपवाद प्रबंधन और GC के लिए अत्यंत कठोर नियम रखते हैं, जबकि Zig C भाषा की तरह मेमोरी का स्वचालित प्रबंधन नहीं करता। जब ये दोनों पैराडाइम एक ही प्रक्रिया में होते हैं, तो प्रत्येक मेमोरी आवंटन की पंक्ति-दर-पंक्ति समीक्षा की आवश्यकता होती है: ये बाइट्स कहाँ मुक्त होते हैं? कैसे सुनिश्चित किया जाए कि केवल एक बार ही मुक्त किया जाए? JavaScript अपवाद सही ढंग से जांचे गए हैं? इस GC द्वारा प्रबंधित सूचक को संरक्षित स्टैक स्कैनर द्वारा देखा जा सकता है? यह GC मेमोरी है या हस्तनिर्मित प्रबंधित मेमोरी?

अधिक चिंताजनक बात यह है कि टीम ने कोशिश नहीं की है। उन्होंने Zig कंपाइलर में परिवर्तन किए हैं, Address Sanitizer समर्थन (ASAN) जोड़ा है, प्रत्येक कमिट पर CI में ASAN टेस्ट चलाए हैं, Windows पर ReleaseSafe बिल्ड का उपयोग किया है, Fuzzilli के साथ 24/7 फज़िंग किया है, और कई एंड-टू-एंड मेमोरी लीक टेस्ट किए हैं। फिर भी, क्रैश रिपोर्ट्स लगातार आते रहते हैं।

"हमारी बग फिक्स सूची बहुत खराब लग रही है, मुझे Bun के क्रैश के डर के साथ सोने से थक गया हूँ," समनर ने लिखा। वह Zig को दोष नहीं दे रहा है—अन्य Zig उपयोगकर्ताओं को Bun जैसी समस्याएँ नहीं मिल रही हैं, क्योंकि GC को मैनुअल मेमोरी प्रबंधन के साथ मिलाना एक अत्यंत दुर्लभ आवश्यकता है, जिसके लिए लगभग कोई भी भाषा डिज़ाइन नहीं की गई है।

और Rust संस्करण ने यह जवाब दिया: 2000 बार Bun.build() को निष्पादित करने पर, मेमोरी 609MB पर स्थिर रही।

मेमोरी लीक समस्या के मूल कारण को हल करने के अलावा, Rust पुनर्लिखन ने कई अन्य पहलुओं में सुधार भी किया है।

स्थिरता के मामले में, v1.4.0 ने v1.3.14 में पुनर्उत्पन्न होने वाले 128 बग्स को ठीक किया है, जिसमें मेमोरी लीक से लेकर क्रैश और रंग प्रदर्शन त्रुटियों तक की सहायता पाठ्य समाहित है।

आयतन के संदर्भ में, Rust के पुनर्लिखन, ICU में परिवर्तन और समान कोड फोल्डिंग के साथ, Bun के लिनक्स और विंडोज पर बाइनरी आकार में लगभग 20% की कमी आई है।

प्रदर्शन के मामले में, 2% से 5% तक का सामान्य सुधार हुआ है। Bun.serve 16.96 लाख req/s से बढ़कर 17.77 लाख req/s हो गया, और node:http 10.38 लाख से बढ़कर 10.85 लाख हो गया। वास्तविक उपयोग के मामलों में, next build 13.62 सेकंड से घटकर 13.03 सेकंड हो गया, और tsc बैच कंपाइलेशन 0.94 सेकंड से घटकर 0.89 सेकंड हो गया।

Rust Bun पर आधारित Claude Code के लॉन्च के बाद, Linux पर स्टार्टअप समय 517 मिलीसेकंड से घटकर 464 मिलीसेकंड हो गया, जो लगभग 10% तेज है।

2 तरीके: 64 क्लॉड, 11 दिन, 50 कार्यप्रवाह

समनर ने यह कैसे किया, यह सबसे अधिक ध्यान देने योग्य बात हो सकती है—क्योंकि उसने पारंपरिक "AI को कोड लिखने के लिए कहने" की विधि का उपयोग नहीं किया।

समनर ने पूरी प्रक्रिया को लगभग 50 डायनामिक वर्कफ्लो में विभाजित किया, जिनमें से प्रत्येक एक चक्र है। उन्होंने अपने ब्लॉग में इस पैटर्न को प्सीडोकोड के साथ वर्णित किया:

प्रत्येक कार्य का एक संदर्भ होता है (जैसे एक Jira टिकट या GitHub इशू), Claude इस संदर्भ के आधार पर कोड लिखता है, फिर दो समीक्षक (जो भी Claude होते हैं) कोड की समीक्षा करते हैं, और अंत में प्रतिक्रिया को लागू किया जाता है। पूरा होने के बाद, अगला कार्य लिया जाता है।

यह पैटर्न पूरी पुनर्लेखन प्रक्रिया में देखा जाता है। प्रत्येक वर्कफ्लो एक विशिष्ट लक्ष्य के लिए जिम्मेदार है:

• Zig के पैटर्न और प्रकारों को Rust के पैटर्न और प्रकारों में मैप करने के लिए एक पोर्टिंग गाइड बनाएं;
• प्रत्येक .zig फ़ाइल को एक .rs फ़ाइल में मैकेनिकली पोर्ट करें और PORTING.md और LIFETIMES.tsv के साथ मेल खाएं;
• हर crate की कंपाइल त्रुटियों को ठीक करें;
• bun test या bun build जैसे सबकमांड को चलाएं;
• बन के पूरे टेस्ट सूट को पास करें; कुछ बड़ी रीफैक्टरिंग और साफ़-सफाई करें।

शीर्ष समय के दौरान, समनर ने एक साथ 4 वर्कफ्लो चलाए, जिनमें प्रत्येक में 16 Claude थे, जिससे कुल 64 Claude एक साथ 4 वर्कट्रीज में समानांतर कार्य कर रहे थे और अपने-अपने फाइलें सबमिट और पुश कर रहे थे। शीर्ष पर, Claude प्रति मिनट लगभग 1300 पंक्तियाँ कोड लिखता था।

इस “कार्यान्वयनकर्ता / समीक्षक” अलगाव डिज़ाइन कुंजी है। कोड लिखने वाला क्लॉड कोड को स्वीकृत करना चाहता है, जिससे मानव इंजीनियर की तरह उसमें पक्षपात होता है। इसलिए समीक्षक और कार्यान्वयनकर्ता पूरी तरह से अलग हैं—समीक्षक केवल कोड अंतर देखता है, कार्यान्वयनकर्ता की तर्क प्रक्रिया नहीं, और इसे स्पष्ट रूप से बताया जाता है कि “कोड गलत है” मान लें। प्रत्येक कार्यान्वयनकर्ता के लिए दो से अधिक प्रतिद्वंद्वी समीक्षक होते हैं, जिनका एकमात्र कार्य बग ढूंढना होता है।

कोड लिखना केवल पहला कदम है। Zig कोड एकल कंपाइल यूनिट होता है, जबकि Rust को तेज़ कंपाइलेशन के लिए लगभग 100 crate में विभाजित करना पड़ता है, जिससे साइक्लिक डिपेंडेंसी के कारण cargo check एक साथ लगभग 16,000 कंपाइलेशन त्रुटियाँ देता है। एक व्यक्ति के लिए यह आपदा है, लेकिन 64 समानांतर कार्यरत Claude के लिए यह एक प्रबंधनीय कार्य पंक्ति है। प्रवाह में त्रुटियों को crate के आधार पर समूहित किया जाता है, प्रत्येक crate पर cargo check चलाया जाता है, एक Claude द्वारा ठीक किया जाता है, दो द्वारा समीक्षा की जाती है, और एक द्वारा परिवर्तन लागू किया जाता है।

अब bun --version चलाएं, फिर bun test। प्रत्येक टेस्ट वर्कफ़्लो 100 टेस्ट फ़ाइलों को यादृच्छिक रूप से चलाता है और उन्हें 4 कार्य पेड़ों में विभाजित करता है। टेस्ट सूट में कई प्रकार के टेस्ट शामिल हैं: कुछ टेस्ट एक मिनट से अधिक समय तक चलते हैं, कुछ सिस्टम TCP कनेक्शन संख्या को थका देते हैं, और कुछ लगभग 10000 प्रक्रियाओं का फ़ोर्क करते हैं। समनर ने systemd-run का उपयोग करके संसाधनों को सीमित करने के लिए cgroup बनाया, लेकिन मशीन कई बार डिस्क स्थान की कमी के कारण क्रैश हो गई।

दो दिन बाद, Linux प्लेटफॉर्म के असफल परीक्षण 972 से घटकर 23 हो गए। एक और आधे दिन बाद, Linux पूरी तरह से हरा हो गया। पांच दिन बाद, सभी छह प्लेटफॉर्म—Linux x64, Linux arm64, macOS x64, macOS arm64, Windows x64, Windows arm64—सभी सफल हो गए।

14 मई को, PR #30412 को आधिकारिक रूप से मर्ज कर दिया गया, और सभी टेस्ट सूट सफलतापूर्वक पास हो गए, कोई भी टेस्ट छोड़ा या हटाया नहीं गया।

3 चिंताजनक बिंदु: 13,000 असुरक्षित और पंक्ति-दर-पंक्ति समीक्षा के लिए असंभव कोड

हालांकि, समनर ने भी स्वीकार किया कि यह कार्य अभी तक पूरी तरह से समाप्त नहीं हुआ है।

अब तक, Bun के Rust कोड में लगभग 4% unsafe ब्लॉक में स्थित है, जिसमें लगभग 13,000 unsafe कीवर्ड हैं, जो लगभग 27,000 पंक्तियों में फैले हुए हैं, जबकि Rust की कुल कोड मात्रा लगभग 780,000 पंक्तियाँ हैं। इनमें से 78% unsafe ब्लॉक केवल एक पंक्ति के हैं, जो आमतौर पर C++ से एक पॉइंटर या C लाइब्रेरी पर एक कॉल होती है।

वह अगले पुनर्गठन से इस अनुपात में कमी आने की उम्मीद करता है। लेकिन किसी ने एक गणना की: uv में लगभग 350,000 पंक्तियाँ कोड हैं, और केवल 73 असुरक्षित कॉल हैं। जबकि Bun में unsafe की संख्या uv की 178 गुना है। यह अंतर "C पुस्तकालयों को कॉल करने की आवश्यकता" से समझाया नहीं जा सकता।

और फिर बाद में सुरक्षित Rust कोड में भी अपरिभाषित व्यवहार दिखाई दिया। यह C++ की तुलना में अधिक कठिन है क्योंकि आप सोचेंगे कि सुरक्षित कोड में कोई समस्या नहीं हो सकती।

Bun टीम ने बाद में PathString::init को unsafe fn में बदल दिया।

समनर ने स्वयं स्वीकार किया कि इस पुनर्लेखन से 19 ज्ञात रिग्रेशन समस्याएँ उत्पन्न हुई हैं, और बताया कि अधिकांश रिग्रेशन समस्याएँ उन कोड से उत्पन्न हुई हैं जिनकी व्याकरणिक संरचना समान है लेकिन अर्थ भिन्न है।

उदाहरण के लिए, ये दो कोड स्निपेट एक जैसे दिखते हैं, लेकिन व्यवहार पूरी तरह से अलग है। Zig का assert एक फ़ंक्शन है, इसलिए इसके पैरामीटर हर बिल्ड में चलाए जाते हैं। Rust का debug_assert! एक मैक्रो है, इसलिए पब्लिश वर्जन में, पूरा एक्सप्रेशन (फ़ंक्शन कॉल सहित) insert_stale को हटा दिया जाता है।

हालांकि सभी समस्याएँ ठीक कर दी गई हैं, लेकिन इसका अर्थ यह नहीं है कि लाखों पंक्तियों के AI कोड में कोई अन्य समस्याएँ नहीं हैं।

कोई भी सामान्य व्यक्ति एक ऐसे उत्पादन ऐप्लिकेशन को तुरंत स्थानांतरित करेगा जिसका रनटाइम पूरी तरह से फिर से लिखा गया हो? अगर आपको लगता है कि 1.4 संस्करण में कोई नया बग नहीं आया है या व्यवहार में कोई परिवर्तन नहीं हुआ है, तो यह बहुत निर्दोष होगा।

एक और नजरअंदाज नहीं किया जा सकने वाला मुद्दा कोड समीक्षा है। 10 लाख पंक्तियों के परिवर्तन को मानव द्वारा प्रत्येक पंक्ति को देखकर नहीं किया जा सकता—यदि एक मिनट में एक पंक्ति देखी जाए, तो लगातार 11.7 दिन तक देखना पड़ेगा; वास्तविक कोड समीक्षा गति (एक घंटे में 200 पंक्तियाँ) के अनुसार, इसे पूरा करने में दो से अधिक वर्ष लगेंगे।

इस PR के समीक्षक मुख्य रूप से claude[bot] और coderabbitai[bot] हैं। समनर ने खुद स्वीकार किया है कि उनकी समीक्षा विधि "विरोधी समीक्षा एजेंट को सही ढंग से अंतर पकड़ने की जांच करना, सुनिश्चित करना कि रूपांतरण मार्गदर्शिका का पालन किया जा रहा है, और साथ ही खुद कई कोड पढ़ना" है। लेकिन "कई" का मतलब कितना है, उन्होंने नहीं बताया।

एक और अवगत बात यह है: 2025 दिसंबर में Bun को Anthropic द्वारा अधिग्रहित कर लिया गया, और इस कोडबेस को प्रभावी ढंग से बनाए रखने का एकमात्र वास्तविक उपकरण Claude ही है। समुदाय में कुछ लोग कहते हैं कि यह अब पारंपरिक अर्थों में ओपन सोर्स प्रोजेक्ट नहीं रहा है—आपको Bun के लिए PR भेजने के लिए Anthropic का सदस्यता लेना होगा, या उन कुछ कोर सदस्यों पर निर्भर रहना होगा जो AI द्वारा उत्पन्न कोड को समझ चुके हैं।

Is 165,000 USD worth a year's worth of work?

समनर ने ब्लॉग में भी उल्लेख किया कि इस रीव्राइट की API लागत लगभग 165,000 डॉलर है, जो 3 इंजीनियरों के एक वर्ष के काम के बराबर है। यह संख्या Hacker News पर तीव्र चर्चा का विषय बन गई।

कुछ लोग मानते हैं कि यह खर्च वास्तव में बहुत लाभदायक है। सिलिकॉन वैली में 165,000 डॉलर से कुछ ही पूर्णकालिक इंजीनियर नियुक्त किए जा सकते हैं, और Anthropic जैसी कंपनी के इंजीनियर को तो और भी नहीं। levels.fyi पर वेतन डेटा के अनुसार, Anthropic के इंजीनियर का कुल पैकेज 500,000 डॉलर या उससे अधिक हो सकता है। 50 इंजीनियरों की औसत वार्षिक आय 336,000 डॉलर के अनुमान के साथ, प्रतिदिन लगभग 1,292 डॉलर का खर्च होता है। 50 लोगों द्वारा 11 दिनों तक लगातार काम करने पर, केवल मानव संसाधन लागत ही लगभग 710,000 डॉलर हो जाती है, और यह भत्ते, कार्यालय स्थान, उपकरण और अन्य प्रशासनिक खर्चों को शामिल नहीं करता।

लेकिन, समनर ने "क्लॉड फेबल 5 का प्री-रिलीज संस्करण" का उपयोग किया है, जो एक उन्नत मॉडल है जो अभी तक सार्वजनिक रूप से उपलब्ध नहीं है और जिस पर निर्यात नियंत्रण लागू हो सकता है। इसलिए, API मूल्य केवल अंतिम उपयोगकर्ता द्वारा देखा जाने वाला अंक है, जिसके पीछे Anthropic द्वारा किए गए विशाल शोध और विकास व्यय हैं। कुछ लोगों ने यह भी बताया है कि लागत को केवल API मूल्य के रूप में सरलीकृत करना, वास्तविक निवेश को जानबूझकर कम दिखाने का प्रयास है। यदि मॉडल विकास लागत, प्रशिक्षण लागत, कंप्यूटेशनल संसाधनों का निवेश, इंजीनियरिंग मानव संसाधनों सहित सभी लागतों को शामिल किया जाए, तो विश्वास किया जाता है कि कुल लागत निश्चित रूप से बहुत अधिक होगी, संभवतः 150 डॉलर से अधिक।

और वर्तमान में देखा जाए तो, 165,000 डॉलर के बदले एक साल का काम दिखने में काफी सस्ता लगता है।

लेकिन वास्तविक लागत इस बिल पर नहीं है। इस कोडबेस में 6778 कमिट हैं, और किसी ने भी इसे पूरी तरह से पढ़ा नहीं है, हालाँकि अभी सब कुछ सही चल रहा है, लेकिन छह महीने बाद क्या होगा? जब कोई अजीब समानांतर समस्या रात के तीन बजे अचानक प्रकट हो जाए, तो ड्यूटी पर लगे इंजीनियर के सामने एक ऐसा सिस्टम होगा जिसकी आंतरिक तर्क को वह स्वयं समझ नहीं पा रहा है। भविष्य में सब कुछ AI द्वारा रखरखाव किया जाएगा, रखरखाव की लागत कैसे गिनी जाए, वास्तव में काफी कठिन है।