Bun के Rust पुनर्लेखन वाला PR merge हो गया

• PR #30412 में Bun को Rust में फिर से लिखने वाला बदलाव शामिल है, और इसे 14 मई 2026 को claude/phase-a-port branch से main में merge किया गया
• बदलाव का आकार 6,755 commits, 2,188 files, और +1,009,257/-4,024 lines के रूप में दिखाया गया है
• Jarred-Sumner ने कहा कि विस्तृत जानकारी वाली blog post जल्द आएगी
• बताया गया है कि यह बदलाव Bun के मौजूदा test suite को सभी platforms पर pass करता है, और कई memory leaks व flaky tests को ठीक किया गया है
• binary size 3MB~8MB कम हुई है, और benchmarks को neutral या उससे बेहतर बताया गया है
• सबसे महत्वपूर्ण कारण के रूप में कहा गया है कि टीम जिन memory bugs पर वर्षों से भारी development और debugging समय खर्च कर रही थी, उन्हें अब compiler-assisted tools की मदद से पकड़ा और रोका जा सकता है
• बताया गया है कि codebase अधिकांशतः वही है, और architecture व data structures भी वैसे ही रखे गए हैं
• यह भी स्पष्ट किया गया है कि Bun अब भी third-party libraries का कम उपयोग करता है, और async Rust का उपयोग नहीं करता
• उपयोगकर्ता bun upgrade --canary से इस बदलाव को आज़मा सकते हैं
• Jarred-Sumner ने समस्या होने पर issue दर्ज करने का अनुरोध किया, और कहा कि अगर thread बहुत गरम हो गया तो उसे lock किया जा सकता है
• non-canary version में शामिल होने से पहले अभी optimization का काम बाकी है
• cleanup का काम भी अभी बाकी है, और इसे आगे आने वाली PR series में किया जाएगा

[xguru]

वाह, दस लाख लाइनों वाला PR मर्ज हो गया। Zig से Rust पर सीधे एक ही बार में चले गए।
कह रहे थे, पता नहीं ये मर्ज होगा भी या नहीं~~, लेकिन सिर्फ एक हफ्ते में अच्छी तरह चल रहे कोड की भाषा एक झटके में बदल दी, हाहा
लग रहा है कि AI-assisted coding की वजह से कुछ सचमुच ऐतिहासिक हो रहा है।

[heycalmdown]

सच में, उन्होंने कहा था कि यह बस टेस्ट कर रहे हैं और शायद इसका इस्तेमाल नहीं करेंगे।

[freedomzero]

जब zig में नहीं किया, तो सीधे Rust पर कूद जाने की ये हिम्मत, दंग कर देने वाली

[GN⁺]

Hacker News की राय

• अगर घोषणा में कहा गया है कि rewrite में 1 हफ़्ता लगा, तो यह सोचने वाली बात है कि Zig idioms को Rust idioms में मैप करने वाली इस बेहद विस्तृत guideline file को तैयार करने में कितना समय लगा होगा: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
  इसके अलावा Pointers & ownership और Collections सेक्शन को देखें तो लगता है कि Bun codebase पहले से ही internal smart pointer types इस्तेमाल कर रहा था, ताकि उन्हें Rust equivalents के साथ 1:1 मैप किया जा सके, और bun_collections Rust crate भी पहले से मौजूद था
  यह rewrite बहुत पहले से तैयार किया जा रहा था, और ऐसा लगता है कि Anthropic acquisition talks के दौरान Bun टीम ने इसे प्रस्तावित किया था

  • LLM से जुड़े लेख पढ़ते समय क्या सच है, यह समझना मुश्किल होता है, और यहाँ Hacker News comments में भी वही हाल है
    इसमें लगे पैसे बहुत बड़े हैं, इसलिए community में marketing shills घुसाने की प्रेरणा साफ़ है, और कुछ लोग बस camp mentality में फँसे हुए हैं
    अब जब Anthropic Bun का मालिक है, तो इस काम को वास्तविकता से आसान दिखाने की प्रेरणा भी काफ़ी है
  • नतीजे में आए Rust code की quality अच्छी है या नहीं, line count उचित है या नहीं, और codebase इस काम के लिए शुरू से कितना तैयार था—इन सबको अलग रख दें, तो लगभग 10 लाख lines output की consistency या quality बढ़ाने वाले pre-work artifact के रूप में 622-line document को अपेक्षाकृत छोटा cost माना जा सकता है
    output का scale इतना बड़ा है कि यहाँ multiplier effect दिखता है
    फिर भी यह जानने की जिज्ञासा है कि इन rules को बनाने के लिए कितनी tacit knowledge चाहिए थी, और इस file को कितनी बार iterate करके सुधारा गया
    उदाहरण के लिए, मैं जानना चाहूँगा कि इन rules में से कितने translation iteration के दौरान मिले failure cases से आए
  • आपने using internal smart pointer types that map 1-to-1 to Rust equivalents कहा, लेकिन smart pointers का आविष्कार Rust ने नहीं किया
    अगर आप pointers वाली किसी दूसरी language में code लिखते हैं, तो आप पहले से ही दिमाग में ऐसे types को model कर रहे होते हैं
    और यह कहना भी गलत है कि bun_collections Rust crate पहले से मौजूद था
    वह codebase के PR का ही हिस्सा है, पहले से मौजूद चीज़ नहीं
  • यह Anthropic के gcc demo जैसा ही है
    शक कम करना और IPO का माहौल बनाना बहुत आसान होता, अगर AI को आगे बढ़ाने के लिए ज़रूरी छिपे हुए काम को अलग repository में public कर देते और सबको result reproduce करने देते
    आख़िर ग्राहक भी तो “7 दिन” में इस्तेमाल होने लायक 10 लाख lines code ही पाना चाहते हैं, है न
    सब लोग इसे अपने workflow में reproduce करते, और Anthropic usage metrics भी बढ़ जाते
    अगर नतीजा सचमुच शानदार होता, तो शायद वे links और instructions वाला blog post पहले ही निकाल चुके होते
    हो सकता है कि इस समय वह blog post लिखा जा रहा हो और मैं गलत साबित हो जाऊँ
  • ऐसा लगता है कि Zig version of Bun में 3 pointer types थे जो existing Rust pointer types से साफ़-साफ़ मैप हो जाते थे, और बाकी 7~8 के लिए नए types बनाने पड़े
    क्या यही conspiracy theory का मूल है
    bun_collections भी porting guide से बहुत पुराना नहीं लगता

• [phone] का मतलब है कि Bun अब 10 लाख lines Rust code पार कर चुका है
  यह अब Rust compiler खुद जितना बड़ा होने के क़रीब पहुँच रहा है
  हालाँकि BunJS ज़्यादातर JavaScript interpreter wrapper और NodeJS libraries की reimplementation है, यानी Rust standard library wrapper के क़रीब
  BunJS अब LLM युग में software complexity management का canary बनता दिख रहा है

  • mostly a JavaScript interpreter wrapper कहना सही नहीं है
    Bun batteries-included JavaScript और CSS transpiler (parser), minifier, bundler, npm-जैसा package manager, Jest-जैसा test runner है, और built-in Postgres, MySQL, Redis clients जैसे runtime APIs भी देता है
    ऐसे में code बहुत ज़्यादा होना स्वाभाविक है
  • Bun JavaScript interpreter नहीं, बल्कि NodeJS libraries और कई दूसरी libraries की reimplementation के ज़्यादा क़रीब है
    Bun JavaScriptCore को JS engine की तरह इस्तेमाल करता है, इसलिए Bun खुद JavaScript parsing, interpretation, या JIT नहीं करता, या कम से कम नहीं करना चाहिए
    सुधार: मैंने गलत पढ़ा। “JavaScript interpreter wrapper” कहा गया था, तो यह सही अभिव्यक्ति है
  • iOS पर phone number detection सामने वाले + की वजह से है या किसी और कारण से, पता नहीं, लेकिन mobile पर line count changes के नीचे underline आ जाती है और tap करने पर call किया जा सकता है
    अगर यह diff size की वजह से है, तो काफ़ी मज़ेदार है
  • rewrite से पहले भी Bun codebase का लगभग उतना ही line count था
    rewrite का नतीजा भी लगभग वही LOC देना कोई अजीब बात नहीं है
  • JavaScriptCore wrapper का 10 लाख lines होना इस बात का शानदार उदाहरण है कि agents क्या कर सकते हैं

• $ rg 'unsafe [{]' src/ | wc -l का नतीजा 10428 है, और $ rg 'unsafe [{]' src/ -l | wc -l का नतीजा 736 है
  language के हिसाब से Rust 1443 files 929213 lines, Zig 1298 files 711112 lines, TypeScript 2604 files 654684 lines, JavaScript 4370 files 364928 lines, C 111 files 305123 lines, C++ 586 files 262475 lines, और C Header 779 files 100979 lines हैं

  • Rust में यह अच्छा है कि potentially unsafe code को इस तरह target करके search किया जा सकता है
    Zig में unsafe code कैसे search करते हैं?
    या बस मान लेना चाहिए कि वह हर जगह है
  • अगर आधी files में unsafe keyword है, तो यह कोई अच्छी rewrite नहीं लगती
    अगर code का लगभग आधा हिस्सा अब भी unsafe है, तो Rust में rewrite करने का मतलब क्या है
  • उम्मीद है Mythos वैसा ही world-class है जैसा वे दावा करते हैं। अब इसकी सच में ज़रूरत पड़ेगी
  • घर में memory safety है!
    घर में जो है: 10428

• हम अभी भी इस पर blog post लिख रहे हैं, और आगे और detail share करेंगे
  background चाहिए तो Bun v1.3.14 और उससे पहले के release notes में bug fix list देख सकते हैं
  Rust यह सब कुछ अपने आप नहीं पकड़ता। references को बहुत देर तक पकड़े रहने से होने वाले leaks, या JS boundary के पार reentry वाले सारे issues की ज़िम्मेदारी अभी भी हमारी ही है
  लेकिन उस list का बड़ा हिस्सा use-after-free, double-free, और error paths में free करना भूल जाने जैसी चीज़ों का है, और ये compile errors बन जाती हैं या automatic cleanup में बदल जाती हैं

  • 9 दिन पहले आपने यह कहा था[0]:
    I work on Bun and this is my branch
This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
    शायद यह overreaction नहीं था?
    [0]: https://news.ycombinator.com/item?id=48019226
  • blog post का इंतज़ार रहेगा
    यह जानना दिलचस्प होगा कि bugs छाँटने के लिए क्या आप Zig और Rust binaries को बड़े पैमाने पर real applications पर side-by-side चलाएँगे, या संभव हो तो production में shadow execution करेंगे
  • अगर मैं paid customer होता, तो जानना चाहता कि इस काम की cost कितनी आई
    क्या इसका कोई मोटा अनुमान दे सकते हैं
  • यह भी जानना चाहूँगा कि क्या आपने दोनों binaries की तुलना करने वाला कोई end-to-end fuzz test implement किया है या करने वाले हैं
    और इस release को users के workflows तोड़े बिना ship करने की आपकी concrete plan क्या है
  • क्या इससे Bun Workers API की stability issues ठीक होने की संभावना है? https://bun.com/docs/runtime/workers

• लगभग 9 दिन पहले Jarred ने लिखा था कि यह merge होगा, इसका कोई भरोसा नहीं, और यह overreaction है
  विडंबना है

  • यह open source leadership की best practice जैसी लगती है
    सोचिए अगर Linus कहता कि वह Linux kernel को rewrite नहीं करेगा, और फिर एक दिन उठकर पूरी machine-assisted Rust rewrite merge कर देता, तो कैसी अफ़रातफ़री मचती
  • जब आप company के मालिक नहीं रहते, तो आपकी बात को सुरक्षित रूप से ignore किया जा सकता है
    साफ़ था कि उसे खर्च हुए token cost को justify करना था
  • लेकिन इससे यह संभावना ख़ारिज नहीं होती कि यह merge हो सकता था

• वाह, आगे इसे देखना दिलचस्प होगा
  इस code का review हुआ होगा, इसकी संभावना लगभग नहीं है, लेकिन शायद अब हम उस post-human era में पहुँच गए हैं जहाँ model के code लिखने और review करने पर भरोसा किया जा सकता है
  यह Gastown जैसा है, बस कहीं ज़्यादा प्रसिद्ध project में हो रहा है
  यह देखना दिलचस्प होगा कि आगे यह project नए features कैसे जोड़ पाएगा, या जोड़ भी पाएगा या नहीं
  क्या किसी को पता है Anthropic Bun का इस्तेमाल ठीक कैसे करता है?
  क्या यह Claude Code का हिस्सा है?
  अब Bun इस्तेमाल करने को लेकर मैं काफ़ी चिंतित हूँ, लेकिन यह चिंता Claude के इस्तेमाल पर कितनी लागू होती है, यह साफ़ नहीं है

  • ऐसा बिलकुल नहीं है कि model के code लिखने और review करने पर भरोसा किया जा सकता है
  • सारे tests pass हुए
    अगर आप automatic language translation पकड़ने के लिए test suite पर भरोसा नहीं कर सकते, तो फिर आपको शुरू से ही उस test suite पर बिल्कुल भरोसा नहीं करना चाहिए :)
  • Anthropic Bun का इस्तेमाल कैसे करता है, यह तो नहीं पता, लेकिन ऐसा लगता है कि इसका इस्तेमाल discussion window को इस दिशा में शिफ्ट करने के लिए किया जा रहा है कि लाखों lines को बेधड़क merge करना भी ठीक है
  • test suite किस हालत में है

• automatic translation के साथ प्रयोग करना सच में रोमांचक है, लेकिन backward compatibility issues बहुत आने का डर है
  मैंने commit देखना शुरू किया, और मूलतः “tests pass नहीं हो रहे” वाली समस्या को tests बदलकर हल किया जा रहा है
  जो programs पहले से deploy हो चुके हैं, उनमें चीज़ों को सही तरह चलाने का असली काम तो अब शुरू होगा
  जो थोड़ी राहत की बात है, वह यह कि server-side JS community किसी कारण से पहले ही बार-बार होने वाले breakage की आदी है

  • यह सोचकर असहज लगता है कि मेरे इस्तेमाल वाले runtime में ऐसा code जाएगा जिसे किसी इंसान ने देखा तक नहीं
    लेकिन अगर यह सच में बिना बड़ी दिक्कत के काम करता है, तो यह काफ़ी चौंकाने वाली बात होगी
  • मुझे नहीं पता ये फैसले LLM ने लिए या नहीं, लेकिन मुझे हमेशा लगा है कि Claude में समस्या का सही समाधान खोजने के बजाय tests बदलकर निकल जाने जैसा संदिग्ध व्यवहार ज़्यादा देखने को मिलता है
    GPT/Codex इस मामले में ज़्यादा ईमानदार लगते हैं
  • यह तुरंत stable release बनेगा, ऐसा नहीं लगता, लेकिन अगर मैं गलत साबित हो जाऊँ तो खुशी होगी
    मैं इस पूरी rewrite को लेकर skeptical हूँ, और Jarred Sumner की बहुत बड़ी internet following है, इसलिए यह advertisement जैसा लगता है
  • “tests pass नहीं हो रहे” समस्या को tests बदलकर हल करने का उदाहरण: https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...
    कमाल है! बस tests में random sleep(1) जोड़ दो। चिंता मत करो, सब ठीक हो जाएगा!
  • मैं tests खंगालकर देखना चाहता हूँ कि कोई वाकई महत्वपूर्ण बदलाव हुआ भी है या नहीं, लेकिन GitHub diff तक load नहीं कर पा रहा

• Bun इस्तेमाल करने वाले मेरे कुछ ही projects को मैं किसी और चीज़ पर migrate करने वाला हूँ
  मैं ऐसी governance पर भरोसा नहीं करता जो ऐसे लापरवाह बदलाव की इजाज़त दे

  • Deno शानदार है, लेकिन मुझे लगता है कि उसे उतना प्यार नहीं मिलता
    वह शुरू से अच्छी तरह लिखा गया था, इसलिए rewrite की ज़रूरत भी नहीं पड़ी
  • मैं भी बस node का इस्तेमाल जारी रखूँगा
    दूसरी तरफ़, अग्निपरीक्षा कैसी होती है यह देखना दिलचस्प होगा, और लंबे समय में शायद समस्याएँ आख़िरकार सुलझ जाएँगी

• यह एक शिक्षाप्रद thread है। एक हफ़्ता पहले वाला वही thread, जहाँ Jarred ने फिर से merge के फ़ैसले से दूरी बनाई थी, और ढेर सारे foot soldiers उन लोगों पर हमला कर रहे थे जिन्होंने कहा था कि यह जल्दी merge हो जाएगा:
  https://news.ycombinator.com/item?id=48073680
  अब पीछे मुड़कर देखें तो वह बात ज़्यादा टिकाऊ नहीं निकली, है न?

  • “यह पूरा thread overreaction है। जो code काम भी नहीं करता, उस पर 302 comments। हमने rewrite के लिए commit नहीं किया है। इस code के पूरी तरह फेंक दिए जाने की संभावना बहुत ज़्यादा है।” — वहाँ से लेकर महज़ 10 दिनों में पूरा merge हो जाना सच में पागलपन जैसा लगता है, यहाँ तक कि जो चीज़ महज़ experimental curiosity जैसी लग रही थी, वह भी शामिल है
  • दुनिया में कितने सत्ता-भक्त लोग हैं जिन्हें यह ज़्यादा फर्क नहीं पड़ता कि वे किसके जूते चाट रहे हैं—यह देखकर हर बार हैरानी होती है

• अगर इसमें ज़रा भी गड़बड़ हुई, तो अपने ही माल के नशे में रहने वाले drug dealer वाली खिल्ली बहुत लंबी और उदास तरह से चलेगी

  • बहुत से लोग भावनात्मक रूप से इस संभावना के लिए तैयार नहीं हैं कि इसमें शायद ज़रा भी गड़बड़ न हो
  • क्या leaked Claude Code source देखना ही पहले से मज़ाक उड़ाने के लिए काफ़ी नहीं था
  • वे पहले से ही अपने ही माल के नशे में हैं
    क्या आपने Mythos paper पढ़ा है? anthropomorphism काफ़ी ज़्यादा है
    हो सकता है यह बस सस्ता attention-seeking हो, लेकिन अगर वे सच में मानते हैं कि LLMs conscious हैं... वाह