Bun का Rust में री-राइट कैसे आगे बढ़ रहा है?

 (lockwood.dev)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • इसे 11 दिनों में पूरा हुआ काम बताया गया था, लेकिन main में मर्ज होने के 6 हफ्ते बाद, 27 जुलाई 2026 तक भी कोई release tag नहीं है और संबंधित काम जारी है
  • शुरुआती री-राइट पर 3~14 मई 2026 के बीच Anthropic API पर 1 लाख 65 हजार डॉलर खर्च हुए, लेकिन लगता है कि इसमें Buildkite CI/CD और बाद के काम की लागत शामिल नहीं है
  • robobun के खुले PR 9 जुलाई को 1,277 से बढ़कर 27 जुलाई तक 2,475 हो गए, और अगर हर PR की pipeline में लगभग 40 मिनट लगते हैं, तो सबको प्रोसेस करने के लिए 86 दिन लगातार चलाना होगा
  • री-राइट शुरू होते ही Claude का उपयोग तेज़ी से बढ़ा और robobun व Anthropic कर्मचारियों की Rust कार्यों में भागीदारी भी बढ़ी, इसलिए पूरा होने का समय और वास्तविक कुल लागत को 1 लाख 65 हजार डॉलर मान लेना मुश्किल है
  • Bun टीम ने खुद री-राइट की पूर्णता और कुल लागत को लेकर कोई अंतिम दावा नहीं किया है, इसलिए AI coding के नतीजों को कंपनी valuation का आधार मानना हो तो लागत के मुकाबले मूल्य और लगातार मानव हस्तक्षेप भी देखना होगा

मर्ज के बाद भी जारी री-राइट

  • Jarred Sumner ने Rewriting Bun in Rust में बताया कि 3~14 मई 2026 के 11 दिनों के दौरान Anthropic API calls पर 1 लाख 65 हजार डॉलर खर्च कर री-राइट का नतीजा main में मर्ज किया गया
    • यह लगभग 15 हजार डॉलर प्रतिदिन बैठता है, जो कई open source maintainers के लिए वहन करना कठिन स्तर है
    • संगठन के Buildkite cluster पर लगातार चलने वाली दिख रही CI/CD लागत इस संख्या में शामिल नहीं लगती
  • 27 जुलाई 2026 तक मर्ज के 6 हफ्ते बीत चुके हैं, लेकिन कोई नया release tag नहीं है, और आखिरी tag bun-v1.3.14 के बाद 11 हफ्ते गुजर चुके हैं
    • इससे पहले एक महीने से अधिक समय तक release न होने का मामला 26 अक्टूबर 2022 के v0.2.2 से 7 दिसंबर के v0.3.0 तक चला 6 हफ्ते का अंतराल था
  • Claude Code द्वारा बनाए गए PR का एक proxy metric माने जाने वाले robobun खुले PR 9 जुलाई को 1,277 से बढ़कर 27 जुलाई तक 2,475 हो गए
    • देखा गया कि Buildkite checks और main में मर्ज होने में आम तौर पर लगभग 40 मिनट, और कभी-कभी 1 घंटा 30 मिनट तक लगते हैं
    • हर PR पर 40 मिनट मानें, तो 2,475 PR को मर्ज करने के लिए pipeline को 86 दिन लगातार चलाना पड़ेगा
    • कुछ PR का Rust code से संबंध नहीं है, और कुछ individual PR ऐसे भी हैं जिन पर बहुत अधिक review हुआ है

घोषित लागत और वास्तविक投入 के बीच अंतर

  • री-राइट की शुरुआत में Claude usage में बड़ी बढ़ोतरी दिखी, और उसके बाद Anthropic कर्मचारियों व robobun की Rust कार्यों में भागीदारी भी बढ़ती नजर आई
    • विश्लेषण में यह मान लिया गया है कि री-राइट अवधि के दौरान Jarred Sumner के commits में Claude का उपयोग हुआ था
    • कुछ PR Anthropic कर्मचारियों ने लिखे थे, इसलिए केवल token लागत ही नहीं बल्कि कर्मचारियों के सीधे हस्तक्षेप को भी ध्यान में रखना चाहिए
  • अगर मान लें कि री-राइट आगे भी प्रतिदिन 10 हजार डॉलर की दर से चलती रही, तो कुल लागत लगभग 8 लाख डॉलर के करीब पहुँचती है, लेकिन यह घोषित वास्तविक लागत नहीं बल्कि मान्यताओं पर आधारित अनुमान है
  • Bun टीम ने यह दावा नहीं किया कि री-राइट पूरी तरह खत्म हो चुकी है या कुल लागत सिर्फ 1 लाख 65 हजार डॉलर ही थी
    • केवल इस मामले के आधार पर यह मानना कठिन है कि AI ने open source maintainers के काम को अधिक तेजी से replace कर दिया है
    • Anthropic अपने टूल्स का internal उपयोग कर रहा है, और automation कार्यों व कर्मचारियों की भागीदारी भी जारी है
  • AI को पूरी तरह नकारने के बजाय, मौजूदा अत्यधिक उम्मीदों और कंपनी valuation को लेकर सावधान रहना चाहिए, और यह देखना चाहिए कि जितनी लागत लगी, उतना मूल्य बना या नहीं, तथा क्या उस कंपनी का valuation उचित है
  • Anthropic का C compiler और Cursor का FastRender web browser कई महीनों से बिना commits के पड़े हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • Bun का Rust rewrite एक महीने से ज़्यादा समय से Claude Code में चल रहा है, लेकिन लगभग किसी ने नोटिस नहीं किया, और कुल मिलाकर यह अच्छी तरह काम कर रहा है
    Bun v1.4 वीडियो में किए गए वादे के मुताबिक, Node.js compatibility tests उतनी संख्या में पास करने से पहले इसे रिलीज़ नहीं किया जाएगा। संबंधित PR merge हो जाने पर अगले मंगलवार के आसपास v1.4 रिलीज़ होने की संभावना ज़्यादा है

    • software quality के लिए जितना समय चाहिए, लेना ठीक है। एक महीने तक रिलीज़ न होना कोई बड़ी बात नहीं है, और अगर कोई खास feature urgently चाहिए तो आप खुद contribute कर सकते हैं या build कर सकते हैं
      Node.js में भी security fixes को छोड़ दें तो हर साल दिसंबर में 4–6 हफ्तों तक कोई meaningful release नहीं होती, इसलिए संबंधित लोगों से पहले पूछे बिना गुस्से वाला पोस्ट लिखने वाली यह आलोचना कमज़ोर आधार पर है। यह बात मैं Node.js maintainer के तौर पर कह रहा हूँ
    • Claude Code खुद भी bugs और release के बाद outages से अक्सर जूझता है, इसलिए यह हैरानी की बात नहीं कि users Rust-based Bun migration से आए bugs और सामान्य bugs में फर्क नहीं कर पाए
    • लेख में अनुमानित costs, खासकर Buildkite cost, पर क्या जवाब मिल सकता है—यह जानने की उत्सुकता है
    • कई vibe coding projects ज़ोरदार शुरुआत करते हैं और फिर Anthropic C की तरह छोड़ दिए जा सकते हैं, इसलिए Bun के भविष्य को लेकर चिंता समझ आती है। Bun तेज़ है और इस्तेमाल में अच्छा है, इसलिए उम्मीद है कि यह GCC की तरह लंबे समय तक टिके

  • बड़े refactoring या rewrite के तुरंत बाद सामान्य development speed वापस पाने में समय लगता है, इसलिए सिर्फ commit count और release cadence से बहुत कुछ judge करना मुश्किल है
    developers को structure familiar होने पर भी Rust codebase में नए सिरे से adapt करना होगा, और वे user features की बजाय unsafe usage sites track करने जैसे कामों पर focus कर रहे होंगे। Canary channel में भी कोई बड़ी समस्या या बदलाव लगभग detect नहीं हुआ, इसलिए जल्दबाज़ी में release करने के बजाय backlog निपटाने की पर्याप्त वजह है
    Anthropic का C compiler और Cursor का FastRender browser मुझे ongoing projects नहीं, बल्कि capability experiments लगे; उम्मीद है कि फिलहाल इन्हें कोई सीधे इस्तेमाल नहीं कर रहा होगा

    • एक महीने पहले सभी Claude Code users को नए version पर migrate कर दिया गया था, इसलिए एक मायने में यह पहले ही production release कर चुका है। ध्यान काफी मिल रहा है और official release की जल्दी नहीं है, इसलिए लगता है कि वे gradual तरीके से आगे बढ़ रहे हैं
    • CI/CD cost का angle दिलचस्प है। आम तौर पर AI ROI के खिलाफ तर्क देते समय कहा जाता है कि code ज़्यादा होने से value ज़्यादा नहीं हो जाती, लेकिन अगर हर CI run पर charge लगता है तो actual revenue बढ़ता है
      खासकर AI-generated repetitive work को नियंत्रण से बाहर होने से रोकने के लिए CI और extra testing अहम हैं—यह बात भी इससे जुड़ती है
    • लेख लिखने वाले के नजरिए से भी यह पक्का नहीं है कि इन numbers से कितना judge किया जा सकता है। उम्मीद है कि अगली release के बाद Anthropic या Bun पूरा cost बताने वाला retrospective publish करेंगे

  • LLM से किसी project को कम समय में translate करना या office product का clone एक बार में बना देना अपने-आप में हैरान करने वाला है, लेकिन software का सार तेज़ initial generation नहीं, बल्कि feature development और long-term maintenance में है
    Word clone में भी basic features जल्दी बन जाते हैं, लेकिन page structure, tables, images, rotation जैसे detailed features पर LLM टूटने लगते हैं। SQLite को C से Rust में port करके सारे tests pass करा भी दें, तो existing implementation की सालों की optimization न होने से उसके slow होने की संभावना ज्यादा है, और language migration से आने वाले नए bugs व future support भी संभालने होंगे
    Reddit पर X, Y, Z implement करने वाले projects लगातार आते रहते हैं, लेकिन bug fixes, user handling, security, बदलती data structures और database work आकर्षक नहीं होते, इसलिए वे vibe coding जितनी तेजी से छोड़े भी जाते हैं
    अगर आप अपने बनाए software को गहराई से नहीं समझते, तो अंत में वह फटेगा ही, और X को Y दिनों में Z में rewrite किया जैसी line अपने-आप में कोई मायने नहीं रखती। शुरुआत तेज़ करना और ported code को समझकर उसे grow व maintain करना बिल्कुल अलग चीजें हैं; maintained Zig version की जगह छोड़ा हुआ Rust version और promotional posts search results को दूषित कर सकते हैं

    • काश और लोग इस process को document करते। व्यक्तिगत तौर पर मैं LLM पर ज्यादा निर्भर एक project बनाते हुए सीख रहा हूँ; complex feature जल्दी काम करने लगते हैं तो बहुत सुखद महसूस होता है, लेकिन integration, cleanup, UI polishing शुरुआती speed का स्वाद चखने के बाद उल्टा ज्यादा तकलीफदेह लगते हैं
      जब code बहुत adhoc तरीके से उलझ जाता है, तो वह एक inertia point पर पहुँचता है जहाँ LLM और ज्यादा chaos पैदा किए बिना आगे नहीं बढ़ पाता; architecture ठीक करनी पड़ती है, सब छोड़कर फिर से शुरू करना पड़ता है, या आखिरी stable point तक वापस जाना पड़ता है। यह jetpack पहनकर development करने जैसा है—लक्ष्य तक भी जल्दी पहुँचते हैं, लेकिन दीवार से भी ज्यादा तेजी और दर्द से टकराते हैं
      AI best है या worst—इस बहस और tools कैसे इस्तेमाल करें वाली दौड़ के पीछे यह जानकारी दब जाती है कि क्या काम करता है और क्या fail होता है, और इस्तेमाल के दौरान अपना behaviour कैसे बदलना चाहिए। मैं खुद भी usage notes लिखना चाहता हूँ, लेकिन नया feature बनाना या UI flaws ठीक करना ज्यादा मज़ेदार लगता है, इसलिए टालता रहता हूँ
    • GitHub पर LLM से पहले भी छोड़े हुए game engines और काल्पनिक भाषाओं के compilers हजारों की संख्या में थे। 2000s की शुरुआत के operating system boards पर भी लगभग हर कोई अपना OS बना रहा था, और कुछ ने तो Firefox तक चला लिया था
      उपयोगी होने के लिए हर software का commercial या highly polished होना ज़रूरी नहीं; सिर्फ learning experiments से भी काफी कुछ सीखा जा सकता है
    • तकनीकी रूप से जितने गहरे जाते हैं, उतना ही replaceable माने जाने की संभावना बढ़ती है। क्योंकि संगठन में यह assumption स्वीकार कर लिया जाता है कि value खुद व्यक्ति या relationships से नहीं, बल्कि pure technical skill से बनती है
      लेकिन लगता है कि लोग अब यह मानने लगे हैं कि network effects, ownership, accountability जैसे accidental factors भी महत्वपूर्ण हैं। हालांकि paradox यह है कि कई technologists ऐसे ही factors से जुड़ी nepotism, arbitrary evaluation, और tech से ज्यादा bluster को महत्व देने वाली environments से बचकर technical domain में आए थे
    • मैं एक startup में काम कर चुका हूँ जहाँ feature development तक रोककर बड़े codebase को पूरी तरह rewrite किया गया था, लेकिन दूसरे project पर काम करने के कारण पूरी process miss करने के बाद जब लौटा, तब भी learning curve लगभग नहीं था। भाषा बदल गई थी, लेकिन core architecture, data structures और concepts वही थे
      Bun भी शुरू से redesign नहीं किया गया, बल्कि पहले नई language में लगभग वैसा ही port किया गया। LLM से पहले के अनुभव के आधार पर भी, team को जल्दी transition कराना हो तो सबसे सही तरीका है कि जितना हो सके simple और fast तरीके से दूसरी language में port किया जाए; rewrite duration X days को minimize करना अच्छा goal है
    • अपने लिखे code को गहराई से न समझने वाला रवैया extreme short-termism है। maintainers को AI-generated code और इंसानों द्वारा maintain किए जा सकने वाले code के बीच की सीमा कठिन तरीके से सीखनी पड़ेगी

  • कहा गया कि किसी ने मूल Zig implementation को modernize करके और best practices लागू कर bugs ठीक करते हुए 1 सेकंड से कम incremental build हासिल कर लिया। इससे संकेत मिलता है कि rewrite को justify करने वाली समस्या असल में खुद बनाई गई थी और हल की जा सकती थी
    https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
    Zig वाला version भी LLM इस्तेमाल करता है, इसलिए इसका culture war से कोई संबंध नहीं है। problem domain को सही से समझने वाला व्यक्ति हमेशा सिर्फ सैकड़ों हजार डॉलर के tokens जैसे resources झोंकने वाले व्यक्ति से बेहतर नतीजे दे सकता था

    • rewrite को justify करने वाला मुख्य मुद्दा build speed नहीं, बल्कि खासकर garbage-collected JavaScript objects के साथ interact करते समय होने वाले memory bugs थे। Zig में इसे सामान्य तौर पर रोकने का कोई तरीका नहीं है, और Buz ने इसे हल किया है—ऐसा दावा भी नहीं दिखता
    • यह project किसी गंभीर प्रयास से ज़्यादा meme या मज़ाक जैसा लगता है। यह मौजूदा 6 लाख lines को AI द्वारा बनाया गया खराब code बताता है, और कहता है कि ज़्यादातर subsystems को फिर से लिखे जाने तक इंसानों द्वारा लिखे contributions को reject किया जाएगा
      LLM से खराब code साफ़ करते हुए human contributions पर रोक लगाने वाले project को गंभीरता से लेना मुश्किल है

  • Bun rewrite की वजह से code porting और rewrite, तथा external dependencies की vendoring को कहीं ज़्यादा बेझिझक आज़माने लगे, और upstream projects के लिए सही न भी हो तो internal needs के हिसाब से specialize कर सके
    coding models को ज़्यादा ambitious काम सौंपते हुए test harnesses और language boundary के बाहर validation पर कहीं ज़्यादा ध्यान देने लगे। कई वर्षों तक चले बड़े rewrites में हिस्सा लिया है, लेकिन tests और feature parity बनाए रखते हुए improvements भी जोड़ने वाले Bun को एक जबरदस्त engineering success मानता हूँ

  • Bun rewrite के इर्द-गिर्द चर्चा में dramatic आरोप और personal attacks बहुत हैं, और लगता है कि लोग अपनी-अपनी गहरी ideological चिंताएँ उस पर project कर रहे हैं। यह लेख इस बात को लेकर skeptical है कि AI programmers को कितनी सफलता से replace कर सकता है, और Zig maintainer का मुद्दा LLM युग में open source ethics और भविष्य के ज़्यादा करीब था
    AI capabilities को लेकर optimistic नजरिए से देखें तो इस बात पर बहुत संदेह करने की वजह नहीं है कि skilled developer frontier LLM को guide करके पूरी library translate कर सकता है। ज़्यादा अहम follow-up सवाल मौजूदा लागत और यह है कि आगे चलकर AI को पूरी तरह अपनाने वाले और न अपनाने वाले खेमों में बंटवारा होगा या नहीं

    • टीम में Rust experience वाला कोई भी नहीं था
    • Bun की Zig→Rust porting, Zig, Rust, language porting, या LLM इस्तेमाल करने के तरीके पर generalize करने लायक बहुत कम सबक देती है। पहले और बाद के codebase में quantify करना मुश्किल ऐसी बहुत सारी characteristics हैं, और language, porting style तथा LLM coding को लेकर preferences भी शामिल हैं
      अगर वही result न निकले या token cost ज़्यादा आए तो कहा जा सकता है कि tool गलत इस्तेमाल किया गया, और result disappointing हो तो यह कहकर बचा जा सकता है कि वह सिर्फ proof of concept था और पिछले 6 महीनों में models इतने बेहतर हो गए हैं कि comparison संभव नहीं, इसलिए verifiable conclusions पाना मुश्किल है
    • LLMs दिखने में plausible लेकिन गलत results बनाने में बहुत अच्छे हैं, इसलिए skeptical होने की कई वजहें हैं। यह काम, result सही हो या नहीं, साफ तौर पर एक marketing event है, और Anthropic का बढ़ा-चढ़ाकर या facts से अलग announcements करने का इतिहास रहा है, इसलिए ज्यादा कड़ी verification चाहिए

  • जीत घोषित करने वाली announcement और honest लगने वाली deep dive तक कुछ जल्दबाज़ी भरी रही होंगी—ऐसा संदेह था
    LLM hype का मुख्य risk यह है कि typing और manual thinking से थके skilled developers को तुरंत gains देकर, दशकों की software experience को collateral की तरह इस्तेमाल करवाता है। असली cost bill बहुत बाद में आता है

    • typing software engineering में secondary है, लेकिन जिन स्थितियों में सचमुच typing bottleneck हो, वहाँ LLM valuable हो सकता है। हालांकि ऐसी स्थितियाँ दुर्लभ हैं

  • अगर लेख में यह fact जोड़ा जाए कि Rust-based Bun 17 जून से Claude Code में production में चल रहा था और main में merge होने के बाद canary build के रूप में भी उपलब्ध हुआ, तो उसकी credibility बढ़ेगी। इतने बड़े rewrite के लिए लंबा canary period पूरी तरह justified है

    • लेख में Anthropic के internal real-world usage को पहले ही cover किया गया है

  • Anthropic को शायद अगला version public release करने में खास interest न हो। Rust version एक महीने से ज़्यादा समय से लाखों users वाले Claude Code में चल रहा है, और Bun को acquire करने का मकसद भी संभवतः Claude Code ही था
    open source project खुद उनके लिए इतना महत्वपूर्ण नहीं हो सकता

    • अगर सच में सिर्फ Claude Code ही important था, तो TypeScript runtime की language बदलने के बजाय Claude Code को ही Rust में rewrite करना कहीं ज़्यादा efficient होता। करीब $800k की लागत संभवतः Anthropic के marketing budget से आई होगी, जिसका लक्ष्य बड़ा PR impact था
    • वे broader community को छोड़ेंगे इसकी संभावना कम है, और जितने ज़्यादा अन्य users होंगे, Anthropic को भी उतना फायदा होगा। इस release में problem हुई तो तीखी criticism मिलेगी और community trust को नुकसान हो सकता है, इसलिए वे सामान्य से ज्यादा सावधान लग रहे हैं
    • Bun web ecosystem का प्रमुख component है, इसलिए Anthropic का इसे AI से develop करना अपने-आप में बड़ा PR effect देता है
    • Claude Code तो किसी भी JavaScript runtime पर चल सकता होगा, फिर Bun की जरूरत क्यों थी—यह समझना चाहता हूँ
    • आखिरकार यह Claude-based code rewrite के advertisement के लिए marketing event लगता है। असुविधाजनक codebase से छुटकारा पाना हो तो Anthropic पर बड़ा पैसा खर्च करें—यह message सफलतापूर्वक पहुँच गया
      अगर मकसद Claude Code था, तो पहले उसी को rewrite करना चाहिए था, और अगर वे लगातार यह जोर देते रहे हैं कि अब वे खुद code नहीं लिखते, तो implementation language भी मायने नहीं रखनी चाहिए

  • जिसने भी software rewrite किया है वह इस stage को समझ सकता है। ज़्यादातर चीज़ें काम करती हैं, लेकिन regressions न रहें इसके लिए लगातार fixes करने पड़ते हैं, और release का pressure भी बहुत बड़ा होता है
    rewrite का decision सही था ऐसा लगता है, लेकिन शुरुआत से ही production environment में deploy करना नहीं चाहूँगा। Jarred अगर सीधे stable release देने के बजाय पहले release candidate उपलब्ध कराएँ, तो pressure कम हो सकता है