Bun 1.4 Rust rewrite is not looking good?

मूल लेख ↗ Hacker News चर्चा ↗

Bun की Rust-आधारित 1.4 rewrite और AI-assisted coding पर इसकी भारी निर्भरता को लेकर चिंताएँ बढ़ रही हैं, क्योंकि बार-बार चूके हुए release targets और रुकी हुई stable-release cadence ने कुछ early adopters का भरोसा डगमगा दिया है। समर्थकों का कहना है कि canary builds पहले से ही Anthropic और Prisma जैसी कंपनियों में production में हैं, बड़े-scale rewrites स्वाभाविक रूप से कठिन होते हैं, और यह LLM-driven development के लिए एक promising proof-of-concept है। बहस केवल Bun की stability और Node व Deno जैसे alternatives के बीच तुलना तक सीमित नहीं है, बल्कि इस पर भी है कि क्या AI-generated code भरोसेमंद रूप से critical infrastructure की नींव बन सकता है।

Bun 1.4 और Rust rewrite पर समग्र भावना

  • कुछ उपयोगकर्ताओं का कहना है कि Bun व्यवहार में “amazing” रहा है (तेज़, एकीकृत tooling, बेहतर DX) और वे आशावादी हैं कि Rust rewrite से safety और leaks में सुधार होगा।
  • अन्य लोग लगातार अस्थिरता की रिपोर्ट करते हैं: random build failures, memory leaks, और regressions जिनसे resource savings भी खत्म हो गए, और अब उन्हें “serious” projects के लिए Bun अपनाने पर पछतावा है।
  • कुछ लोग 1.4 canary (Rust rewrite) को production में उपयोग कर रहे हैं और बता रहे हैं कि यह लगभग ठीक काम कर रहा है, बस कुछ छोटी समस्याएँ हैं (जैसे REPL rendering glitches)।

Release cadence, “not shipping,” और communication

  • एक केंद्रीय चिंता: Rust rewrite के दौरान Bun की पहले की frequent releases लगभग 3 महीनों तक रुक गईं, जबकि पहले 2–3 सप्ताह की cadence थी।
  • आलोचकों का तर्क है कि बार-बार दिए गए, आशावादी “it ships tomorrow” जैसे public statements, और फिर delays, भरोसे को कमजोर करते हैं और rewrite में परेशानी का संकेत देते हैं।
  • समर्थक कहते हैं कि बड़े rewrite के दौरान releases का रुकना स्वाभाविक है; बड़े cut से पहले सावधानी और polishing उचित है।
  • निराशा यह है कि canary builds का heavy real-world use हो रहा है (जैसे बड़े users द्वारा), लेकिन लंबे समय तक कोई official stable release नहीं आई, जिससे conservative environments में adoption रुक गया।
  • thread के अंत के करीब, लोग नोट करते हैं कि 1.4 वास्तव में रिलीज़ हो चुका है।

Code quality, dead code, और metrics

  • हमले की एक लाइन large volumes of open PRs और dead code के दावों को rewrite के “not looking good” होने के सबूत के रूप में पेश करती है।
  • अन्य लोग इसे कमजोर या भ्रामक तर्क कहते हैं:
    • 5k+ open PRs को code quality में गिरावट का प्रमाण नहीं माना जाना चाहिए।
    • “11k lines of dead code” वाले उदाहरण को ठीक किया जाता है: वह removal पुराने Zig codebase पर लागू था, Rust port पर नहीं।
    • कुछ लोग तर्क देते हैं कि million-line project में <1% dead code स्वीकार्य हो सकता है; दूसरे कहते हैं dead code zero होना चाहिए और linters मौजूद हैं।

Node, Deno, और alternatives

  • कुछ लोग पूछते हैं कि Node के alternative की ज़रूरत ही क्यों है; वे Node की बढ़ती standard library, test runner, TS support, और env-file support का हवाला देते हैं।
  • Bun समर्थक integrated tooling (package manager, test runner, bundler, image और SQL support) और performance को Node के toolchain sprawl पर बड़े फायदे के रूप में रेखांकित करते हैं।
  • अन्य लोग अधिक stability और standards alignment के लिए बस Node पर pnpm/yarn, या Deno, इस्तेमाल करने का सुझाव देते हैं।

AI-generated code और व्यापक AI बहस

  • Rewrite को LLM-assisted development के लिए एक key test case माना जा रहा है:
    • समर्थकों का कहना है कि language-to-language rewrites LLMs के लिए स्वाभाविक रूप से उपयुक्त हैं, खासकर जब उन्हें tests से validate किया जाए।
    • संशयवादी long-term maintainability, संभावित “spaghetti” code, और human oversight तथा token spend को जोड़ने पर कुल आर्थिक लागत पर सवाल उठाते हैं।
  • कुछ लोग स्पष्ट रूप से चाहते हैं कि rewrite विफल हो ताकि इस hype को तोड़ा जा सके कि “AI will replace developers”; अन्य लोग कहते हैं कि लोग LLM success को साबित या खंडित करने के लिए जरूरत से ज़्यादा झुक रहे हैं।