Bun (JS runtime) को Zig से Rust में vibe port किया जा रहा है

 (github.com/oven-sh)
3 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Bun के संस्थापक Jarred Sumner ने claude/phase-a-port ब्रांच में Zig → Rust पोर्टिंग गाइड (PORTING.md) कमिट किया, जिससे AI एजेंट्स का उपयोग करके बड़े पैमाने पर language conversion का प्रयोग सार्वजनिक हुआ
  • पोर्टिंग को Phase A (फ़ाइल-स्तर पर सिर्फ़ लॉजिक का शुरुआती अनुवाद, compile आवश्यक नहीं) और Phase B (crate-दर-crate compile pass) में बाँटा गया है, और LLM को लगभग 300 type/idiom mapping rules दिए जाते हैं
  • Sumner ने स्वयं Hacker News पर कहा कि "rewrite तय नहीं हुआ है, और इस कोड के पूरी तरह फेंक दिए जाने की संभावना बहुत अधिक है", इसलिए इस समय यह एक experimental exploration stage है
  • कम्युनिटी में Anthropic अधिग्रहण के बाद Zig की AI contribution ban policy के साथ टकराव, Bun द्वारा पहले से Zig fork चलाना, और Rust ecosystem के safety advantages जैसी बातों को पृष्ठभूमि के रूप में चर्चा में लाया गया
  • ज़्यादातर PR @robobun (AI bot) द्वारा अपने-आप बनाए जा रहे हैं और CodeRabbitAI व Claude उनकी review कर रहे हैं; यह AI-नेतृत्व वाले बड़े code migration की व्यावहारिक संभावनाओं और सीमाओं को दिखाने वाला उदाहरण है

पोर्टिंग गाइड (PORTING.md) की मुख्य संरचना

  • पोर्टिंग का लक्ष्य एक Zig फ़ाइल को उसी directory में .rs फ़ाइल में बदलना है; Phase A में लॉजिक की faithful reproduction लक्ष्य है और compile होना ज़रूरी नहीं
  • tokio, rayon, hyper, async-trait, std::fs, std::net जैसे external async/I/O crates का उपयोग निषिद्ध है — क्योंकि Bun अपना event loop और syscalls स्वयं नियंत्रित करता है
  • async fn निषिद्ध है; सारी asynchronous processing Zig की तरह callback + state machine तरीके से ही रखी जाती है
  • जिन हिस्सों पर भरोसा न हो उन्हें // TODO(port): से, और performance-संबंधित Zig idioms को // PERF(port): से चिह्नित किया जाता है ताकि उन्हें Phase B में संभाला जा सके

type/idiom mapping rules

  • []const u8 → &[u8] (कभी भी &str नहीं), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error> आदि सहित 50 से अधिक type mapping tables दिए गए हैं
  • defer x.deinit() → हटाकर impl Drop से प्रतिस्थापित, errdefer → scopeguard का उपयोग, comptime → const generic·const fn·macro_rules! में रूपांतरण
  • strings के लिए byte-based processing सिद्धांत अपनाया गया है: std::string::String या &str का उपयोग मना है, और &[u8]/Vec<u8> का उपयोग किया जाता है — क्योंकि Bun WTF-8 और arbitrary bytes को संभालता है
  • @intCast → T::try_from(x).unwrap() (हमेशा checked), @truncate → x as T (intentional wrapping), @bitCast → transmute आदि के रूप में Zig built-in functions के Rust equivalents व्यवस्थित किए गए हैं

crate map और ownership model

  • @import("bun").X जैसे Zig namespaces को bun_str, bun_sys, bun_jsc, bun_alloc आदि लगभग 30 Rust crates में 1:1 मैप किया गया है
  • AST/parser crates में bumpalo::Bump arena बरकरार रखा जाता है, जबकि अन्य crates में global mimalloc allocator के उपयोग से allocator parameters हटा दिए जाते हैं
  • bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T> जैसी pointer ownership mapping दी गई है

कम्युनिटी की प्रतिक्रिया (Lobsters·HN)

  • "क्या वे सच में Rust में switch करना चाहते हैं, या यह Anthropic LLM का showcase है?" जैसी शंकाएँ कई लोगों ने उठाईं
  • Zig की AI contribution ban policy और Anthropic के AI-केंद्रित development workflow के बीच टकराव इसकी पृष्ठभूमि हो सकता है, ऐसी अटकलें हैं; हालांकि इसे conspiracy-level speculation भी कहा गया
  • लगभग 300 rules को LLM कितनी faithfully follow कर पाएगा, इस पर skepticism है — वहीं "~16k tokens है, इसलिए sub-agents के लिए ठीक-ठाक है" जैसी सकारात्मक राय भी मौजूद है
  • "Phase A में पहले non-compiling code बनाना मौजूदा coding agent workflows के बिल्कुल उलट है" जैसी दिलचस्प टिप्पणी भी सामने आई
  • Bun के Zig fork को बनाए रखने का बोझ, Zig के बार-बार आने वाले breaking changes, और अभी beta-stage language पर core product निर्भर होने का risk भी switch के संभावित कारणों के रूप में बताए गए हैं

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs की रायें

  • संदर्भ के लिए, Jarred Sumner ने इस बारे में HN पर यह कहा: वह Bun पर काम करते हैं, यह उनकी अपनी branch है, और उनके मुताबिक यह thread काम न करने वाले code पर overreaction है
    अभी यह तय नहीं हुआ है कि वे वास्तव में rewrite करेंगे, और यह भी बहुत संभव है कि यह सारा code फेंक दिया जाए
    उनका कहना है कि वे देखना चाहते हैं कि काम करने वाला version कैसा दिखता है, performance कैसी है, Bun test suite पास कराना और उसे maintainable बनाना कितना कठिन है, और एक व्यवहार्य Rust version और Zig version को साथ-साथ compare करना चाहते हैं

    • यह कहावत याद आती है: “झूठ तब तक आधी दुनिया घूम आता है, जब तक सच अपने जूते पहन रहा होता है”
      pop-culture वाली tech व्याख्याएँ अक्सर तुरंत प्रतिक्रिया पर टिकी होती हैं

  • Bun के सामान्य pull request भी काफ़ी अव्यवस्थित हैं: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
    ज़्यादातर @robobun अपने-आप बनाता है, GitHub Actions से duplication चेक होती है (Claude आधारित), और @coderabbitai तथा @claude review करते हैं
    इस बीच CI टूटा हुआ है, और @robobun ने अपने ही कुछ PR इस वजह से बंद कर दिए कि वे उसके बनाए दूसरे PR के duplicate थे
    main में merge अभी भी इंसान करते हैं

    • इसकी उम्मीद नहीं थी
      मुझे याद है Bun की तारीफ़ Jarred के performance obsession की वजह से होती थी, लेकिन यह नहीं सोचा था कि वे codebase में LLM को इस तरह खुलकर दौड़ने देंगे

  • यह बेतुका है
    “idiom mapping” देखें तो unsafe भरा पड़ा है, और लगता है Rust-जैसा न होने वाला code भारी मात्रा में निकलेगा
    @fieldParentPtr("field", ptr) mapping खास तौर पर काफ़ी rough लगती है
    लेकिन लगता है कि “phase A” असल में line-by-line translation है, और उसके बाद prompts के ज़रिए उसे अधिक idiomatic और maintainable Rust में refactor करना चाहते हैं
    समस्या यह है कि language design implementation की दिशा को काफ़ी ज़ोर से धकेल सकती है, और अक्सर धकेलती भी है, इसलिए बाद में सुलझाना मुश्किल उलझाव पैदा हो सकता है
    अंत में शायद पुराने ढंग का manual rewrite ही बेहतर रास्ता होता

    • अगला चरण शायद LLM से ही इसे idiomatic और safe code में बदलवा दे
      खासकर Anthropic जैसी funding के साथ, AI की सुविधा यह है कि वह एक ही code को बार-बार refactor करते हुए भी नहीं थकता

  • migration अपने-आप में अलग बात है, लेकिन इन्होंने जो तरीका चुना है वह खास तौर पर दिलचस्प है
    linked docs/PORTING.md में लगभग 300 porting rules हैं, और कोई भी LLM इन्हें सब “याद” रखकर ठीक से follow कर पाए, ऐसा कम लगता है
    Anthropic Bun का मालिक है, इसलिए इस porting के लिए लगभग असीम token budget होगा, और शायद वे फ़ाइलों की संख्या * नियमों की संख्या जितने agents चलाकर यह “गारंटी” करने की कोशिश करें कि सबका पालन हुआ है
    उन्होंने porting को दो चरणों में बाँटा है: A में हर file को अलग-थलग रखकर rough port किया जाता है और उम्मीद रहती है कि compile टूटेगा, B में सबको जोड़कर compile होने लायक बनाया जाता है
    phase A में agent से कहा जाता है कि code का “compile होना ज़रूरी नहीं है”, और हर port की गई file को output quality के हिसाब से low/medium/high score देने को कहा जाता है
    low का मतलब logic ग़लत है, medium का मतलब logic सही है लेकिन compile नहीं होगा, high का मतलब logic भी सही है और शायद compile भी हो जाएगा
    मैं coding agents को जिस तरह समझता और इस्तेमाल करता हूँ, यह उससे बिल्कुल उल्टा है, इसलिए नतीजा देखने की उत्सुकता है
    मेरी समझ से अगर यह कह दिया जाए कि compile होना ज़रूरी नहीं है और कोई साफ़ “end goal” न दिया जाए, तो नतीजे बहुत unpredictable हो जाते हैं, और phase B में review के लिए अविश्वसनीय code का ढेर मिल सकता है
    मैंने जल्दी से grep किया तो ऐसे 1279 output-quality scores में लगभग 3% low, 80% medium, और 17% high थे

    • मई 2026 के हिसाब से 300 rules ठीक-ठाक लगते हैं
      PORTING.md लगभग 16k tokens का है और मुख्य काम पर केंद्रित है
      नए sub-agent के लिए यह बुरा नहीं, बल्कि शायद आदर्श भी हो सकता है

  • समझ नहीं आता कि वे सचमुच Rust में जाना चाहते हैं, या यह Anthropic LLM का test है

    • मेरे अंदर का conspiracy theorist कहता है कि इसकी वजह Zig का हालिया AI-assisted contributions पर ban और Mattew Lugg की Bun language fork पर आलोचना है
      अगर Anthropic, Zig के सबसे लोकप्रिय projects में से एक Bun को दूसरी language में ले जाए, तो यह काफ़ी खुला हुआ power move होगा
      बेशक मैं इस नाटकीय hypothesis पर पूरी तरह यक़ीन नहीं करता; हो सकता है कि बस Anthropic अपनी मोटी funding से product showcase करना चाहता हो

  • काफ़ी दिलचस्प लग रहा है
    एक बार में निपटाए जाने वाले rules के bundle इतने बड़े लगते हैं कि भारी code-review cycles के बिना उनकी verification संभव नहीं दिखती
    tokens भले बहुत हों, लेकिन ऐसे transformation के बाद code को practically verify करना बहुत मुश्किल हो जाएगा
    अगर tests को भी इसी प्रक्रिया से गुज़रना पड़े, तो सवाल उठता है कि आखिर ground truth के रूप में बचेगा क्या
    फिर भी experiment अपने-आप में प्रभावशाली है

  • जब देखते हैं कि Node.js killers कैसे चल रहे हैं, तो Deno ने permissions system या default TypeScript support जैसे मामूली सुधार दिए, लेकिन दुनिया नहीं बदल दी, और ये features अब Node.js में वापस आ रहे हैं
    मेरे अनुभव में developer experience कोई अर्थपूर्ण तरीके से बेहतर नहीं था, और pnpm जैसे शानदार tools की वजह से कभी-कभी उल्टा और खराब लगा
    यह तेज़ हो सकता है, लेकिन पिछले 5–6 साल में अपने उपयोग के दायरे में मुझे Node.js performance की कोई खास समस्या महसूस नहीं हुई
    JSR भी दुनिया नहीं बदल पाया, और community ने इसके बजाय npmx बना लिया जो अब बेहतर experience देता है
    हाँ, Deno की standard library, जैसे @std/collections, काफ़ी अच्छी है और मैं उसका उपयोग करता हूँ
    Bun का scope इतना बड़ा था कि शुरू से ही कई red flags थे, लेकिन मैं सावधानी से आशावादी था क्योंकि लगता था Jarred कई साल लगाकर भी सबसे अच्छा all-in-one JS runtime बनाना चाहते हैं
    लेकिन Anthropic द्वारा acquisition के बाद, Jarred अब काफ़ी ~~vibe coding~~ agent-style development करते दिख रहे हैं, और अब यह vibe porting वाली खबर भी है, तो चाहे यह experimental branch ही क्यों न हो, मेरा यह निष्कर्ष और पक्का हो गया है कि यह वह project नहीं है जिसे मैं इस्तेमाल करूँगा
    इसलिए Node.js अब भी राज कर रहा है
    गंभीरता से कहूँ तो built-in TypeScript features और SQLite कमाल के हैं
    मैं पूरी तरह anti-AI नहीं हूँ; बहुत खास तरह की समस्याओं के लिए छोटे Python scripts या web apps को vibe coding से बनाना मज़ेदार और उपयोगी हो सकता है
    लेकिन जिन complex projects में बहुत सारे moving parts और users हों, उनमें बड़े पैमाने का “agent-style development” चाहे थोड़े समय के लिए feature development तेज़ कर दे, अंततः project को अस्थिर और फूला हुआ बनाने वाला net loss ही लगता है
    VSCode, Cursor, mise, Perplexity web UI जैसे उदाहरण याद आते हैं
    क्या एक JS dropdown बनाना, जो scroll करते समय अटके नहीं, इतना मुश्किल है?
    मैं चाहता हूँ कि जिन बड़े tools, libraries, और projects पर मैं निर्भर हूँ, वे इसे समझें और ज़्यादा सख़्त anti-AI policies अपनाएँ

  • यह सचमुच ग़लत दिशा है
    मैंने एक भी Rust maintainer नहीं देखा जो मध्यम आकार, यानी कई लाख lines वाले Rust project को maintain करते हुए बड़े codebase में उसकी scalability से संतुष्ट हो

    • नमस्ते
      मेरे हिसाब से Rust बड़े codebase के लिए खास तौर पर शानदार है:
      https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
      https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
      हालाँकि इसे प्रभावी ढंग से संभालने के लिए कुछ हद तक यह जानना ज़रूरी है कि आप क्या कर रहे हैं:
      https://matklad.github.io/2021/09/05/Rust100k.html
      इस संदर्भ में Zig की Rust से तुलना कैसी है, यह मुझे ठीक से नहीं पता
      TigerBeetle का design approach काफ़ी विशेष है
    • पृष्ठभूमि के तौर पर, मैंने लगभग 6 Rust codebase maintain किए हैं जो 10k से 100k lines के बीच थे, लेकिन 100k से ऊपर कोई नहीं था
      और मैं ऐसे कुछ उदाहरण भी जानता हूँ जहाँ 20k lines के Rust program ने 300k lines के Go program की core functionality implement की
      इसलिए यह ठीक वही शर्तें नहीं हैं जो आपने कही थीं
      लेकिन 10k–100k lines की range में maintainer के रूप में मैं Rust से बहुत संतुष्ट हूँ
      यह आकार इतना छोटा होता है कि program पर्याप्त रूप से focused रहे, और इतना बड़ा भी कि एक मुख्य idea को पूरी तरह implement कर सके
      इस आकार पर language और tooling दोनों बड़े assets रहे हैं, कम-से-कम मेरे व्यक्तिगत अनुभव में
    • cargo-nextest में इस समय comments और blank lines हटाकर 84k lines का Rust code है, और एकल maintainer के रूप में मुझे नहीं लगता कि मैं अपनी निजी quality standards के मुताबिक इसे किसी दूसरी language में लिख पाता

  • शायद इसकी वजह यह हो सकती है: https://github.com/oven-sh/bun/issues/28001

    • काश कोई समझाता कि Rust इसे ठीक-ठीक कैसे पकड़ता
      यह temporal memory safety की समस्या नहीं है