Ladybird ने Rust अपनाया, AI की मदद से बदलाव तेज

• Ladybird ब्राउज़र प्रोजेक्ट ने C++ की जगह लेने वाली memory-safe भाषा के रूप में Rust को अपनाया और बदलाव की प्रक्रिया में AI टूल्स का उपयोग किया
• पहले Swift पर विचार किया गया था, लेकिन C++ interoperability और platform constraints की सीमाओं के कारण दिशा Rust की ओर मोड़ी गई
• पहला porting target JavaScript engine LibJS है, और Claude Code व Codex की मदद से सैकड़ों prompts के जरिए manually guided translation किया गया
• लगभग 2 हफ्तों में 25,000 lines का Rust code पूरा किया गया, और यह सत्यापित किया गया कि output और performance दोनों C++ version के पूरी तरह समान हैं
• फिलहाल प्रोजेक्ट C++ और Rust के parallel development model को बनाए रखेगा, और लंबे समय में safety व maintainability को मजबूत करने की योजना है

---

Rust अपनाने की पृष्ठभूमि

• Ladybird ने C++ की जगह लेने वाली memory-safe भाषा खोजने के लिए कई भाषाओं की समीक्षा की
  • Swift को C++ के साथ interoperability की कमी और Apple ecosystem के बाहर platform support की सीमाओं के कारण बाहर कर दिया गया
• Rust को system programming ecosystem के परिपक्व होने और कई contributors के पहले से ही इससे परिचित होने के आधार पर उपयुक्त माना गया
• 2024 में Rust की C++-style OOP के लिए अनुपयुक्तता के कारण इसे अपनाने का निर्णय टाल दिया गया था, लेकिन बाद में safety और ecosystem maturity के आधार पर इसे फिर से अपनाने का फैसला किया गया
• Firefox और Chromium में Rust अपनाए जाने के उदाहरणों को देखते हुए यह निष्कर्ष निकाला गया कि यह Ladybird के लिए भी उपयुक्त है

LibJS porting प्रक्रिया

• पहला migration target Ladybird का JavaScript engine LibJS है
  • lexer, parser, AST, bytecode generator जैसे स्वतंत्र components और test262-आधारित test coverage के कारण इसे शुरुआत के लिए उपयुक्त माना गया
• porting में Claude Code और OpenAI Codex का उपयोग किया गया
  • यह automatic generation नहीं बल्कि human-led translation था, जिसमें porting order और code structure सीधे तय किए गए
  • सैकड़ों prompts के जरिए बारीकी से निर्देश दिए गए, और बाद में विभिन्न models के माध्यम से code verification और error detection किया गया

परिणाम और सत्यापन

• लक्ष्य यह था कि C++ और Rust pipelines का output byte-level पर एकदम समान हो
• लगभग 25,000 lines का Rust code 2 हफ्तों में पूरा किया गया, जिससे कई महीनों का काम कम समय में हो गया
• AST और bytecode पूरी तरह समान हैं, और tests व JS benchmarks में performance drop नहीं देखा गया
• C++ और Rust pipelines को साथ चलाने वाले lockstep tests के जरिए web browsing के दौरान परिणामों की समानता की पुष्टि की गई
• मौजूदा code अभी C++ से अनूदित रूप में है, और register allocation patterns तक को समान रूप से नकल करता है
  • ऐसा इसलिए है क्योंकि C++ pipeline के साथ compatibility बनाए रखना सर्वोच्च प्राथमिकता है
  • भविष्य में जब C++ pipeline को हटाया जाएगा, तब Rust code को सरल और साफ़ किया जाएगा

आगे की योजना

• Rust migration को प्रोजेक्ट की मुख्य development direction नहीं बल्कि parallel work के रूप में आगे बढ़ाया जाएगा
• C++ और Rust code साथ-साथ मौजूद रहेंगे, और इनके बीच स्पष्ट interoperability boundaries रखी जाएँगी
• porting order और scope का प्रबंधन core team करेगी, और बाहरी contributors को पहले से समन्वय करना होगा
• लंबे समय में safety और maintainability में सुधार के लक्ष्य के साथ यह बदलाव धीरे-धीरे आगे बढ़ाया जाएगा
• यह स्वीकार किया गया कि यह फैसला विवादास्पद हो सकता है, फिर भी इसे Ladybird के भविष्य के लिए सही विकल्प माना गया

[GN⁺]

Hacker News की राय

• इस प्रोजेक्ट में byte-for-byte identical output की मांग करना सबसे समझदारी भरा हिस्सा था
  इसकी वजह से पुरानी pipeline और नई pipeline को साथ-साथ चलाकर diff की तुलना की जा सकती है, और translation के दौरान आए bugs तुरंत पकड़े जा सकते हैं
  बहुत-से rewrites इसलिए fail होते हैं क्योंकि लोग porting के दौरान “सुधार” करने की कोशिश करते हैं, और फिर पुराना version, नया version, या साधारण behavior differences से पैदा हुए ghost bugs के पीछे भागते रहते हैं
  C++ से Rust में अनुवाद किया गया version शुरू में थोड़ा अटपटा लगे तो भी ठीक है। बाद में जब C++ वाला हिस्सा पूरी तरह retire हो जाए, तब इसे धीरे-धीरे और idiomatic बनाया जा सकता है

  • Porting बहुत-सी चीज़ें सुधारने का अच्छा समय है, लेकिन नए features जोड़ने का समय नहीं
    output को एक जैसा रखते हुए refactoring, optimization, documentation किया जा सकता है
    code पढ़ते हुए documentation करना सबसे सही समय लगता है। Ladybird जैसे लोकप्रिय project में documentation खुद development speed बढ़ाने का तरीका है
  • उम्मीद है कि इस तरह की pure porting और ज़्यादा देखने को मिले
    पहले migration cost इतनी ज़्यादा होती थी कि लोग “कर ही रहे हैं तो सुधार भी कर लें” कहकर उसे सही ठहराते थे, लेकिन आखिर में ghost bugs ही ज़्यादा पीछा करवाते थे
  • यह approach मुझे सच में पसंद आई। कुछ दिन पहले testing और verification के नज़रिये से लिखा गया एक लेख पढ़ा था, और इसे इतने complex project पर लागू होते देखना दिलचस्प है
  • मैंने भी web framework को इसी तरह कई बार migrate किया है। पहले नए code में HTTP output string को पूरी तरह match कराया, फिर पुराने version को पूरी तरह हटा दिया
  • अगर अच्छा test suite हो, तो यह approach कहीं बेहतर काम करती है। लगता है Ladybird के पास भी ऐसा होगा

• Claude Code और Codex का इस्तेमाल करके C++ code को Rust में translate किया गया
  यह पूरी तरह automatic नहीं था; इंसानों ने direction तय की और सैकड़ों छोटे prompts के साथ उसे guide किया
  शुरू से ही यह शर्त रखी गई कि दोनों pipelines का output byte-for-byte identical होना चाहिए, और नतीजे में सिर्फ 2 हफ्तों में 25,000 lines का Rust code तैयार हो गया
  AST और bytecode दोनों match हुए और 0 regressions हासिल किए गए
  मुझे लगता है कि languages के बीच porting में AI का इस्तेमाल करने का यही सही तरीका है

  • मैंने भी कभी एक टूटी हुई Perl script को Claude की मदद से Rust में migrate किया था
    80 मिनट में उसने Drupal structure का analysis किया, original design और module structure को वैसे ही restore किया, और custom plugins भी implement कर दिए
    अब सुनने में आता है कि वह site WordPress, ProcessWire, Node.js, और अब Next.js तक migrate हो चुकी है
  • अफसोस है कि AI companies इस तरह के collaborative usage pattern पर ज़्यादा ध्यान नहीं देतीं
    मुझे “एक prompt में तैयार code” नहीं चाहिए, बल्कि AI के साथ लंबे sessions में back-and-forth करके human intelligence को amplify (IA) करने वाला tool चाहिए
    लेकिन शायद ऐसे tools का market छोटा हो, क्योंकि इन्हें वही लोग इस्तेमाल कर पाएंगे जिन्हें development का ज्ञान है
  • मैं भी Rust सीखते हुए Claude के लिए “teach” नाम की एक skill बनाकर इस्तेमाल कर रहा हूँ
    Claude खुद code नहीं लिखता, सिर्फ hints देता है और review करता है
    Rust की प्रकृति ऐसी है कि उसे तुरंत improvisation करके लिखना आसान नहीं, इसलिए यह तरीका बहुत संतोषजनक लगता है
  • मैं भी Claude को इसी तरह इस्तेमाल करता हूँ। “AI सब कर दे” की तरह नहीं, बल्कि design, review, testing में साथ देने वाले partner की तरह
  • मैंने पहले एक complex bash script को Claude की मदद से golang में migrate किया था, और speed व reliability में जबरदस्त सुधार हुआ
    अब उसका browser में चलने वाला wasm version भी है
    cryptography वाला हिस्सा मैंने खुद implement नहीं किया था, इसलिए उसकी चिंता की ज़रूरत नहीं

• Rust में migration की खबर दिलचस्प है, लेकिन यह हैरान करने वाली भी है क्योंकि Ladybird team पहले “anti-Rust hype” रुख के लिए जानी जाती थी
  फिर भी अगर यह Rust में जाता है, तो मेरे लिए contribute करना कहीं आसान हो जाएगा

  • मुझे भी Rust पसंद है, लेकिन किसी language को लेकर हद से ज़्यादा उत्साह कभी-कभी थका देने वाला लगता है
    language आखिरकार एक tool है, और किसी एक language को अपनी पहचान का हिस्सा बना लेना ठीक नहीं लगता
  • मुझे Rust खास पसंद नहीं, लेकिन व्यावहारिक रूप से यह सबसे अच्छा विकल्प हो सकता है
  • एक लिंक है कि अब Ladybird सिर्फ C++/Swift-केंद्रित नहीं रहा
  • language direction का बार-बार बदलना थोड़ा अस्थिर लगता है। इससे project की continuity हिल सकती है

• Andreas एक बेहतरीन engineer हैं और उनमें entrepreneurial sense भी है
  उन्होंने hobby project को industrial project में बदल दिया, यह प्रभावशाली है
  फिर भी इतनी तेज़ language shift थोड़ा असहज महसूस कराती है

  • Andreas सिर्फ business-minded व्यक्ति नहीं, बल्कि वे engineer हैं जिन्होंने Serenity OS को कई साल तक लगभग अकेले बनाया
    इसे project के स्वाभाविक विकास का परिणाम माना जा सकता है
  • कहा गया है कि Swift का फैसला भी कई languages को खुद आज़माने के बाद लिया गया तर्कसंगत निर्णय था
  • जानकारी के लिए, वे पहले Apple Safari engine team में काम कर चुके हैं
  • फिर भी क्या इससे सच में एक नया browser बनेगा, इस पर अभी भी सवाल है
  • आपने “असहज” कहा, लेकिन खास तौर पर किस बात से असहजता है, यह जानना दिलचस्प होगा

• “अभी Rust code असामान्य है, बाद में साफ़ करेंगे” जैसी बात सुनकर लगता है कि यह एक और rewrite का संकेत हो सकता है, और यही चिंता बढ़ाती है
  startup का language बदलना अक्सर warning sign जैसा लगता है

  • फिर भी C++ और Rust दोनों multi-paradigm languages हैं, इसलिए structure को काफ़ी हद तक वैसे ही ले जाया जा सकता है
  • Joel on Software का “rewrite का trap” याद आता है
    जब नया version बनाना और पुराने features को बनाए रखना साथ-साथ चलता है, तो speed race शुरू हो जाती है और नया version पीछे रह सकता है
  • लेकिन Ladybird startup नहीं बल्कि एक open project है, इसलिए तुलना पूरी तरह वही नहीं है
    Linux, PHP, और musl libc भी कई बार full rewrites से गुज़र चुके हैं
  • मैं होता तो शायद ऐसी स्थिति में Firefox ही इस्तेमाल करता रहता
  • LLM के सहारे कुछ हफ्तों तक porting करना थोड़ा अजीब फैसला लगता है

• अब जब AI आम हो चुका है, “नई language में पूरा rewrite” का गणित पूरी तरह बदल गया है
  खासकर अगर test suite मौजूद हो, तो risk बहुत कम हो जाता है
  यह ऐसा दौर है जहाँ testing की अहमियत 10 गुना बढ़ गई है

  • मैंने भी personal project में AI की मदद से Python CLI library बनाई है
    Streamlit, Shiny, Dash जैसी कई UIs को तेज़ी से आज़माया जा सकता है, इसलिए prototyping मज़ेदार हो जाती है
  • लंबी अवधि में लगता है कि AI के आगे बढ़ने के साथ programming languages की अहमियत खुद कम हो सकती है
    कुछ projects में तो अभी भी low-code + agent का combination काफ़ी चल रहा है

• “AI को code review सौंप दिया” वाला हिस्सा थोड़ा चिंताजनक लगता है
  models की logical errors पकड़ने की क्षमता सीमित होती है

  • फिर भी अगर नतीजे में 65,000 tests पर 0 regressions + identical output मिला है, तो इसे पूरी तरह नज़रअंदाज़ नहीं किया जा सकता
    लेकिन असली सवाल यह है कि बाद में “cleanup” सच में होगा भी या नहीं
  • इंसानी reviewers भी perfect नहीं होते। कई नज़रियों से review करने पर, चाहे AI हो या इंसान, अलग-अलग तरह की गलतियाँ पकड़ी जा सकती हैं
  • इस तरह की बातों को validate करने का काम test suite का होना चाहिए
  • लेकिन कुछ लोग AI द्वारा लिखे गए non-idiomatic Rust code के साथ काम नहीं करना चाहते
    AI-generated code पर निर्भरता बढ़ने से AI dependency का दुष्चक्र बन सकता है

• project का C++ और Rust को साथ-साथ विकसित करना inefficient लगता है
  क्या बेहतर नहीं होगा कि इसे किसी एक memory-safe language में पूरी तरह unify कर दिया जाए

  • लेकिन Firefox जैसे mixed codebases भी अच्छी तरह चल सकते हैं
    जब तक हर component सिर्फ एक language में लिखा हो, तब तक समस्या नहीं होती
  • पूरी migration की कोशिश में momentum loss इतना बड़ा हो सकता है कि project रुक ही जाए
  • C++ के strict subset का इस्तेमाल करके भी memory safety हासिल की जा सकती है

• 2024 में Swift अपनाते समय Andreas ने Rust के बारे में tweet किया था
  उन्होंने कहा था कि Rust short-lived programs के लिए शानदार है, लेकिन complex object graphs को बनाए रखने वाले long-running programs में असुविधाजनक है
  उन्होंने community को toxic भी कहा था
  संबंधित tweet लिंक

  • क्या अब उन्होंने अपना विचार बदल लिया है? शायद शुरू से C++ बदलने की ज़रूरत ही नहीं थी
  • Rust community के बहिष्कारी माहौल वाली बात से मैं सहमत हूँ
  • संभव है कि sponsor requirements की वजह से AI-आधारित Rust migration को आगे बढ़ाया गया हो

• यह देखना दिलचस्प होगा कि non-idiomatic Rust code बाद में technical debt बनता है या नहीं

  • जोखिम मुख्यतः cleanup phase में है। C++-style pointer patterns, Rust के ownership rules से टकरा सकते हैं
    Servo project ने भी ऐसे मुद्दे देखे थे, लेकिन उसी प्रक्रिया में latent bugs भी पकड़े गए थे
  • समस्या C++ खुद नहीं था; Rust में जाने की वजह memory safety थी
  • Andreas पहले भी JS runtime की GC safety समस्याओं का ज़िक्र करते रहे हैं और अधिक सुरक्षित language चाहते थे
    Rust में migration उसी सोच के अनुरूप एक mature decision लगता है