Electrobun 2.0 Rust में दोबारा लिखे जाने के कारण Bun से अलग होने वाला है

• Electrobun 2.0 में, yt-dlp के फैसले की तरह, Bun के Rust rewrite के कारण Bun पर निर्भरता कम करने की दिशा में बदलाव होगा, और runtime dependency संरचना भी बदलने वाली है
• अलग होने के इस फैसले में यह आकलन भी शामिल था कि Anthropic पर्याप्त human review, उचित rollout, और stabilization process से नहीं गुजर रहा है
• Rust को स्वयं सकारात्मक रूप से देखा गया है, और Electrobun 2.0 में इसे first-class support मिलेगा
• Electrobun 2.0 में Rust के अलावा Zig और Go को भी first-class support language के रूप में शामिल करने की योजना है
• संबंधित project को blackboardsh/electrobun repository में देखा जा सकता है, और इसकी मुख्य दिशा Bun पर निर्भरता कम करना है

[GN⁺]

Hacker News की राय

• यह पूरा मामला काफ़ी दिलचस्प है, और सिर्फ़ तमाशे से बढ़कर 2026 के software development का रुख़ बताने वाला संकेतक लगता है

  • वैसे सही शब्द bellwether है, जो उस बधिया किए गए मेढ़े (wether) से आया है जिसकी गर्दन में घंटी बाँधकर झुंड को आगे ले जाया जाता था
  • और भी मज़ेदार बात यह है कि लगातार दुरुपयोग और हैकिंग झेलने वाले npm को छोड़ने की बात कोई नहीं करता
    आखिर npm पूरे उद्योग में हैकिंग का स्रोत कितनी बार रह चुका है? सिर्फ़ बड़े मामलों की बात करें तो तीन बार, और npm को निशाना बनाने वाले बड़े supply-chain attack campaigns भी हुए हैं। लेकिन असली चिंता जैसे bun को लेकर है
    अब वास्तविकता को देखना चाहिए और npm की फिर से समीक्षा करके उसे बारीकी से परखना चाहिए। यह ख़तरनाक हद तक नियंत्रण से बाहर जा रहा है
  • समय के साथ पता चल जाएगा। मुझे लगता है यह वही 20 साल पुराना पैटर्न है जिसमें इंटरनेट पर लोग $latest_thing पर ग़ुस्सा होते हैं और फिर जल्दी ही किसी दूसरे गर्म मुद्दे पर चले जाते हैं
  • wind vane से ज़्यादा सही उपमा शायद coal mine की canary होगी
  • शुरू से ही सोच रहा हूँ कि “पीछे रह गईं और बहुत modern न होने वाली” कंपनियाँ Bun या Deno का कितना इस्तेमाल कर रही होंगी
    दूसरी तरफ़ यह थोड़ा कमज़ोर overreaction भी लगता है। आख़िर Linux चलाने से पहले हम kernel, drivers, BIOS, EFI code की हर एक लाइन audit तो नहीं करते, है न? अगर tests pass हो रहे हैं, performance regress नहीं कर रही, और यह सुरक्षित है, तो सिर्फ़ vibe coding से बनने पर लोग इतने नाराज़ क्यों हैं, समझ नहीं आता। शायद इसलिए कि यह गैर-जिम्मेदाराना है? दोनों पक्ष समझ में आते हैं

• Electrobun repository: https://github.com/blackboardsh/electrobun
  Electrobun का लक्ष्य TypeScript में लिखे ultra-fast, छोटे और cross-platform desktop apps को build, update और deploy करने के लिए एक end-to-end solution बनना है। अंदरूनी तौर पर यह main process चलाने के लिए bun का उपयोग करता है, webview TypeScript को bundle करता है, और इसमें Objc, C++ में लिखी native bindings तथा Zig में लिखे core हिस्से शामिल हैं

• LLM से बने बड़े codebases से तब तक बचना ही ठीक लगता है, जब तक यह साबित न हो जाए कि उन्हें LLM या उचित स्तर की मानवीय मेहनत से maintain किया जा सकता है

  • मुझे हैरानी है कि लोग तुरंत Bun को “AI garbage” कहकर निष्कर्ष निकाल रहे हैं
    Bun पर Rust rewrite से काफ़ी पहले, लगभग 6 महीनों तक काम लगभग पूरी तरह LLM के सहारे हुआ था। स्रोत: https://x.com/jarredsumner/status/2054525268296118363
    यानी यह तो पहले ही साबित हो चुका है कि LLM ऐसे codebase को maintain कर सकता है
  • यह जाँचने का एक तरीका है कि AI agent maintenance के तहत codebase सड़ रहा है या नहीं
    coding agent development tasks के दौरान code को कैसे पढ़ता है, इसे collect और analyze करें, और देखें कि मिलते-जुलते development tasks में code access की मात्रा और token consumption लगातार बढ़ रही है या नहीं। अगर agent के नज़रिए से code readability खराब नहीं हो रही, तो codebase की maintainability भी ठीक ही होगी

• पूरी तरह LLM से लिखे या rewrite किए गए software को लेकर मैं निश्चित रूप से सशंकित हूँ, लेकिन cyberattack vectors के मामले में मान लेना चाहिए कि Anthropic ने नए Mythos model के साथ पर्याप्त testing की होगी
  शायद उन्होंने इस बारे में कहीं और अधिक विस्तार से भी कुछ कहा हो

  • लेकिन दस लाख lines of code के लिए “पर्याप्त testing” का मतलब आखिर कैसे तय किया जाता है?
    जब तक code की एक line एक token न हो, आप दस लाख lines of code को 10 लाख token context window में डाल नहीं सकते। आख़िरकार आप बस इतना करते हैं कि उम्मीद करें कि खराब या ग़लत हिस्से सामने आ जाएँ, और उसके लिए काफ़ी समय व पैसा tokens पर खर्च करें
  • अगर LLM आसानी से जिस तरह की समस्याएँ पैदा करता है, वही वे security vulnerabilities हों जिन्हें LLM ख़ुद पहचानने में मुश्किल महसूस करता है, तो इसमें हैरानी नहीं होगी
  • तो फिर LLM-generated code की रक्षा कोई दूसरा LLM करेगा, और हमला भी दूसरे LLM करेंगे? नतीजा और उसका हम पर असर चाहे जो हो, जीत अंत में उन्हीं की होती है?
  • Jarred ने कहा कि इस मामले का Mythos या Anthropic से कोई लेना-देना नहीं है

• Electrobun के बारे में पहले कभी नहीं सुना, लेकिन यह Electron alternative के रूप में काफ़ी अच्छा लग रहा है। साइट पर CEF bundling को एक option बताया गया है—सोच रहा हूँ किसी ने इसे इस्तेमाल किया है क्या

• Electrobun का नाम आज पहली बार सुना। Electron की तुलना में यह कैसा है?

  • फ़र्क बस +bu का है

• शायद नाम बदल देना बेहतर होगा

• अब तो जिज्ञासा हो रही है कि कोई Zig-based Bun को fork करके कुछ और बनाएगा या नहीं

• यह काफ़ी वाजिब बात है
  उदाहरण के लिए, हमारी तरह बहुत-सी जगहें numpy पर काफ़ी निर्भर हैं। numpy दशकों से मौजूद है और पर्याप्त रूप से battle-tested है। अगर कोई एक हफ़्ते में vibe coding से numpy का नया version rewrite करके जारी करे और कहे कि “सारे tests pass करते हैं”, तो क्या हम उसे अपनाएँगे? बिल्कुल नहीं। हमें न तो यह भरोसा होगा कि उसमें छिपे bugs नहीं हैं, न ही यह कि उसके नतीजों पर पूरी तरह भरोसा किया जा सकता है
  असली मुद्दा यह नहीं है कि rewrite AI ने की या नहीं, बल्कि यह है कि क्या वह समय के साथ battle-tested हुई है। अगर किसी human team ने भी एक हफ़्ते में rewrite किया होता, तब भी हम उस पर भरोसा नहीं करते या उसे इस्तेमाल नहीं करते

  • “एक हफ़्ते में बना दिया” वाली बात HN पर बार-बार दोहराई जा रही है, लेकिन वह PR release नहीं था। Rust rewrite एक महीने से ज़्यादा समय से चल रही है और अभी ship नहीं हुई है
  • यह कुछ ऐसा हुआ जैसे कहना, “इस अलमारी को हाथ से बनाने में मुझे एक महीना लगा, तो अगर किसी ने मशीन से इसे एक दिन में बना दिया, क्या मैं उस पर भरोसा करूँगा?”

• नाम काफ़ी बदनाम Electron के बहुत क़रीब है—क्या यह वैसा ही कुछ है?