Claude Code, Rust में दोबारा लिखे गए Bun का उपयोग करता है

 (simonwillison.net)
2 पॉइंट द्वारा GN⁺ 1 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code v2.1.181 से Rust में पोर्ट किया गया Bun बिल्ट-इन है, जिससे Linux startup speed 10% तेज हुई है, लेकिन ज़्यादातर users को बदलाव लगभग महसूस नहीं होता
  • executable की strings की जांच करने पर Bun v1.4.0 और Rust source file paths दिखते हैं, जिसके लिए अभी official tag नहीं है
  • ~/.local/bin/claude में src/runtime/bake/dev_server/mod.rs आदि सहित 563 .rs filenames मिले
  • BUN_OPTIONS के जरिए TypeScript file को preload करके Bun.version print करने के तरीके से भी embedded version 1.4.0 होने की पुष्टि की जा सकती है
  • Rust version Bun canary के रूप में distribute किया गया था, और Claude Code के जरिए पहले ही लाखों devices पर production में चल रहा है

Claude Code में embedded Rust-based Bun

  • Rewriting Bun in Rust के मुताबिक, 17 जून को release हुए Claude Code v2.1.181 से Rust port का उपयोग किया जा रहा है
    • Linux startup speed 10% बेहतर हुई
    • इसके अलावा users को अंतर लगभग महसूस नहीं हुआ, और Jarred Sumner ने इसे “Boring is good” कहा
    • Claude Code के जरिए यह पहले ही लाखों devices पर production में चल रहा है
  • Claude executable की strings में embedded Bun version ढूंढा जा सकता है
strings ~/.local/bin/claude | grep -m1 'Bun v1'
  • macOS arm64 environment में Bun v1.4.0 (macOS arm64) output होता है
  • उस समय GitHub पर latest official release 12 मई का Bun v1.3.14 था, इसलिए Claude Code में अभी officially release न हुआ v1.4.0 preview शामिल माना जा सकता है
  • Rust version Bun canary के रूप में public हुआ है, और bun upgrade --canary से install किया जा सकता है

Rust source और version verification

  • executable से Rust source paths निकालने पर 563 filenames दिखते हैं
strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'
  • list में ये paths शामिल हैं
src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs
  • Ajan Raj द्वारा share की गई method BUN_OPTIONS से TypeScript file को preload करके Claude Code में embedded Bun.version को सीधे print करती है
cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version
  • इस command में भी 1.4.0 output होता है
  • 17 मई के commit में package.json version 1.4.0 में बदले जाने के बाद से वैसा ही रखा गया है, और अभी canary के अलावा किसी tagged release में शामिल नहीं है

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

1 टिप्पणियां

 
GN⁺ 1 일 전
Hacker News की राय

  • यह समझना मुश्किल है कि TUI को JavaScript से होकर टर्मिनल के लिए React पर क्यों चलना चाहिए। Anthropic ने TUI सुधारने के लिए runtime तक acquire कर लिया, यह बात engineering quality पर और संदेह पैदा करती है। अगर rewrite इतना आसान था, तो Claude Code को native language में ले जाना कहीं सस्ता पड़ता

    • यह पहले से अच्छी तरह काम कर रहा है और भारी revenue ला रहा business है, इसलिए “यह तकनीक क्यों?” तकनीकी से ज़्यादा business choice के करीब है। शुरुआत में चुनी गई तकनीक अपना काम कर रही है, इसलिए architecture perfect न भी हो तो उसे बदलने की वजह कम है
      rewrite Bun के लिए भी आसान नहीं है, और API contracts व tests साफ़ हों तो non-UI development tool को rewrite के बाद भरोसेमंद मानना, अस्पष्ट functionality और कम tests वाले UI tool की तुलना में आसान होता है
    • Claude, OpenCode और Ghostty को साथ इस्तेमाल करने पर interactive terminal programs CPU और battery बुरी तरह खाते हैं, और रातभर sleep state में रहे laptop तक गर्म हो जाते हैं। curses/ncurses, Emacs, Vim, MS-DOS तक 40 साल से ज़्यादा की मिसालें मौजूद हैं, फिर भी web technologies को जबरन क्यों घुसाया गया, यह जानना चाहता हूं
    • मैंने पढ़ा था कि एक मशहूर Haskell company ने LLM के साथ iterative development की speed की वजह से Python पर switch किया। React training data बहुत ज़्यादा है और TypeScript compile time भी Rust आदि की तुलना में छोटा है
      User-facing code और तेजी से बदलती UX layer शायद fast iterative development वाली dynamic systems में जाएंगी, और infrastructure layer Rust जैसे safe systems environment में जाएगी। Java/C# बीच का रास्ता हैं, लेकिन आगे चलकर UX के लिए TypeScript/Python काफ़ी होंगे और systems work के लिए Rust ज़्यादा उपयुक्त होगा, इसलिए उनकी जगह घटती दिखती है
      https://avi.press/posts/2026-07-10-after-7-years-in-producti...
    • अगर मानें कि Anthropic AI से Claude Code लिखता है, तो JavaScript भी बुरा चुनाव नहीं है। Training data भरपूर है, और दूसरे high-performance languages में AI को confuse कर सकने वाली multi-threading और memory management समस्याओं से भी बचा जा सकता है, इसलिए AI से तेजी से software बनाने के लिए यह अच्छा है
    • OpenAI ने लगभग 1 साल पहले Codex को Rust में rewrite करने का फैसला किया था। अगर rewrite सच में इतना आसान है, तो यह भी पूछना चाहिए कि Bun की ज़रूरत क्यों है और सारे JavaScript code को Rust में क्यों नहीं ले जाते
      https://github.com/openai/codex/discussions/1174

  • Jarred की मूल पोस्ट देखें तो switch की वजह साफ़ लगती है: Zig में जो हिस्से manual थे, Rust में वे automated हो जाते हैं। इंसान और agent दोनों non-deterministic हैं, इसलिए Zig में memory lifetime और explicit deallocation को manually track करने पर missed bugs लंबी कतार में जमा होते जाते हैं, लेकिन Rust इस error class को हटा देता है और engineering management के लिहाज़ से अच्छा trade-off बनता है
    खासकर compiler errors coding agents के लिए ज़रूरी deterministic safety net हैं, और Claude को accuracy test करने का तरीका और “इसे compile कराओ” लक्ष्य देने पर यह अच्छी तरह काम करता है। Deterministic tests से probabilistic output को ठोस guarantee में बदलने का generalized approach https://michael.roth.rocks/blog/verification-surface/ में लिखा है

    • Zig और C तब suitable नहीं हैं जब अलग-अलग lifetimes वाली बहुत-सी छोटी allocations बनानी हों। Robust तरीके से लिखना हो तो arena में allocations बांधना या fixed buffer रखना जैसी चीज़ों से lifetimes खुद manage करनी पड़ती हैं
      ऐसा करने पर Zig भी Rust जितना robust हो सकता है, लेकिन अगर आप managed language जैसा allocation pattern चाहते हैं जिसे LLM पसंद करते हैं, तो Zig फिट नहीं बैठता
    • जो अपने-आप handle करती हैं वे garbage-collected languages हैं। Rust में भी memory lifetime के बारे में सोचना और track करना पड़ता है, लेकिन borrow checker गलत handling रोकता है और तुरंत correction feedback देता है, इसलिए LLM के लिए इस्तेमाल करना अच्छा है। Default immutable reference parameters भी बड़ी performance problems रोकते हैं
    • फिलहाल Bun में unsafe Rust बहुत ज़्यादा है, फिर भी क्या कहा जा सकता है कि वह error class automatically हटा देता है? इस पर संदेह है: https://news.ycombinator.com/item?id=48967630
    • मेरे अनुभव में LLM memory bugs काफ़ी आसानी से पकड़ लेते हैं। यह मामला Anthropic का सफल marketing event भर लगता है
    • मेरी याद में यह Rust rewrite पूरी तरह unsafe था, इसलिए संभव है कि वह समस्या automatically eliminate न कर पाए

  • Jarred या Simon Willison के assessment से अलग, मैं इस घटना को काफ़ी negative मानता हूं। Anthropic द्वारा Bun acquisition या AI rewrite से भी बड़ी समस्या वह immature process है जिसमें “यह सिर्फ़ मेरी branch है और लोग overreact कर रहे हैं” वाले रवैये से शुरुआत कर 10 लाख से ज़्यादा lines का PR एक महीने से भी कम समय में merge कर दिया गया
    Communication बेहद खराब रहा, trust को नुकसान हुआ और विभाजन बढ़ा; समझ नहीं आता कि TypeScript team ने 7.0 में जो approach लिया था, उसे follow करना इतना मुश्किल क्यों था

    • आखिरकार Claude Code users में से ज़्यादातर ने या तो notice नहीं किया या परवाह नहीं की, और मुद्दा उठाने वाले बहुत कम हैं, इसलिए practical तौर पर शायद यह important न हो
    • TS7 भी architecture को गंभीरता से review करने के बजाय दूसरी language में line-by-line port करने का representative case है

  • Claude में शामिल Bun v1.4.0 अभी public नहीं हुआ preview version लगता है। अगर ऐसा है, तो लगता है FOSS project Bun चुपचाप किसी और चीज़ में बदल गया है; अच्छा हुआ कि मैंने investigation को सिर्फ़ TODO में रखा और adopt नहीं किया
    Bun का governance document नहीं मिल रहा; अब क्या यह effectively ऐसा structure है जहां Anthropic ही काम और merge होना है या नहीं, दोनों decide करता है?

    • यह निष्कर्ष समझना मुश्किल है कि Rust में बदलने से project मर जाएगा
    • PR public है, कोई भी build करके इस्तेमाल कर सकता है; बस Anthropic team ने पहले इस्तेमाल करने का फैसला किया है
    • मेरी समझ में structure basically इस पर निर्भर है कि Jarred उस हफ्ते accept करने को तैयार है या नहीं। Claude Code changelog में लगभग एक महीने पहले से Bun 1.4.0 version change लिखा था, लेकिन वह AI-written log था, इसलिए ज़्यादातर लोगों ने न पढ़ा हो तो भी हैरानी नहीं
    • मैंने भी Bun adopt करने की जांच की थी, लेकिन instability की वजह से इस्तेमाल न करने का फैसला किया; इस घटना को देखकर लगता है कि वह सही judgement था

  • समझ नहीं आता कि Bun को लेकर इतना घुमा-फिराकर जटिल तरीके से क्यों निपटा गया। अगर agent Zig को Rust में ले जा सकता है, तो Claude Code को भी JavaScript से सीधे Rust में rewrite करके runtime dependency हटाई जा सकती थी और performance बढ़ाई जा सकती थी

    • अगर यह मान लें कि Bun का Rust rewrite, Anthropic की product strategy से असल में लगभग कोई लेना-देना नहीं रखता, तो भ्रमित होने की वजह नहीं बचती
    • सिर्फ Claude Code को देखें तो सीधे Rust में rewrite करना बेहतर होता, लेकिन तब Bun/oven.sh acquisition value बहुत घट जाती
      Bun के Claude Code के अलावा बाहरी और Anthropic के internal users भी होंगे, और इससे JavaScript runtime व tools ecosystem मिलता है जिसे coding models पसंद कर सकते हैं। आगे चलकर Anthropic ऐसे apps को run और manage करने में specialized cloud तक दे सकता है, और सिर्फ developer community हासिल कर लेना भी Claude Code को Rust में ले जाने से कहीं बड़ा प्रभाव दे सकता है
    • यह भी सवाल है कि Claude Code सच में performance bottleneck है या नहीं। JavaScript runtime का tools ecosystem बड़ा है और plugin development आसान है, इसलिए यह काफी उपयुक्त है

  • अटकल और भावनाएं हटाकर देखें तो असल execution quality जानने की उत्सुकता है। सिर्फ startup speed नहीं, RAM और CPU usage, infinite loops या deadlocks कैसे हैं यह देखना होगा; अगर यह पहले जैसा या बेहतर है तो यह काफी प्रभावशाली है
    developer के तौर पर AI के jobs ले जाने की संभावना पसंद नहीं है, लेकिन अगर कोई भी simple requirements से अपनी मनचाही software बना सके, तो दुनिया बेहतर हो सकती है। Microsoft का data collection पसंद नहीं तो operating system, Google की eavesdropping पसंद नहीं तो mobile phone AI से बनवाने जैसी technical self-sufficiency संभव हो सकती है, और उसके सामने व्यक्ति की job security मामूली हो जाती है
    इसलिए technology को open source बनाए रखना और भी जरूरी है; वरना पुराने monopoly structure दोहरेंगे और jobs भी चली जाएंगी

    • software development में सबसे कठिन हिस्सा clear requirements पाना है। perfect AGI भी हो, तब भी लोग अपनी चाहत साफ-साफ व्यक्त नहीं कर पाते, इसलिए ऐसी दुनिया नहीं आएगी जहां हर कोई ठीक वही software बनाए जो वह चाहता है
    • अच्छे tools से भी बेहतरीन नतीजे तभी आते हैं जब उन्हें skilled craftsperson इस्तेमाल करे। अच्छे developers सही सवाल पूछते हैं, safeguards बनाते हैं, और जहां जरूरत हो output को खुद adjust कर सकते हैं
    • फिलहाल subsidized paywall के पीछे closed models को technology democratization कहना बहुत भोला है। लगता है Bun के Rust port को मुख्यतः marketing के लिए इस्तेमाल करने की strategy अच्छी तरह काम कर गई

  • हाल में Kitty tab के अंदर Claude Code इस्तेमाल करते हुए segmentation fault हुआ, और उसके बाद पूरा tab input पर respond करना बंद कर गया। report link दिखता है, लेकिन click नहीं किया जा सकता और encoded है, इसलिए यह भी नहीं देख सकता कि कौन-सी जानकारी भेजी जा रही है

    • Bun ideas और features के मामले में दूसरे JavaScript runtimes से बहुत आगे है, लेकिन stability बेहद खराब है और Node की तुलना में segmentation faults करीब 20 गुना ज्यादा थे। यह आंकड़ा New Relic telemetry data पर आधारित है
    • अगर shell में Segmentation fault print नहीं हुआ, तो यह segmentation fault नहीं बल्कि hang होने की संभावना ज्यादा है। अगर सच में fault हुआ हो, तो shell में लौटने के बाद screen पर दिखाई न दे तब भी reset type करके tab recover किया जा सकता है
    • work MacBook पर Ghostty और Claude Code इस्तेमाल करता हूं, लेकिन यह issue अभी तक नहीं हुआ। पहले runaway memory leak से system hang हो जाता था और reboot करना पड़ता था, पर पिछले कुछ हफ्तों में यह गायब हो गया है; पक्के तौर पर कहना जल्दी होगा, लेकिन संभव है कि Rust port ने memory leaks घटाए हों
    • Ghostty में Claude का interactive question interface इस्तेमाल करते समय भी इसी तरह hang होता है, और scroll के अलावा selection या cancel समेत कोई input नहीं लेता। हालांकि मुझे नहीं लगता कि यह Bun से संबंधित है
    • Zig version में भी segmentation faults थे, और अगर उसे unsafe Rust में line-by-line ले जाया गया है, तो कारण बनने वाला code भी वैसे ही बचा रहेगा। idiomatic और memory-safe Rust में refactor करने से पहले यह हल नहीं होगा

  • ये लोग समस्या को अच्छी तरह describe करने वाले, unlimited token budget रखने वाले, बहुत सफल लेकिन खराब engineers जैसे लगते हैं। अगर token cost खुद चुकानी पड़ती, तो software efficiency बढ़ाने की financial motivation बनती
    AI datacenters की छिपी reality यह है कि GPU cluster efficiency सिर्फ 40–60% होने पर भी funding से और hardware खरीदकर कमी पूरी कर दी जाती है। Chinese competitors से डरने की वजह भी यह हो सकती है कि उनके पास इस तरह waste करने की गुंजाइश नहीं है

  • यह काम transpile है और quality भी अच्छी नहीं है। generated code idiomatic Rust से बहुत दूर है, इतना कि उसे बदसूरत कहा जा सकता है

    • फिर भी लगता है कि यह ठीक से काम कर रहा है। इस बार मूल रूप से line-by-line mechanically move किया गया initial stage है, और अगले stage में idiomatic Rust में polish करने की योजना है, इसलिए इस rewrite के खिलाफ लगातार bet करना अच्छा नहीं लगता
    • stability, efficiency और cost को देखें तो original structure को जितना हो सके preserve करने वाला source-to-source translator इस्तेमाल करना या लिखना कहीं ज्यादा logical था
      आम तौर पर rewrite में मौजूदा codebase से मिली सीखों को शामिल किया जाता है, लेकिन agent से file-by-file port कराने पर वह फायदा नहीं मिलता। किसी भी तरह non-idiomatic translation होगी, लेकिन LLM इस्तेमाल करने पर nondeterminism और भारी cost भी जुड़ जाती है
    • Rust code को बदसूरत कहने के concrete examples चाहिए
    • यह जानना चाहता हूं कि सीधे LLVM IR में transpile क्यों नहीं किया गया
    • अगर project memory safety goal हासिल कर ले, तो code idiomatic है या नहीं, यह जरूरी है भी या नहीं—इस पर सवाल है

  • हाल में Claude Code पहले से कहीं ज्यादा unstable है, और TUI rendering errors की वजह से conversation history अक्सर टूट जाती है

    • फरवरी से अनिच्छा से Claude इस्तेमाल कर रहा हूं और शुरुआत से ही rendering defects, keyboard input errors आदि के साथ यह अब तक इस्तेमाल किए गए TUIs में सबसे खराब था। फिर भी पिछले एक हफ्ते में यह और खराब हो गया है; typed characters में से कुछ दिखाई नहीं देते और terminal session तक बिगाड़ने लगा है
      इसे background में भेजकर reset चलाने और फिर foreground में वापस लाने पर ठीक हो जाता है। Claude से diagnosis मांगी तो उसने कहा कि उसमें ऐसे bugs नहीं हैं और किसी दूसरे program की गलती है, जबकि सिर्फ tmux और Claude चल रहे थे। अगर हालिया Rust version लगाया गया है, तो quality degradation का timing लगभग match करता है
    • Windows पर window resize करते ही output पूरी तरह टूट जाता है, और अभी दिया गया जवाब फिर से मांगना पड़ता है। यह नई problem नहीं है, लेकिन हाल में और खराब लगती है
    • मैं AI के खिलाफ नहीं हूं, लेकिन Anthropic बहुत आगे जाकर AI से बना low-quality code ship कर रहा है। असली engineers को लगातार involve रहकर tools को guide करना चाहिए, पर Anthropic मानो code का 100% AI पर छोड़ना चाहता है