Buz – नवीनतम Zig और 1 सेकंड से कम incremental builds को सपोर्ट करने वाला Bun fork

• Buz, Bun के Rust rewrite से ठीक पहले वाले commit से शुरू हुआ एक शुरुआती चरण का fork है, जिसे नवीनतम Zig आधारित compatible alternative बनाने के लक्ष्य से विकसित किया जा रहा है
• JavaScriptCore के vendored source तक पूरे build graph को build.zig में ले जाकर और Zig में छोटे patches लागू करके 1 सेकंड से कम incremental builds लागू किए गए हैं
• Rust version Bun के नए features और bug fixes के tests लाए गए हैं, लेकिन कई tests fail हो रहे हैं, इसलिए upstream features और JavaScriptCore changes को लगातार follow करना होगा
• इस्तेमाल न हो रहे code की 11,000 से अधिक lines हटाई गईं और कुछ implementations को Zig standard library केंद्रित तरीके से modernize करने की प्रक्रिया में कई bugs भी fix किए गए
• अभी production में इस्तेमाल योग्य नहीं है, और LLM व human supervision दोनों का उपयोग करके technical debt घटाने के बाद LLM के बिना भी maintain करने में आसान codebase बनाना इसका long-term goal है

---

Project goals और development status

• Buz, Bun के Rust में rewrite होने से पहले के आखिरी commit पर आधारित एक work-in-progress fork है
• इसका focus Bun-compatible alternative होने के साथ-साथ पहले से अधिक व्यवस्थित codebase बनाने पर है
• Development बहुत शुरुआती चरण में है, इसलिए production use के लिए तैयार नहीं है
• Ziggit पर पहले से समान Zig-based Bun project सार्वजनिक होने की स्थिति में development work की duplication से बचने के लिए Buz को सार्वजनिक किया गया
  • Public release के समय उस project की अभी समीक्षा नहीं की गई थी

नवीनतम Zig porting और incremental builds

• Bun को current upstream Zig पर port किया गया है, और incremental rebuilds के लिए Zig में छोटे patches लागू किए गए हैं
• JavaScriptCore के vendored source सहित पूरे build graph को build.zig में integrate किया गया है
• इस setup से incremental build time 1 सेकंड से कम हो गया, जिससे development iteration cycle तेज हुई
• Project में incremental build patch लागू Zig master submodule शामिल है
• उस समय upstream Zig commit 2b1c663 पर भी build सही ढंग से हो सकता था

Compatibility tests और upstream tracking

• Rust version Bun में जोड़े गए tests लाए गए हैं, और नए features व bug fixes को verify करने वाले कई tests भी शामिल हैं
• अभी पास न होने वाले tests बहुत हैं, इसलिए Bun upstream को लगातार catch up करना होगा
• Feature compatibility बनाए रखते हुए code cleanup और technical debt घटाने का काम भी साथ-साथ किया जा रहा है
• JavaScriptCore changes को भी लगातार track करना होगा

Codebase cleanup और modernization

• Bun में बिल्कुल इस्तेमाल न हो रहे code की 11,000 से अधिक lines हटाई गईं
• कुछ code को rewrite और modernize करते हुए Zig standard library का उपयोग बढ़ाया गया
• Cleanup और modernization की प्रक्रिया में कई bugs भी साथ में fix किए गए
• मौजूदा Bun codebase लगभग 6 लाख lines का है, और व्यवस्थित स्थिति तक पहुंचने के लिए कई subsystems को फिर से लिखना पड़ेगा, ऐसा माना जा रहा है

LLM usage और contribution policy

• जटिल मौजूदा code को साफ करने के लिए LLM का व्यापक रूप से उपयोग किया जाएगा, लेकिन human supervision और बेहतर development practices भी साथ में लागू करने की योजना है
• जब तक codebase को पर्याप्त रूप से व्यवस्थित नहीं माना जाता, तब तक इंसानों द्वारा सीधे लिखे गए contributions स्वीकार नहीं किए जाएंगे
• Technical debt कम करना और idiomatic Zig code लिखना प्राथमिकता है, और कुछ हफ्तों या महीनों के भीतर Rust Bun 1.4.0 का compatible alternative बनने योग्य codebase का लक्ष्य है
• Sol या Fable इस्तेमाल कर सकने वाले developers से support मांगा गया है
• Long term में LLM की मदद के बिना भी maintain करने में आसान codebase बनाना और development process में Zig skills को भी बढ़ाना लक्ष्य है

[GN⁺]

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

• इस fork की सबसे दिलचस्प बात यह है कि इसने साबित कर दिया कि Bun भी पहले से ही तेज़ी से build हो सकता था
  अभी Zig incremental compilation aarch64 को support नहीं करता और binary patching भी केवल Linux linker में संभव है, लेकिन मुख्य platforms का support बस समय की बात लगता है
  • build speed बढ़ाने के लिए Zig compiler को fork करने को लेकर हुए शोर-शराबे को देखते हुए हैरानी है कि यह top comment नहीं है
    एक-व्यक्ति टीम ने 1-second build हासिल किया, यह दिखाता है कि slow builds लापरवाह development practices का नतीजा थे, और fork पर समय लगाना resources का पूरी तरह गलत allocation था
• LLM से बिगड़े code को फिर LLM से साफ़ करना—लगता है 2026 में technology अपने peak पर पहुँच गई है
  • अब तक इंसानों ने इंसानों द्वारा बिगाड़े code को ही साफ़ किया है, इसलिए इसमें logical contradiction नहीं है
  • LLM का output उतना ही अच्छा होता है जितनी उसे निर्देश देने वाले user की क्षमता
  • AI को लेकर skeptical हूँ, लेकिन इस्तेमाल करने को तैयार हूँ; अगर LLM सच में अपने output को खुद साफ़ कर सके तो यह game changer हो सकता है
  • मेरा भी यही ख्याल था, लेकिन ठीक आगे वे कहते हैं कि इंसान control संभालेंगे, technical debt घटाएँगे और idiomatic Zig code लिखकर कुछ हफ्तों या महीनों में Rust Bun 1.4.0 की जगह ले सकने वाला codebase बनाएँगे
    आखिरकार इसका मतलब शायद और ज़्यादा, या बेहतर, निर्देश देना है। code structure कुछ हद तक पसंद का मामला भी लगता है; कल ही एक दोस्त से अजीब बातचीत हुई जो ज़िद कर रहा था कि एक HTTP request handle करने के लिए चार backend processes चाहिए
  • शुरुआत से ही दिशा यही थी। इंसानों द्वारा पढ़े या समझे न जा सकने वाले, software जैसे दिखने वाले टूटे-फूटे LLM outputs code बन रहे हैं, इसलिए आखिरकार सारा code machines द्वारा पढ़ने और लिखने के लिए ही बनेगा
    इंसानी involvement का दौर शुरू से ही एक temporary phase था, ऐसा लगता है
• Bun से पूरी तरह dead code की 11,000 lines हटाईं और standard library का ज़्यादा उपयोग करने के लिए modernize करते हुए ढेरों bugs भी fix किए—यह हैरान करने वाला है
  सोचता हूँ कि क्या बड़े projects में यह आम बात है और बस मुझे पता नहीं था
  • कुल code 600k lines का है, इसलिए dead code लगभग 1.8% है। बड़े codebase में यह तय करने के लिए कि code वाकई use नहीं हो रहा, काफी व्यापक scope देखना पड़ता है, और समय के साथ दूर-दराज़ changes भी dead code बना देते हैं, इसलिए यह ज़्यादा common है
    यह साफ़ नहीं है कि यह if (false) { dead_code(); } जैसा obvious code था, या ऐसा code जिसे dynamic dispatch से call किया जा सकता है लेकिन logic के हिसाब से कभी call नहीं हो सकता। पहले मामले में 1.8% ज़्यादा है, लेकिन दूसरे में कम भी हो सकता है; कई projects में पुराने feature flags के पीछे ऐसा code जमा रहता है जो practically कभी run नहीं होगा
    simple utilities या generated code जैसी थोड़ी dead code छोड़ देना ठीक हो सकता है, लेकिन removal कभी-कभी chain में और deletion व simplification तक ले जाता है
  • पिछली company में 10k-line component को 2k lines तक घटाते हुए सभी major bugs fix किए थे
    strictly speaking वह dead code नहीं था, लेकिन एक छोटी गलत abstraction साफ़ करने पर अगली cleanup opportunities खुलती जाती हैं, और आखिर में ऐसा software बचता है जो केवल intended काम करता है। codebases समय के साथ फूलते हैं, इसलिए Bun के scale पर सिर्फ 11,000 lines मिलना ज़्यादा हैरान करता है
  • Zig compiler lazy compilation करता है, इसलिए compiled functions में कहीं से call न होने वाली dead functions को detect नहीं करता
  • Bun के development style को देखते हुए यह उम्मीद से कम है, और codebase में इससे कहीं ज़्यादा बचा हुआ लगता है
  • बड़े codebase में इतने dead code पर हैरान होना ही हैरान करने वाला है। यह normal-size PRs के करीब 10 के बराबर ही है
• आपकी programming career कितनी लंबी है कि dead code की 11,000 lines आपको इतनी unusual लगती हैं?
  • 10 साल से ज़्यादा experience है। मेरा मतलब ऐसे obvious dead code से था जिसे कहीं से भी call नहीं किया जाता, और सोच रहा था कि क्या इतने अधिक वाले और projects हैं
• हर agent-centric coding project में feature development और code management के बीच tick-tock oscillation दिखी
  tick phase में features तेज़ी से जोड़कर accurate लेकिन बेहद messy version बनता है, और tock phase में output को digest और clean up करके performance, maintainability और change fragility सुधारी जाती है
  एक दिन vibe coding से working app बनाने के बाद, उसे ऐसा project बनाने में अक्सर एक हफ्ता लग जाता है जिसमें card-house की तरह ढहे बिना features जोड़ते रह सकें। AI से पहले भी कुछ ऐसा था, लेकिन professional developers के पास system का mental model ज़्यादा मजबूत था और काम की speed भी धीमी थी, इसलिए switch इतना abrupt नहीं था
  • आखिरकार code को खुद देखकर verify करना पड़ता है कि logic जगह-जगह duplicate नहीं है और वह वास्तव में maintainable है
    coding models encapsulation तोड़ने वाले shortcuts लेने या duplicate नहीं होना चाहिए ऐसा code copy करने की ओर बहुत झुकते हैं
• इसे मैं conspicuous performance programming कहना चाहूँगा। मुझे performance पसंद है और build time भी 0 seconds के करीब होना चाहिए, लेकिन अब हम diminishing returns वाले zone में हैं और current bottleneck शायद build time नहीं है
  • Bun developers इससे सहमत नहीं होंगे, क्योंकि incremental compilation का फायदा न मिल पाने की स्थिति में उन्होंने खुद लंबी waiting times झेली हैं: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    बड़े projects में tests चलाने या semantic errors check करने के लिए हर बार कई मिनट इंतज़ार नहीं कर सकते, इसलिए build time साफ़ bottleneck है
  • ऐसे projects के लिए fast builds ज़रूरी हैं, और मैं इसे maintenance आसान बनाने की एक अहम step मानता हूँ
• अगर Bun को code quality की परवाह करने वाला व्यक्ति manage करे तो welcome है, लेकिन यह Herculean task है
  • Herculean से ज़्यादा यह लगातार दोहराया जाने वाला Sisyphean task लगता है
• इसके ठीक उलट, सिर्फ AI contributions लेने वाला Zig fork भी देखना चाहूँगा
  AI का ज़ोरदार supporter होने की वजह से नहीं, बल्कि concept art या experiment के तौर पर यह देखना मज़ेदार होगा कि दोनों projects अलग-अलग कैसे evolve करते हैं
• काफ़ी relevant Cruller भी rewrite से पहले वाले Bun codebase का उपयोग करता है, लेकिन production runtime हिस्से पर ही focus करता है
  Link: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  HN discussion: https://news.ycombinator.com/item?id=49017344
• समझ नहीं आता Bun इतना चर्चा में क्यों है। बस Node + npm + Vitest + Vite पर वापस क्यों नहीं जा सकते?
  • Bun के फायदे Node में लाने की कोशिश करने वाला Nub project है, और यह दिखा सकता है कि लोग Bun क्यों पसंद करते हैं और existing tools में क्या gap है
    https://nubjs.com
  • वही list इस चर्चा की वजह है। ढेरों tools जोड़ने के बजाय आप एक single runtime इस्तेमाल कर सकते हैं जो ज़रूरी सारे काम संभालता है
    purpose-specific tools को combine करने में भी कोई समस्या नहीं है, लेकिन default state में सभी समस्याएँ हल हो जाना बहुत convenient है। Bun bundler में runtime API भी है, जिससे assets serve करने वाली वही process external bundler से coordinate किए बिना या static files disk पर लिखे बिना memory से सीधे bundling कर सकती है
  • चार tools की list बनानी पड़ती है, यही दिखाता है कि existing situation कितनी खराब है
  • अब तो यह भी unclear है कि npm का इस्तेमाल जारी रखने की वजह क्या है