मुख्य सारांश

  • समस्या: बुन का ज़िग कोडबेस जावास्क्रिप्टकोर के गार्बेज कलेक्टर के साथ मैन्युअल एलोकेटर्स मिलाने से लगातार मेमोरी बग झेल रहा था। ज़िग की एआई-विरोधी नीतियों और १.० से पहले की अस्थिरता ने ऐंथ्रोपिक द्वारा अधिग्रहण के बाद स्वचालित रखरखाव को रोक दिया था।
  • समाधान: कई वर्षों के मानवीय प्रयास के बजाय, बुन ने विरोधी समीक्षकों के साथ ६४ समानांतर क्लॉड एजेंट्स चलाकर ११ दिनों में १,४४८ फाइलों की ५,३५,००० पंक्तियां बदल डालीं।
  • परिणाम: १२८ पुराने बग ठीक हुए, बाइनरी २०% छोटी हुई, डेव सर्वर की मेमोरी लीक समाप्त हुई। अनुमानित कंप्यूट लागत: १,६५,००० डॉलर। ज़िग के निर्माता एंड्रयू केली ने बेंचमार्क्स को सार्वजनिक रूप से भ्रामक बताया।

वर्ष २००० में, जोएल स्पोल्स्की ने सॉफ्टवेयर इंजीनियरिंग का सबसे चर्चित निबंध लिखा था, जिसमें उन्होंने तर्क दिया कि उत्पादन कोडबेस को शुरू से दोबारा लिखना किसी कंपनी की सबसे बड़ी रणनीतिक भूल है। उन्होंने नेटस्केप का उदाहरण दिया, जिसने अपना ब्राउज़र दोबारा बनाने में तीन साल लगा दिए जबकि माइक्रोसॉफ्ट ने उसकी बाज़ार हिस्सेदारी छीन ली।

२६ वर्षों तक वह नियम लगभग अकाट्य रहा। मई २०२६ में, बुन ने उसे तोड़ दिया।

बुन क्यों फंसा हुआ था

बुन गूगल के वी८ के बजाय एप्पल के जावास्क्रिप्टकोर (जेएससी) इंजन का उपयोग करता है। जेएससी जावास्क्रिप्ट ऑब्जेक्ट्स को प्रबंधित करने के लिए एक सटीक गार्बेज कलेक्टर इस्तेमाल करता है। समस्या यह थी कि बुन का नेटिव रनटाइम कोड ज़िग में लिखा गया था, जहां मेमोरी को मैन्युअल रूप से प्रबंधित किया जाता है।

बुन के आधे ऑब्जेक्ट्स जेएससी के गार्बेज-कलेक्टेड हीप में रहते थे। बाकी आधे ज़िग मेमोरी बफ़र्स में मैन्युअल एलोकेटर्स के साथ रहते थे। दोनों हिस्से एक-दूसरे की तरफ कच्चे पॉइंटर्स रखते थे, और उन पॉइंटर्स को सिंक्रोनाइज़ रखने के लिए जिस अनुशासन की ज़रूरत थी, कोडबेस अक्सर उसमें चूकता था।

बुन के चेंजलॉग्स इस बेमेल से उपजे बग्स से भरे थे: पहले से मुक्त की गई मेमोरी को पढ़ना, एक ही मेमोरी को दो बार मुक्त करना, या कभी मुक्त न करना। डेव सर्वर हर हॉट रीलोड पर ३ एमबी लीक करता था क्योंकि बंडलर में एक अकेली त्रुटि शाखा सफाई करना भूल जाती थी। ये कोई विरले किनारी मामले नहीं थे। ये दस लाख पंक्तियों के कोडबेस में दो असंगत मेमोरी प्रबंधन मॉडल मिलाने के संरचनात्मक परिणाम थे।

२०२५ के अंत में ऐंथ्रोपिक द्वारा बुन के अधिग्रहण के बाद एक दूसरी समस्या सामने आई। भविष्य का अधिकांश विकास क्लॉड द्वारा लिखा जाने वाला था। ज़िग एआई-जनित कोड के प्रति शत्रुतापूर्ण है: परियोजना एलएलएम पुल रिक्वेस्ट अस्वीकार करती है और सुरक्षा रिपोर्ट भी बंद कर देती है अगर बग एआई ने खोजा हो। इसके अलावा, ज़िग संस्करण १.० तक नहीं पहुंचा है, लगातार ब्रेकिंग बदलाव लाता रहता है, और सार्वजनिक कोड रिपॉजिटरी का बहुत छोटा हिस्सा है, इसलिए मॉडल स्थापित भाषाओं की तुलना में कमज़ोर ज़िग लिखते हैं।

रस्ट ने दोनों समस्याएं हल कीं। इसका बॉरो चेकर मेमोरी प्रबंधन को टाइप सिस्टम में ले जाता है, जिससे अधिकांश पॉइंटर गलतियां रनटाइम क्रैश की बजाय कंपाइल-टाइम त्रुटियां बन जाती हैं। और क्लॉड जैसे मॉडल दशकों के ओपन-सोर्स प्रशिक्षण डेटा की बदौलत उच्च गुणवत्ता का मुहावरेदार रस्ट लिखते हैं।

उन्होंने यह कैसे किया

बुन के संस्थापक जेरेड समनर ने मई की शुरुआत में ज़िग की सभी ५,३५,००० पंक्तियों को रस्ट में बदलने का फैसला किया। माइग्रेशन मानव सिस्टम प्रोग्रामर्स की टीम ने नहीं किया। यह ६४ समानांतर क्लॉड कोडिंग एजेंट्स ने किया।

प्रक्रिया तीन चरणों में चली:

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

चरण २: समानांतर अनुवाद। ६४ क्लॉड एजेंट्स ने चार गिट वर्क-ट्रीज़ में एक साथ स्वतंत्र उपप्रणालियां बदलीं: एचटीटीपी पार्सर, बंडलिंग इंजन, वेबसॉकेट परत, पैकेज मैनेजर। अधिकतम गति पर, झुंड प्रति मिनट १,३०० पंक्तियां रस्ट कोड तैयार कर रहा था।

चरण ३: विरोधी समीक्षा। हर कार्यान्वयनकर्ता एजेंट को अलग-अलग संदर्भ विंडो में चलने वाले दो समीक्षक एजेंट दिए गए। समीक्षकों का एकमात्र काम था यह मानना कि कोड गलत है और पता लगाना क्यों। पुल रिक्वेस्ट तब तक रोकी जाती थीं जब तक दोनों समीक्षक बदलावों को मंज़ूर नहीं कर देते।

ग्यारह दिन, ६,०५२ कमिट्स, और लगभग १,६५,००० डॉलर के कंप्यूट के बाद, बुन की पूरी टेस्ट सूट हर प्लेटफॉर्म पर पास हो रही थी।

आंकड़े

मापदंड ज़िग (बुन संस्करण १.१) रस्ट (बुन संस्करण १.२) बदलाव
सिस्टम कोड पंक्तियां ५,३५,००० ४,९८,००० -६.९%
रिलीज़ बाइनरी आकार ९२.४ एमबी ७३.९ एमबी -२०%
डेव सर्वर मेमोरी लीक ३.२ एमबी प्रति रीबिल्ड ०.० एमबी समाप्त
पुराने बग ठीक किए आधार १२८ बंद पोर्ट के दौरान ठीक
एचटीटीपी हैलो वर्ल्ड थ्रूपुट १,४२,००० अनुरोध/सेकंड १,४५,२०० अनुरोध/सेकंड +२.२%
क्लीन रिलीज़ बिल्ड समय ४२ सेकंड ३ मिनट १८ सेकंड ~४.७ गुना धीमा

बुन की घोषणा के अनुसार, रस्ट पोर्ट जून से क्लॉड कोड को चला रहा है और किसी को पता भी नहीं चला।

एंड्रयू केली की प्रतिक्रिया

सबने खुशी नहीं मनाई। ज़िग के निर्माता एंड्रयू केली ने एक प्रतिक्रिया प्रकाशित की जिससे साफ था कि यह तलाक सालों से तैयार हो रहा था।

केली ने कहा कि ज़िग टीम ने वर्षों तक बुन को अपनी भाषा को शर्मिंदा करते देखा, ऐसे कोड के साथ जिसे वे आंतरिक रूप से "ज़िग कैसे न लिखें" के पाठ्यपुस्तक उदाहरण के रूप में इस्तेमाल करते थे। उन्होंने जेरेड समनर पर आरोप लगाया कि वे "एलएलएम के अस्तित्व से बहुत पहले से घटिया कोड लिख रहे थे," बताया कि समनर ने १८ साल की उम्र में पीटर थील का पैसा लेने के लिए कॉलेज छोड़ दिया, और दूसरों के हवाले से बताया कि समनर के नीचे काम करना आसान नहीं था।

व्यक्तिगत हमलों के नीचे वैध तकनीकी आपत्तियां दबी थीं:

१. प्रदर्शन लाभ बढ़ा-चढ़ाकर बताए गए हैं। केली का तर्क है कि गति में सुधार मुख्य रूप से लिंक-टाइम ऑप्टिमाइजेशन (एलटीओ) चालू करने से आया, जो ज़िग शुरू से सपोर्ट करता है। बुन की ज़िग बिल्ड्स ने इसे कभी चालू नहीं किया था।

२. बाइनरी आकार में कमी रस्ट की जीत नहीं है। २०% की कमी एलटीओ और डेड कोड एलिमिनेशन से आई, रस्ट की किसी अनूठी विशेषता से नहीं।

३. कंपाइल समय नाटकीय रूप से बिगड़ गया। बुन की क्लीन बिल्ड ४२ सेकंड से बढ़कर ३ मिनट से अधिक हो गई। केली ने नोट किया कि बुन की घोषणा ने सुविधाजनक रूप से कंपाइल समय का कोई उल्लेख नहीं किया, एक ऐसा मापदंड जहां ज़िग निर्णायक रूप से जीतता है।

४. ज़िग टीम "राहत महसूस कर रही है।" केली ने कहा कि बुन का ज़िग के सबसे प्रमुख उपयोगकर्ता होना एक बोझ था क्योंकि उसका कोडबेस बाहरी लोगों को अच्छे ज़िग की विकृत तस्वीर दे रहा था।

जनता की राय किसके पक्ष में

शायद किसी के नहीं। ज़िग ने अपना सबसे मशहूर उपयोगकर्ता खोया। केली ने व्यक्तिगत हमलों से अपना संयम खोया जिसने उनके वैध तकनीकी बिंदुओं पर परदा डाल दिया। और समनर को एक कंपाइलर इंजीनियर ने सार्वजनिक रूप से "शुरुआती ऊर्जा" का निदान दे दिया।

पुनर्लेखन अपने आप में, हालांकि, व्यावहारिक दृष्टि से विवाद से परे है। १२८ बग ठीक हुए, एक पुरानी मेमोरी लीक खत्म हुई, बाइनरी २०% छोटी हुई, और एक ऐसा कोडबेस जिसे एआई एजेंट्स अब स्वायत्त रूप से बनाए रख सकते हैं। कंपाइल समय की गिरावट वास्तविक है और स्थानीय विकास के लिए महत्वपूर्ण है, लेकिन जिस परियोजना की भावी कार्यशक्ति मुख्य रूप से सीआई में चलने वाले क्लॉड एजेंट्स हैं, उसके लिए यह समझौता स्वीकार्य हो सकता है।

बड़ा सवाल यह है कि सामान्य रूप से एआई-संचालित पुनर्लेखनों के लिए इसका क्या अर्थ है। बुन के पास असामान्य फायदे थे: ऐंथ्रोपिक एआई और परियोजना दोनों का मालिक था, जिससे कंप्यूट लागत की चिंता खत्म हो गई। कोडबेस के पास व्यापक टेस्ट सूट था। और लक्ष्य भाषा (रस्ट) ऐसी है जहां मॉडल अच्छा प्रदर्शन करते हैं। इन फायदों के बिना ऐसा प्रयास करने वाली अधिकांश टीमों के लिए यह कहीं अधिक कठिन होगा।

संदर्भ