Bun का Rust rewrite: "codebase बुनियादी miri checks में fail हो रहा है और safe Rust में UB की अनुमति देता है"

• यह issue अभी Open स्थिति में है, और बातचीत off topic के कारण lock की गई है तथा collaborator तक सीमित है, और संबंधित fixes के रूप में #30728 और #30876 लिंक किए गए हैं
• रिपोर्ट करने वाले ने दिखाया कि PathString::init से बनाया गया मान मूल Box के drop होने के बाद भी slice() कॉल कर सकता है, जिसके कारण Miri ने dangling reference आधारित Undefined Behavior रिपोर्ट किया
• reproduction code में Box::new(*b"Hello World") से बना buffer PathString::init(&*test) को दिया जाता है, फिर drop(test) के बाद init.slice() कॉल किया जाता है; Miri ने core::slice::from_raw_parts बिंदु पर error दिया
• robobun ने पुष्टि की कि समस्या reproduce हुई, और सारांश दिया कि PathString::init safe function होने के बावजूद slice lifetime मिटा देता है, जिससे dangling &[u8] बनाया जा सकता है
• लिंक किया गया #30728 PathString::init और dir_iterator::next() में मौजूद समानांतर खामी को unsafe fn में बदलने, और लगभग 70 call sites पर backing allocation को स्पष्ट करने वाले SAFETY comments जोड़ने की दिशा में है
• उसी fix में compile_fail doctest भी शामिल है, जो यह अनिवार्य करता है कि तीन signatures में unsafe keyword होना चाहिए, और resolver के readdir-error fd leak का fix भी इसमें शामिल बताया गया है
• AwesomeQubic ने अतिरिक्त रूप से कहा कि PathString::init provenance को भी मिटा देता है और MIRIFLAGS=-Zmiri-strict-provenance में भी fail होता है
• JavaDerg ने समझाया कि init &[u8] की implicit lifetime लेता है, unsafe operation के जरिए उसे मिटाता है, और 'static जैसा दिखने वाला Self लौटाता है, जिससे use-after-free और invalid aliasing संभव हो जाते हैं
• JavaDerg ने चेतावनी दी कि Rust के safety model के ऊपर UB अप्रत्याशित जगहों पर समस्याएँ पैदा कर सकता है, इसलिए unsafe के उपयोग की व्यापक समीक्षा ज़रूरी है, और दूसरी भाषाओं की memory management शैली को Rust में 1:1 अनुवाद करना उपयुक्त नहीं है
• robobun ने संबंधित commits के रूप में PathString::init signature stays unsafe test और dir_iterator: make next() unsafe; audit call sites जोड़े
• SimonReiff ने repository की Rust files में comments को छोड़कर unsafe grep का परिणाम 13255 lines बताया, और तुरंत rollback करने तथा AI code usage policy और process पर चर्चा की मांग की
• Jarred-Sumner ने कहा कि Rust port फिलहाल मूल Zig code के जितना संभव हो उतना करीब 1:1 mapping को शुरुआती आधार मानकर चल रहा है और उसमें सुधार किया जा रहा है, और Rust code के bugs या unsound behavior पर नए issues लगातार रिपोर्ट करने का अनुरोध किया

[GN⁺]

Hacker News की टिप्पणियाँ

• मेरी Bun में शुरुआती दिलचस्पी इसलिए थी क्योंकि यह Zig में लिखा गया था, और Zig मुझे इसलिए आकर्षित करता था क्योंकि मैं Andrew Kelley के फैसलों और रुचि पर भरोसा करता था
  बाद में Bun में मेरी दिलचस्पी बढ़ने के कारण भी आखिरकार वही थे जिन्हें मैं सम्मान देने लायक चुनाव मानता था, और Anthropic द्वारा अधिग्रहण के बाद भी मैं सावधानी से आशावादी रहना चाहता था
  लेकिन यह कदम भरोसा करना मुश्किल बना देने वाला फैसला लगता है; Rust खुद समस्या नहीं है, पर अगर Anthropic Bun को इस तरह मैनेज करता है, तो इसे टूलबॉक्स के एक भरोसेमंद हिस्से के रूप में आगे दाँव पर लगाना मुश्किल लगता है
  सिर्फ कोड नहीं, उसके पीछे की सोच पर भी भरोसा होना चाहिए, और अभी यह Anthropic के अंदरूनी उपयोग वाले टूल जैसा लग रहा है

  • Bun सच में बहुत दिलचस्प प्रोजेक्ट है, लेकिन issues में आने वाले segmentation fault की संख्या इतनी चिंताजनक थी कि इसे गंभीर production environment में इस्तेमाल करना मुश्किल लगता था
    यह नया रास्ता उसे ठीक करने का एक तरीका हो सकता है, इसलिए देखना होगा
  • मैं समझता हूँ, लेकिन मेरा शुरुआती नज़रिया काफ़ी अलग था
    एक पुराने Deno फ़ैन के रूप में Bun मुझे कम महत्वाकांक्षी Deno जैसा लगता था, और क्योंकि मैं Zig सीखना नहीं चाहता था, इसलिए शौकिया तौर पर भी Bun को खुद छूने की संभावना कम थी
    लेकिन पिछले कुछ वर्षों में runtime से कम बँधे तरीके से काफ़ी बड़े TypeScript codebase को maintain करने की कोशिश करते हुए Bun के लिए मेरी रुचि बढ़ी, और मैं किसी खास TypeScript runtime को requirement नहीं बनाना चाहता था, फिर भी Bun लगातार Deno जैसी वजहें देता रहा: Postgres, SQLite, S3, WebSocket, local secret storage, bundling, compilation, और तेज़ performance
    अभी मैं कई API servers और frontend app servers को bun build --compile --bytecode single executable के रूप में बनाकर लगभग हर जगह चला और deploy कर रहा हूँ
    हालाँकि मुझे नहीं लगता कि यह तरीका आम है, और अगर यह LLM-आधारित porting विफल होती है, तो मैं Bun से जुड़े सारे फैसलों पर पछताने की आदर्श स्थिति में हूँ
    फिर भी अगर यह विफल नहीं होती, तो यह दिलचस्प है। यह दिखाएगा कि LLM से क्या संभव है, और आगे Bun का Rust में develop होना मेरी नज़र में एक प्लस है
    और अगर यह विफल भी होती है, तब भी यह जानकारी के रूप में महत्वपूर्ण है। Bun प्रमुख TS/JS runtimes में से एक है, और Anthropic के पास भारी संसाधन, नवीनतम models तक पहुँच, और लगभग असीमित budget है; अगर ये लोग भी नहीं कर पाए, तो इसका मतलब होगा कि अभी यह सच में संभव नहीं है
  • जानना चाहूँगा कि Bun आपको Deno से ज़्यादा आकर्षक क्यों लगा

• अगर वे Zig को unsafe Rust में ही port करने वाले थे, तो समझ नहीं आता कि translation tool क्यों नहीं बनाया
  language constructs को one-to-one map करके और codebase के patterns को hardcode करके deterministic conversion मिल सकता था; जैसा मेरे एक दोस्त ने कहा, “zig translate-c को c2rust से जोड़ दो” जैसा कुछ भी किया जा सकता था
  अभी जो नतीजा है वह input से भी कम भरोसेमंद लगता है। Input memory-safe नहीं था, लेकिन इंसानों ने लिखा था; output memory-safe भी नहीं है, vibe coding से बना लगता है, और ऐसा भी नहीं लगता कि किसी इंसान ने उसे ठीक से देखा हो
  इस तरह के काम में agent-style AI का इतना ज़्यादा इस्तेमाल करने का मतलब समझ नहीं आता

  • अगर आपने c2rust का output देखा हो, तो ऐसा कहना मुश्किल होगा
    वह C की unsafe pointer semantics को Rust की unsafe function libraries से नकल करने की कोशिश करता है, इसलिए नतीजा भयानक होता है
    कुछ साल पहले मैं OpenJPEG bug देख रहा था, तब किसी ने उसे c2rust से convert करके देखा था, और वह converted unsafe Rust भी C code की तरह उसी जगह segmentation fault दे रहा था
    compatible होना safe होने जैसा नहीं है
    असली बात यह है कि string manipulation C या unsafe Rust में नहीं करनी चाहिए। यह उस काम के लिए बिल्कुल सही tool नहीं है
  • उन्होंने बनाया था। एक बहुत dynamic translation tool
  • “zig translate-c को c2rust से जोड़ दो” वैसा काम नहीं करता जैसा सुनने में लगता है
    ऐसे tools में errors बहुत होते हैं और वे code को बहुत verbose और समझना मुश्किल बना देते हैं
    छोटे apps के लिए शायद ठीक हो, लेकिन पूरे rewrite के लिए उपयुक्त नहीं
  • मैंने भी दूसरे thread में लगभग यही बात कही थी, लेकिन software लिखने के तरीके पर मेरा नज़रिया थोड़ा अलग है
    Zig को Rust में translate करने के बजाय, मैं static Python में JPEG parser लिखकर फिर उसे हर भाषा के idiomatic structure के अनुसार Zig और Rust में lower करना बेहतर मानता हूँ
    इसी लिए मैंने इस उद्देश्य के अनुरूप Python dialect parser बनाया है, और Rust/Zig की कुछ ऐसी खूबियाँ अपनाने की कोशिश कर रहा हूँ जो translation आसान बनाती हैं, जबकि ज़्यादातर Python code के साथ compatibility भी बनी रहे
    JPEG parser भी example assets में शामिल है
    https://github.com/py2many/static-python-skill
    https://github.com/py2many/spy-ast
  • codebase को दूसरी language में port करने का सही तरीका है syntax tree parse करना और deterministic, verified transformations लागू करना

• यह issue ग़लतफ़हमी पैदा करता है
  समस्या सिर्फ यह नहीं है कि miri से पकड़ी जा सकने वाली undefined behavior मौजूद है, बल्कि यह है कि ऐसे APIs expose किए गए जो safe code से undefined behavior पैदा कर सकते हैं। miri भी उसे तभी पकड़ता है जब ऐसा साबित करने वाला test लिखा जाए
  किसी unsafe language से शुरुआती porting के दौरान ऐसा हो जाना पूरी तरह अविवेकपूर्ण नहीं है
  Bun team भी बाद में unsafe code को wrap करने वाले functions सही हैं या नहीं, इसे जाँचती हुई लग रही है
  porting के दौरान कुछ unsafe functions को अस्थायी रूप से safe mark कर देना अपने-आप में बहुत बड़ी समस्या नहीं है, लेकिन उन्हें उसी हालत में main repository में merge कर देना थोड़ा अजीब है
  असली समस्या तब होगी जब इसी हालत का code release किया जाए
  अफ़सोस की बात यह है कि tests को तुरंत miri पर चलने के लिए सेट नहीं किया गया। LLM अच्छे tests पर अच्छी प्रतिक्रिया देते हैं
  मैं यह बात इस GitHub issue की वजह से नहीं कह रहा, बल्कि इसलिए कि दूसरा test [1] सच में ऐसी undefined behavior call करता है जिसे miri पकड़ लेता; हालाँकि जिस code पर वह test है, वह कहीं इस्तेमाल होता नहीं दिखता, इसलिए वास्तविक असर बड़ा नहीं लगता
  यह porting का शुरुआती दौर है, इसलिए बाद में इसे ठीक किया जा सकता है, और संभव है कि ऐसी unsafe code भी हट जाए जिसकी असल में ज़रूरत ही नहीं
  [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - पहले mutable reference से निकले pointers उसी object पर नया mutable reference बनते ही invalidate हो जाते हैं। C के अंदाज़ में कहें, तो “mutable reference” को “ऐसा restrict reference जिस पर मामूली बदलाव किए जाते हैं” की तरह सोच सकते हैं
  सही तरीका यह होता कि सारे pointers उसी mutable reference से derive किए जाते, लेकिन ऐसा नहीं किया गया
  GitHub पर भीड़ लगाकर spam करने से बस public में काम करने की संभावना घटती है। उम्मीद है लोग ऐसा नहीं करेंगे
  और बेहतर होगा कि code publish करने लायक स्थिति में आने तक फैसला रोककर रखा जाए। work-in-progress की हालत को judge करना न तो fair है, न बहुत दिलचस्प

  • जब कोई project पहली बार 1.0 तक पहुँचता है, तो बहुत से लोग उम्मीद करते हैं कि main branch हमेशा काम करेगी
    क्योंकि CI/CD लगभग इसी धारणा पर टिका है कि हर commit काम करने लायक होना चाहिए
    पूरे rewrite जैसे non-working work-in-progress code को branch में होना चाहिए
    तभी security fixes जैसी ज़रूरत आने पर भी working main बनाए रखना संभव होता है

• यह नतीजा चौंकाने वाला नहीं है, क्योंकि माँगी गई चीज़ लगभग literal porting थी
  शायद पहले Bun को किसी ज़्यादा मजबूत type system वाली language में ले जाना, और फिर उसी type system को आधार बनाकर आगे सुधार करना बेहतर रणनीति हो सकती है
  पहली ही stage में perfection माँगने से तो यह बेहतर लगता है

  • असल में वे यही कर रहे हैं
    आने वाले issues को handle करते जा रहे हैं
  • prompt में बस “undefined behavior न हो” जोड़ दो, फिर ठीक हो जाएगा
  • अब लगता है कि miri जैसे tools से rewrite पर pressure डालकर Claude Code से उसे अपने-आप improve कराया जा सकता है
  • ज़्यादातर literal translate किए गए, कुछ हिस्सों में unsafe Rust code से undefined behavior निकलना कोई आश्चर्य की बात नहीं
    लेकिन यह निराशाजनक है कि Rust code के APIs unsafe के रूप में mark नहीं किए गए, फिर भी वे undefined behavior पैदा कर सकते हैं
    अगर मैं ऐसा translation करता, तो सावधानी से शुरू में सब या ज़्यादातर चीज़ें unsafe mark करता
    फिर हर individual हिस्से की safety को धीरे-धीरे verify करता

• सच कहूँ तो यह सुनकर थोड़ा हैरान हुआ कि इसे सिर्फ एक हफ्ते में पूरी तरह working बना दिया गया
  मेरा side project भी मिलते-जुलते ambition वाला है https://tsz.dev, लेकिन मैं यह दावा नहीं कर सकता कि वह सफल हो गया है
  मैं लगातार tests जोड़कर behavior verify कर रहा हूँ, और TypeScript के अपने सारे tests pass करने के बाद भी उम्मीद के मुताबिक bugs मिल रहे हैं
  tsc behavior से match करने की कसौटी वाकई बहुत ऊँची है
  https://github.com/type-challenges/type-challenges
  मुझे LLM से बहुत-सा code लिखवाने में कोई आपत्ति नहीं, लेकिन अब जब इस speed पर code निकल सकता है, तो verification 100 गुना ज़्यादा मजबूत होना चाहिए

  • “experiment” के नाम पर एक हफ्ते में लगभग बिना review वाले million-line scale code को merge कर देना चौंकाने वाला है
    agents इस्तेमाल करने से मुझे एतराज़ नहीं, लेकिन ऐसी चीज़ को जल्दबाज़ी में करना और community को अचानक चौंका देना बहुत amateurish लगता है
    यह वैसा व्यवहार है जैसा किसी बहुत उत्साही junior engineer से उम्मीद की जाती है
  • https://tsz.dev/sound-mode/
    यह शानदार है। TypeScript को ऐसी चीज़ों की और ज़रूरत है, और उम्मीद है यह इतना जाना जाए कि Microsoft भी इसे अपनाए
    लेकिन इसे sound mode कहना थोड़ा सावधानी से करना चाहिए
    “यह गणितीय अर्थ में soundness proof नहीं है, और third-party .d.ts files को true नहीं बना देता” इस वाक्य में दो बिल्कुल अलग बातें मिली हुई हैं
    पहली, soundness एक mathematical concept है। अगर कुछ sound है, तो वह सच में sound है, यानी details को manually जाँचे बिना भी compiler पर भरोसा किया जा सकता है
    implementation bugs हों तो चीज़ गलत चल सकती है, लेकिन उन्हें ठीक किया जा सकता है; soundness का मतलब है कि spec या type system में सैद्धांतिक रूप से ऐसा bug नहीं है जो इसे गलत बना दे
    दूसरी, वास्तविक languages में ऐसे unchecked features की ज़रूरत होना पूरी तरह सामान्य और अपेक्षित है जिनके सही उपयोग पर हम इंसानों पर भरोसा करते हैं। जैसे Haskell का unsafeCoerce या Java का sun.misc.unsafe
    असली समस्या तब है जब ऐसे features इस्तेमाल ही न किए गए हों, फिर भी type system टूट जाए
  • इसे working कहना थोड़ा बढ़ा-चढ़ाकर कहना है
    मैंने code को बस कुछ मिनट देखा, लेकिन optimization on होते ही यह बुरी तरह टूट जाएगा, ऐसा लगता है
  • संभव है कि वे महीनों से इसकी planning और experiments कर रहे हों
    बड़े existing test suite के अलावा उनके पास agents को parallelize करने के tools और लगभग असीमित token budget भी रहा होगा, इसलिए बहुत निराश होने की ज़रूरत नहीं

• एक किताब है [0] जिसने attention और media को लेकर मेरी सोच बहुत बदल दी
  किताब खुद बहुत महान नहीं है, लेकिन यहाँ से जुड़ी एक महत्वपूर्ण बात बताती है
  बड़े और चमकदार announcements की reach, जैसे “Bun को कुछ ही हफ्तों में memory-safe Rust में rewrite कर दिया गया”, और corrections की reach, जैसे किसी पुराने article की footnote या GitHub issue के बीच बहुत बड़ा असंतुलन होता है
  इस असंतुलन को marketing और PR industry अच्छी तरह समझती है और सक्रिय रूप से इस्तेमाल करती है
  [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

  • इस बार के माहौल को देखकर लगता है कि बहुत से लोग code पर किसी भी तरह की आलोचना ढूँढकर उसे जितना हो सके amplify करना चाहते हैं
    अभी तक ज़्यादातर चीज़ें काफ़ी सतही लगती हैं
    इतना बड़ा LLM-assisted port merge करना निश्चित रूप से बहुत साहसी फैसला था, लेकिन असल output पर लोग जो बातें उठा रहे हैं उनमें मुझे ऐसा बहुत कम दिखा जो दूसरे work-in-progress ports से बदतर लगे
    हर issue को बढ़ा-चढ़ाकर पेश किया जा रहा है
  • मुझे तो पहले यही संदेह है कि क्या उन्होंने सच में memory-safe होने का दावा किया भी था
    इस विषय की हर चर्चा में दर्जनों टिप्पणियाँ थीं कि vibe-coded codebase un-audited unsafe blocks से फटने वाला है, और ऐसे लोग हल्की-फुल्की review कर रहे हैं जिन्हें Rust समझ ही नहीं आती
    कभी-कभी तो ऐसा लगता है जैसे कुछ लोग इस विचार से ही नाराज़ हैं कि किसी भी programming language को समझना ज़रूरी होता है
  • क्या यह वही विचार है जिसे इस उद्धरण में कहा जाता है: “झूठ आधी दुनिया घूम आता है, उससे पहले कि सच अपने जूते भी पहन पाए”
  • सिर्फ marketing और PR ही नहीं, mainstream media भी जानती है कि पहले बकवास चला दो और बाद में वापस ले लो, तब भी उसका असर बना रहता है
    लोग आम तौर पर original article या headline याद रखते हैं, correction तक पहुँचते ही नहीं
  • मैं तो उल्टी दिशा की समस्या की बात करने वाला था
    porting अभी जारी है, इसलिए बड़ा चमकदार announcement हुआ ही नहीं है, और यह अभी complete या release भी नहीं हुई
    मुझे जो चमकदार घोषणा दिख रही है, वह ज़्यादा इस ongoing code पर hit-and-run style में तंज कसना है, और यह संकेत देना है जैसे team ने दावा किया हो कि सब पूरा या परफेक्ट है
    rewrite तो बस code translation थी ताकि उसे starting point बनाया जा सके
    Bun team ने कभी यह बड़ा दावा नहीं किया कि code अब memory-safe है; उन्होंने साफ़ कहा है कि यह एक शुरुआत है
    इसलिए यह उम्मीद करना कि यह तुरंत परफेक्ट हो और original Zig code की सारी memory problems भी हल कर दे, असल में Bun team की घोषणाओं से नहीं बल्कि लोगों की अपनी कल्पना की घोषणाओं से लड़ना है
    यह भी जानना दिलचस्प होगा कि क्या किसी ने map किया है कि ये memory issues original codebase में भी मौजूद थे या नहीं

• इस तरह की errors की उम्मीद थी
  जिन्हें stability चाहिए उनके लिए stable version Zig में ही छोड़ा गया है, और आख़िरकार ये bugs ठीक हो जाएँगे, ऐसा लगता है

  • इस तरह की errors को काफ़ी हद तक टाला जा सकता था
    Rust ecosystem में इन्हें पकड़ने के लिए जाने-पहचाने tools हैं, और भले ही वे unsafe blocks की गलतियों से पैदा होने वाली हर undefined behavior न पकड़ें, फिर भी उन्हें चलाना अच्छी practice माना जाता है

• मुझे सबसे ज़्यादा चिंता meta conversation की है
  शुरुआत में मैं उन maintainers के प्रति आलोचनात्मक था जिन्होंने इस GitHub issue को off-topic कहकर बंद कर दिया
  लेकिन GitHub UI अपने-आप ऐसी messages को bulk में fold कर रहा था जिनकी informational value लगभग शून्य थी, और वे messages शायद किसी forum या community Discord से भीड़ बनाकर आए थे
  इससे सबके लिए हारने वाली स्थिति बन जाती है
  जिसने ऐसी गंभीर समस्या देखी हो जो कई संबंधित communities के लिए चिंता का विषय हो सकती है, उसके पास उसे जितना संभव हो उतना व्यापक रूप से साझा करने का अच्छा कारण होता है
  यह हाल की changes पर एक substantive request है, और tone को मुद्दा बनाने से उसकी factuality खत्म नहीं हो जाती
  समस्या यह है कि अतिरिक्त attention सचमुच discussion को मार देती है
  maintainers की तरफ़ इससे उन लोगों को भी ढाल मिल सकती है जो ज़्यादा भावनात्मक या AI psychosis जैसी decision-making कर रहे हों
  आलोचना को रोककर नज़रअंदाज़ करने वाली siege mentality वाले projects बहुत जल्दी पटरी से उतर सकते हैं
  दूसरी तरफ़, जो projects maintainers को AI को लेकर anxiety और pathology से बचा नहीं पाते, वहाँ maintainer burnout लगभग तय है

• यह Bun rewrite मुझे Mythos marketing के लिए एक संभावित event जैसी लगती है

  • अभी तक न Bun team ने, न Anthropic में किसी ने, इसे इससे आगे बढ़ाकर market किया है कि यह बेहतर compiler guarantees वाली, ज़्यादा memory-safe language में बदलाव है
    अभी तक की ज़्यादातर चर्चा और hype AI-विरोधी लोगों की नकारात्मक प्रतिक्रिया से आई है
    मेरे हिसाब से Anthropic के हालिया कुछ फैसलों की वजह से Anthropic को लेकर बढ़ी नकारात्मक धारणा भी इसमें काफ़ी जुड़ी हुई है
  • यह बस corporate rug pull जैसा लगता है
    जैसे Anthropic की ज़रूरतें ही एकमात्र priority हों और बाकी किसी चीज़ की परवाह न हो
  • उन्होंने न जाने कितना पैसा unlimited tokens पर उड़ाकर यह rewrite चलवाई
    फिर “Claude Code ने Bun team को Zig के 10 लाख+ lines को Rust में rewrite करने में मदद की” जैसा बड़ा शोर मचाकर blog post लिखो, तो VC लोग ललचा जाएँगे
    basic checks में fail हो जाता है
    फिर Mythos को codebase के चिथड़े उड़ाने दो और पता नहीं कितना और पैसा खर्च करो
    फिर एक अलग blog post लिखो
    ठग और भोले लोग ताली बजाएँगे और “भ्रमित anti-AI भीड़” के खिलाफ़ बचाव करेंगे
    VC और उत्साहित होंगे
    इसी तरह पैसा बनता है
    और फिर बात वहाँ पहुँचती है कि अब software engineers को भी हटाना चाहिए

• मुझे समझ नहीं आता कि लोग क्यों मान लेते हैं कि unsafe language के codebase में, जिसमें दूसरी unsafe language bindings भी हों, सब कुछ शुरुआत से ही पूरी तरह सही implement दिखेगा