मुझे Bun की चिंता है

 (wwj.dev)
4 पॉइंट द्वारा GN⁺ 7 시간 전 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Bun एक तेज़ JavaScript runtime है और TypeScript पर काम करना आसान बनाने वाला टूल भी, लेकिन Anthropic के दिसंबर 2025 अधिग्रहण के बाद यह चिंता बढ़ी है कि उस पर product policy और संचालन के तरीके का असर पड़ सकता है
  • अधिग्रहण घोषणा में कहा गया था कि Bun open source और MIT लाइसेंस के साथ बना रहेगा, वही टीम इसका विकास जारी रखेगी, और क्योंकि Claude Code को Bun executable के रूप में वितरित किया जाता है, इसलिए Anthropic के पास Bun को स्थिर बनाए रखने की सीधी प्रेरणा है
  • अप्रैल 2026 के बाद Claude Code को लेकर quality degradation, restrictive behavior, third-party harness restrictions, billing confusion और धीमे communication जैसी समस्याएँ उठीं, और Anthropic की engineering postmortem ने product layer की समस्याओं, जैसे default reasoning effort value कम होना और prompt changes, को इसका कारण माना
  • TechCrunch और Gigazine की रिपोर्ट के अनुसार Claude Code, OpenClaw जैसे third-party harness support के लिए अतिरिक्त शुल्क माँग सकता है, या git history में सिर्फ OpenClaw का ज़िक्र होने पर ही request rejection या extra billing behavior trigger हो सकता है, जिससे unexpected behavior सामने आया
  • चिंता Bun की अपनी quality या Bun टीम को लेकर नहीं है, बल्कि इस बात को लेकर है कि Anthropic की policies Bun में भी घुस सकती हैं; इसी वजह से कुछ projects package management के लिए pnpm पर जा रहे हैं और नए JavaScript·TypeScript projects के लिए भी pnpm की सिफारिश करने लगे हैं

Bun को लेकर चिंता क्यों बढ़ी

  • Bun एक तेज़ और practical JavaScript runtime है, जो छोटे scripts, apps, tests और tools में TypeScript के साथ काम करना आसान बनाता है
  • तेज़ install, तेज़ tests, बेहतर bundling और कम toolchain overhead की वजह से इसे Node.js alternative के रूप में सफल होते देखने की उम्मीद की जाती रही है
  • चिंता का केंद्र Bun की quality नहीं, बल्कि यह है कि Anthropic के भीतर जाने के बाद वह product policy और operational style के प्रभाव में आ सकता है

Anthropic अधिग्रहण और शुरुआती उम्मीदें

  • Anthropic ने दिसंबर 2025 में Bun का अधिग्रहण किया
  • अधिग्रहण घोषणा के अनुसार Bun open source और MIT लाइसेंस के साथ जारी रहेगा, वही टीम इसे बनाती रहेगी, और roadmap high-performance JavaScript tools तथा Node.js compatibility पर केंद्रित रहेगा
  • घोषणा में यह वाक्य शामिल था: “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”
  • उस समय यह मानना स्वाभाविक था कि क्योंकि Claude Code, Bun पर चलता है, इसलिए Anthropic के पास Bun को तेज़ और reliable बनाए रखने की सीधी प्रेरणा है
  • वह तर्क आज भी सही लगता है, लेकिन Anthropic के software products चलाने के तरीके में दरारें दिखने लगी हैं, जिससे चिंता पैदा हुई है

Claude Code को लेकर बदलती राय

  • मुख्य चिंता Anthropic के models की quality नहीं है
  • Claude Opus 4.6 माने जाने वाले model family को coding, writing, reasoning और general development work में अब भी अच्छा माना जाता है
  • समस्या models के आसपास की product layer है, और मुख्य बात यह है कि Claude Code की usability अब काफ़ी बिगड़ चुकी है
  • लगभग एक साल पहले Claude Code ऐसा टूल लगता था जो project पढ़ सकता था, focused changes कर सकता था, commands चला सकता था, अपनी गलतियाँ सुधार सकता था और आगे बढ़ता रह सकता था
  • उस समय Claude Code उन शुरुआती AI coding tools में से था जिसने यह भरोसा दिया कि developer workflow autocomplete-केंद्रित मॉडल से agent-केंद्रित मॉडल की ओर जा सकता है
  • दिसंबर 2025 तक भी Claude Code बिगड़ना शुरू हो चुका था, लेकिन तब भी उपयोगी था, और Bun का अधिग्रहण भी इस नज़रिए से समझ में आता था कि Anthropic coding tools का future बना रहा है

अप्रैल 2026 के बाद Claude Code की समस्याएँ

  • अप्रैल 2026 में developers ने Claude Code की quality, restrictive behavior, third-party harness restrictions, confusing billing और धीमे communication पर सवाल उठाने शुरू किए
  • Anthropic ने engineering postmortem प्रकाशित किया, जिसमें default reasoning effort value कम होना, stale session bugs और coding quality को नुकसान पहुँचाने वाले prompt changes जैसी product layer समस्याओं को कारण बताया गया
  • यह postmortem कम से कम सब कुछ सामान्य दिखाने की कोशिश से बेहतर था, और इसे Anthropic द्वारा अपनी ज़िम्मेदारी स्वीकार करने के दुर्लभ उदाहरण के रूप में देखा गया
  • TechCrunch की रिपोर्ट के अनुसार Anthropic ने Claude Code subscribers से कहा कि OpenClaw और दूसरे third-party harness support के लिए अतिरिक्त भुगतान करना होगा
  • Gigazine की रिपोर्ट के अनुसार अगर git history में सिर्फ OpenClaw मौजूद हो, तब भी Claude Code request reject कर सकता है या extra billing trigger कर सकता है
  • रिपोर्ट में Theo के हवाले से कहा गया कि JSON blob के भीतर recent commit में सिर्फ OpenClaw का ज़िक्र होने से भी खाली repository में claude -p "hi" सीधे चलाने पर यह behavior trigger हो सकता था
  • इससे जुड़ा दृश्य वीडियो क्लिप में भी देखा जा सकता है
  • ऐसा behavior यह आभास देता है कि product changes ऐसे बाहर भेजे जा रहे हैं मानो उन्हें code-level usage experience के साथ अंदरूनी तौर पर पर्याप्त रूप से इस्तेमाल ही न किया गया हो
  • बाहर से देखने पर Claude Code अधिक restrictions, अजीब billing और commit text के अनुसार बदलने वाले unexpected behavior की दिशा में जाता दिख रहा है
  • इस प्रवृत्ति को enshittification कहा जा रहा है

Bun तक पहुँचती चिंता

  • Bun, Claude Code के भीतर गहराई से शामिल है, और क्योंकि Claude Code बिगड़ता हुआ दिख रहा है, इसलिए चिंता है कि Bun भी उसी दिशा में जा सकता है
  • इसका मतलब यह नहीं कि Bun खराब है या Bun टीम ने रुचि खो दी है
  • असली समस्या यह है कि Bun और Bun टीम जितना ज़्यादा Anthropic में integrated होंगे, उतना ही Anthropic की policies भी साथ आएँगी
  • अगर वही policies, जिन्होंने Claude Code को नुकसान पहुँचाया लगता है, Bun को भी प्रभावित करती हैं, तो Bun में भी ऐसे मुद्दे दिख सकते हैं जहाँ लगे कि टीम अपने ही product का वास्तविक इस्तेमाल नहीं करती
  • सिर्फ यह संभावना ही कुछ projects में Bun का इस्तेमाल जारी रखने को लेकर भरोसा कम करने के लिए काफ़ी है

फिलहाल pnpm की ओर जाना

  • Bun, pnpm की तुलना में एक ही टूल में ज़्यादा features देता है
  • Bun अलग build step के बिना TypeScript support देता है, Vite की जगह bundler देता है, और vitest की जगह testing features देता है
  • इन features को एक ही toolchain में बाँधकर देना वास्तव में एक बड़ा फ़ायदा है
  • pnpm, न तो Node.js replacement है और न ही Bun replacement; यह सिर्फ एक package manager है
  • लेकिन अगर रोज़मर्रा के काम में Bun का सबसे ज़्यादा इस्तेमाल package management के लिए ही हो रहा है, तो तेज़ install, अच्छा monorepo support और उचित disk usage, Bun और pnpm दोनों ही देते हैं
  • इसलिए Bun इस्तेमाल करने वाले कुछ projects ने Bun से हटकर pnpm पर जाने का फ़ैसला किया है
  • अभी अगर पूछा जाए कि JavaScript या TypeScript project के लिए क्या recommend किया जाए, तो जवाब pnpm होगा

यह Bun छोड़ने की सलाह नहीं है

  • कुछ projects को Bun से हटाया जा रहा है, लेकिन इसे हर किसी के लिए सामान्य जवाब मानने की ज़रूरत नहीं है
  • नए projects के लिए pnpm समझदारी भरा विकल्प है
  • existing projects के लिए, जब तक छोड़ने का पर्याप्त कारण न मिले, Bun पर बने रहना भी एक वैध विकल्प है

बची हुई संभावना और निष्कर्ष

  • उम्मीद यही है कि Bun शानदार बना रहे, Bun टीम अच्छा काम जारी रखे, और Anthropic उसे इतनी autonomy दे कि वह JavaScript ecosystem के अनुरूप फैसले ले सके
  • Anthropic के पास पैसा है, distribution power है, और Bun की performance व stability की परवाह करने के ठोस कारण भी हैं
  • Bun अब भी इस पूरे दौर से गुज़रकर और मज़बूत होकर निकल सकता है
  • फिर भी दिसंबर 2025 की तुलना में मौजूदा स्थिति पर भरोसा कम हुआ है
  • पहले का Claude Code इस बात का सबूत लगता था कि Anthropic developer tools को समझता है, लेकिन अब यह एक warning जैसा दिखता है कि शायद Anthropic नहीं समझता कि products को लंबे समय तक बनाए रखने और बेहतर करने के लिए क्या चाहिए
  • Bun अब भी शानदार है, लेकिन आगे यह किस दिशा में जाएगा, यह कहना कठिन है
  • एक साल बाद स्थिति पूरी तरह बदल भी सकती है, इसलिए यह आकलन सही था या नहीं, इसे बाद में फिर देखना होगा

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

3 टिप्पणियां

 
click 3 시간 전

मैं मानता हूँ कि bun की वजह से node में भी काफी बदलाव आए हैं, लेकिन जब रिपॉजिटरी में AI आपस में PR के जरिए ढोल-नगाड़े बजाते दिखते हैं, तो डर लगता है कि कहीं पहले से चल रही चीज़ें भी regression जैसी बारूदी सुरंग पर पैर रखकर टूट न जाएँ।
anthropic के अधिग्रहण से पहले मैं bun को main के तौर पर इस्तेमाल करता था, लेकिन अब फिर से node पर लौट आया हूँ।
मुझे अब भी लगता है कि sfx फीचर एक killer feature है, लेकिन अगर उसकी ज़रूरत नहीं है, तो अभी bun इस्तेमाल करने की कोई खास वजह मुझे नहीं दिखती।
 
GN⁺ 7 시간 전
Hacker News की राय

  • मैं पूरे आधार से सहमत नहीं हूँ: अधिग्रहण से पहले भी Bun को कभी न कभी कमाई का तरीका ढूँढना ही था
    सिर्फ इसलिए कि इसकी पैरेंट कंपनी ने Claude Code जैसे दूसरे सॉफ़्टवेयर में खराब प्रथाएँ दिखाई हैं, यह मान लेना ज़्यादा हो जाता है कि वही Bun को भी खराब बना देगा। चिंता समझ में आती है, लेकिन Bun को लेकर मैं अभी भी आशावादी हूँ
    Claude Code, Anthropic का मुख्य प्रोडक्ट है और उसकी ग्रोथ भी बेहद तेज़ है, इसलिए छोटे बदलाव भी बिलिंग की समस्या बन सकते हैं। दूसरी ओर Bun एक JavaScript runtime है, इसलिए वह सबसे अच्छा runtime बनने पर ध्यान दे सकता है, और Anthropic की revenue या P&L पर उसका सीधा असर नहीं पड़ता, इसलिए Claude Code की तरह misuse के कारण जल्दबाज़ी में patch निकालने की ज़रूरत भी कम है
    आने वाले कुछ सालों में क्या होगा, यह अभी अनिश्चित है, लेकिन अधिग्रहण के तुरंत बाद इस समय मैं ज़्यादा चिंतित नहीं हूँ

    • यह दिलचस्प है कि लोग misuse वाली व्याख्या को बहुत जल्दी मान लेते हैं। बड़े AI लैब्स लंबे समय से जानते थे कि heavy subscription users से वे वित्तीय लाभ नहीं कमा रहे, और इसका इस बात से कोई लेना-देना नहीं कि कौन-सा agent या execution tool इस्तेमाल हो रहा है। लाभकारी और न्यायसंगत pricing तो usage-based token billing ही है
      ये लैब्स third-party execution tools को खत्म करना चाहते हैं, क्योंकि वे base large language models को commodity बना देने का जोखिम पैदा करते हैं, और साथ ही वे आपस में यह chicken game भी खेल रहे हैं कि कौन कितने समय तक घाटा सह सकता है
      आखिरकार इन्हें प्रोडक्ट की सही pricing करनी ही पड़ेगी, और तब तक बस यही उम्मीद कर सकते हैं कि इन्होंने सारा competition खत्म कर दिया हो। लेकिन लगता है कि वे यह खेल पहले ही हार रहे हैं। उपयोगी models हर साल छोटे हो रहे हैं और उन्हें चलाने की लागत भी कम हो रही है, इसलिए हम उस threshold को पार कर चुके हैं जहाँ third-party execution tools बिना subscription user base के भी बनते रह सकते हैं
      उनकी मूल बाज़ी यह थी कि “उपयोगी AI के लिए बेहद महँगा hardware चाहिए”, और वह पहले ही फेल हो चुकी है; दूसरी बाज़ी कि पहले users को ecosystem में बाँध लो और बाद में monetize करेंगे, वह भी फेल होगी। अंत में उन्हें सिर्फ प्रोडक्ट की अपनी क्षमता पर compete करना होगा, और वह कहीं कम लाभकारी है
    • मुझे तो “अधिग्रहण से पहले भी Bun को कभी न कभी कमाई का तरीका ढूँढना था” वाली स्थिति ही बेतुकी लगती है। यह भी अजीब है कि लोग पहले से ही ऐसे JavaScript runtime, जिसे कभी न कभी monetize करना पड़ेगा, उस पर निर्भर हो गए, और उससे भी विचित्र यह है कि उसे उस क्षेत्र की सबसे घाटे वाली कंपनियों में से एक ने खरीद लिया जो पूरे उद्योग में सबसे बड़े घाटे वाले क्षेत्रों में गिना जाता है, फिर भी लोग उम्मीद लगाए हुए हैं
    • लगता है कि आप किसी कंपनी की नीति और संस्कृति का प्रोडक्ट पर असर कम आँक रहे हैं
      कुछ टीमें अब पूरी तरह AI पर दाँव लगा रही हैं, यहाँ तक कि कोड को खुद देखने से भी बचना चाहती हैं। मैंने यह वास्तविक रूप से देखा है, और नतीजे लगभग वैसा ही हैं जैसा सोचा जा सकता है। कुछ हद तक यह काम करता है, लेकिन खासकर जब टीमों के बीच तकनीकी शब्दावली और समझ अलग हो, तब जटिलता बढ़ती जाती है, गलतियाँ जमा होती जाती हैं, और अंत में ऐसा हो जाता है कि किसी व्यक्ति या टीम को वास्तव में पता ही नहीं होता कि सॉफ़्टवेयर अंदर से कैसे काम करता है
      एक रुझान यह भी है कि इंसान द्वारा testing या QA किए बिना, unit tests और integration tests के ऊपर AI से browser या tools नियंत्रित कराए जाएँ। Anthropic की संस्कृति Bun टीम के काम करने के तरीके और सोच को बदल सकती है
      अगर यह संस्कृति और सोच standard बन गई, तो या तो models बहुत बेहतर होने होंगे, नहीं तो software quality नीचे जाएगी
      Matt Pocock की एक अच्छी प्रस्तुति है: https://youtu.be/v4F1gFy-hqg
      “कोड सस्ता नहीं है। खराब कोड अब तक का सबसे महँगा हो चुका है। क्योंकि अगर आपके पास ऐसा codebase है जिसे बदलना मुश्किल है, तो आप AI से मिलने वाली प्रचुरता का लाभ नहीं उठा सकते। अच्छे codebase में AI सचमुच बहुत, बहुत अच्छा काम करता है।”
      जब खराब कोड अपने-आप जमा होना शुरू हो जाए, तो उससे बाहर निकलना बेहद मुश्किल हो जाता है
    • इसी तर्क से देखें तो अधिग्रहण से पहले GitHub को भी कभी न कभी कमाई का तरीका ढूँढना था। अगर पैरेंट कंपनी Microsoft ने Embrace, Extend, Extinguish या MS Windows में खराब प्रथाएँ दिखाई थीं, तो यह कहना कि GitHub भी खराब हो जाएगा, ज़्यादा होगा; इसलिए चिंता समझ में आती है, लेकिन GitHub को लेकर आशावादी हूँ — यह बात उससे अलग नहीं है
    • Anthropic ने Bun को पूरे JavaScript community के लिए नहीं, बल्कि Claude Code में अपने निवेश को बचाने और बढ़ाने के लिए खरीदा है। यह बात साफ़ लगती है, लेकिन इसे स्पष्ट कहना चाहिए। लंबी अवधि में नतीजे incentives का ही पीछा करेंगे

  • मुझे समझ नहीं आता कि लोग Node की जगह Deno या Bun क्यों इस्तेमाल करते हैं। JavaScript runtime competitors होना अच्छी बात है, लेकिन Node से switch करने पर क्या फायदा मिलता है, यह साफ़ नहीं है
    Bun में REPL नहीं है और उसका JavaScript engine भी खराब है, Deno मुझे permission system वाला सीमित और झंझटभरा Node लगता है, और मैंने समझा था कि उसमें sqlite भी नहीं है। दोनों performance में अच्छे बताए जाते हैं, लेकिन शायद सिर्फ चुने हुए benchmarks में; लगभग एक साल पहले मैंने अपने workload पर खुद आज़माया था और दोनों ही Node से धीमे थे
    हाँ, एक बार जब मैं एक छोटा ERP tool deliver कर रहा था, तब project को *.exe में wrap करने का Bun वाला tool सबसे मज़बूत था, इसलिए Bun इस्तेमाल किया था। बिना dependencies वाले JavaScript के लिए पूरा सिस्टम Node में बनाया और सिर्फ deployment Bun से किया, और वह अनुभव निश्चित रूप से Node से बेहतर था

    • Deno में sqlite है: https://docs.deno.com/examples/sqlite/
    • Bun का developer experience Node से कहीं बेहतर है, खासकर TypeScript projects में यह फ़र्क बड़ा महसूस होता है
    • Deno अच्छा है क्योंकि user को अलग से installation step किए बिना बस run करना होता है

  • Bun पहले भी कभी खास ठीक से maintain नहीं हुआ था। हर feature में bugs और gaps थे, और हर release में कुछ चीज़ें ठीक होतीं तो कुछ और टूट जातीं
    एक हालिया patch release में उसने उतने बड़े features और breaking changes डाल दिए जितने ज़्यादातर software दो major versions में देखते हैं
    मैं उसे मूलतः script runner और npm package manager की तरह ही इस्तेमाल करता हूँ, फिर भी “अच्छा” version ढूँढने में जितनी मेहनत लगती है, वह हैरान करने वाली है। patch versions में installation के दौरान कई बार वह अचानक hang हो गया, और उसी कारण मैं कुछ समय तक upgrade भी नहीं कर पाया
    लगभग दो minor versions पहले ऐसा लगा कि उसने trustedDependencies के साथ postinstall scripts को पूरी तरह बिगाड़ दिया। release notes में इसका एक शब्द नहीं था और GitHub issues में भी किसी ने report नहीं किया लगता। 1.1 के आसपास Bun में trustedDependency build को postinstall में चलवाया जा सकता था, लेकिन बाद में वह बंद हो गया और महीनों से टूटा हुआ है

    • installation के दौरान hang होने की समस्या पर एक GitHub issue है। security scanner पूरी dependency list को command-line arguments के रूप में भेजता है, और Linux के बड़े monorepo में यह ARG_MAX पार कर देता है
      spawn बिना कोई error दिए चुपचाप hang हो जाता है, और scanner postinstall से अलग है इसलिए --ignore-scripts भी मदद नहीं करता। कम-से-कम 1.3.5 से यह टूटा हुआ है

  • मैं Bun में काम करता हूँ, और यह पोस्ट मुझे थोड़ा उलझी हुई लगती है। मैं खुद भी और Bun टीम भी रोज़ Bun का इस्तेमाल करते हैं और उसे बेहतर बनाते हैं, और development की रफ़्तार तो उल्टा और बढ़ी है। Anthropic में शामिल होने के बाद Bun की stability भी बहुत बेहतर हुई है
    अगले Bun version में आने वाली चीज़ों में Windows x64 binary को 17MB छोटा करना [0], Linux binary को 8MB छोटा करना [1], बचे हुए child processes को recursively खत्म करने वाला --no-orphans CLI flag [3], Mongoose/MongoDB जैसे database clients की memory usage को काफ़ी कम करने के लिए client TCP और Unix sockets के लिए SSL context caching [4], fetch के लिए experimental HTTP/3 और HTTP/2 clients [5], Bun.serve() के लिए experimental HTTP/3 support [6], built-in image processing library Bun.Image [7] आदि शामिल हैं
    इसके अलावा node:fs, Worker, BroadcastChannel और MessagePort की reliability improvements भी आ रही हैं
    Anthropic के अधिग्रहण की वजह से अब Bun को revenue-generating business होने की ज़रूरत नहीं है। Claude Code, Bun पर निर्भर है, और बहुत-से software engineers Claude Code पर निर्भर होकर काम करते हैं, इसलिए Bun को बेहतर बनाने का मज़बूत incentive मौजूद है
    [0]: https://github.com/oven-sh/bun/pull/30219
    [1]: https://github.com/oven-sh/bun/pull/30098
    [2]: https://github.com/oven-sh/WebKit/pull/211
    [3]: https://github.com/oven-sh/bun/pull/29930
    [4]: https://github.com/oven-sh/bun/pull/29932
    [5]: https://github.com/oven-sh/bun/pull/29863
    [6]: https://github.com/oven-sh/bun/pull/30032

    • इस उद्योग में acquisitions आम तौर पर किसी न किसी हद तक एक तयशुदा नतीजे तक पहुँचते हैं। खरीदा गया software अक्सर इसलिए बिगड़ जाता है क्योंकि मूल टीम के लोग payout लेकर चले जाते हैं, और पुरानी संस्कृति की जगह नए मालिक की संस्कृति आ जाती है
      हो सकता है Bun अपवाद निकले, लेकिन चिंता को पूरी तरह बेबुनियाद नहीं कहा जा सकता
      Anthropic के CEO अक्सर ऐसे बढ़ा-चढ़ाकर अनुमान लगाते रहे हैं मानो AI लगभग मानव programmers की जगह ले लेगा, और Anthropic उसी विश्वास को Claude Code पर लागू करते हुए उसे unmaintainable spaghetti में बदल रहा है
    • हाल के समय में Bun की सबसे बेहतरीन सुविधा portable binaries रही है। बहुत-से users पुराने Linux distributions चलाते हैं, इसलिए portability बेहद अहम है। Node और Deno को नया Linux, और खासकर नई glibc चाहिए
    • “मैं Bun में काम करता हूँ” कहना बहुत बड़ा understatement है। Anthropic को लेकर चिंताएँ हैं, लेकिन जब तक Jarred नेतृत्व में है, मुझे नहीं लगता Bun गलत दिशा में जाएगा। मेरा मानना है कि वह बड़े संगठन की stability और funding का अच्छा उपयोग कर रहा है

  • मैंने knife sharpening website के backend को Bun से Node में migrate करने में कुछ घंटे लगाए, और lock-in effect से बच निकलने पर अच्छा लगा। शुरू में मैं Bun को लेकर काफ़ी उत्साहित था, लेकिन धीरे-धीरे भरोसा कम होता गया
    जिन features की कमी महसूस होगी, वे हैं tagged template literals से sqlite query करना, Bun.password.verify का default रूप से argon2 इस्तेमाल करना, HTML imports, JSX transform, और .env files का auto-loading
    https://burlyburr.com से https://backend.burlyburr.com को call किया जाता है

    • Node भी tagged template literals से sqlite query को support करता है
      https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
    • मुझे लगता है कि जिन features की आपको कमी लग रही है, उन्हें वापस पाने के लिए एक छोटी helper library ही काफी होगी। Node में कम-से-कम SQLite और Argon2 तो हैं, इसलिए अगर समस्या interface की है, तो उसे आसानी से ठीक किया जा सकता है
    • Node भी .env auto-loading और sqlite को support करता है

  • मुझे नहीं लगता Bun अधिग्रहण से पहले भी बहुत अच्छा काम कर रहा था। छोटे scripts के लिए मैं उसे इस्तेमाल करता रहा, लेकिन नौकरी में किसी service को Bun पर deploy नहीं करता
    memory issues और न सुधरने वाली incompatibilities के कारण मैं उसे एक ठीक-ठाक खिलौना मानता था, जिसने बस इतना दिखाया कि Node.js में सुधार की गुंजाइश है
    उदाहरण के लिए मैं https://github.com/oven-sh/bun/issues/14102 को लगातार देखता रहा, और आखिरकार libraries ने “अगर Bun है तो x करो” जैसी branches डालनी शुरू कर दीं, जो compatibility के ठीक उलट है

    • मैंने कुछ projects में production environment के लिए इसे आज़माने की कोशिश की, लेकिन दोनों में Bun से वापस Node पर जाना पड़ा। एक में, जैसा ऊपर कहा, बड़ी memory leak थी, और दूसरे में TextDecoderStream जैसी जगहों पर API differences की वजह से errors आए। मैंने तय किया कि Bun v2 से पहले दोबारा कोशिश नहीं करूँगा

  • Claude Code और Anthropic की दिशा ऐसी लगती है मानो वे users से कुछ ज़बरदस्ती छिपाना चाहते हों। कुछ लोगों को वह हंगामा याद होगा जब xxx.yy पढ़ने का व्यवहार 1 file read से बदलकर 2 file reads हो गया था
    ऐसे बदलाव और भी हुए, और उन्हें configure करना या तो असंभव था या बहुत मुश्किल। मैं business intent समझता हूँ: जितना हो सके उतना AI इस्तेमाल करवाना, human को loop से बाहर करना, और ज़्यादा training data तथा ज़्यादा token usage पाना
    लेकिन नतीजा यह हुआ है कि Claude Code मुझे कहीं ज़्यादा खराब और कहीं कम भरोसेमंद लगता है। ऐसा महसूस होता है जैसे user से चुपके से steering wheel छीनने की कोशिश हो रही हो। उस तर्क पर चलें तो धीरे-धीरे और भी बहुत-सी बातें सही ठहराई जा सकती हैं
    इस समय की स्थिति में मुख्य रूप से अविश्वास बहुत बढ़ गया है

  • मैं मूल पोस्ट से सहमत हूँ, और यह भी समझता हूँ कि कुछ लोगों को यह अभी जल्दबाज़ी वाली प्रतिक्रिया लग सकती है
    हम पहले से बहुत अलग दुनिया में जी रहे हैं, और लोग ethical concerns को ज़्यादा लेकर सजग हैं, साथ ही पुराने गलतियों को दोहराने से बचने के लिए टिके रहने की इच्छा भी अधिक है
    तकनीकी मानकों से यह जल्दी किया गया फैसला लग सकता है, लेकिन ethical concerns के पैमाने पर यह समझ में आता है। गलत कदम पहले की तरह आसानी से पलटे नहीं जा सकते, और ऐसे फ़ैसलों के बड़े असर से बचने के लिए पहले से कार्रवाई ज़रूरी है

    • मैं यह जानना चाहूँगा कि लोग पहले की तुलना में ethical concerns को ज़्यादा लेकर सजग हैं — इसका आधार क्या है? मुझे नहीं लगता कि लोग पहले से ज़्यादा ethical दिखते हैं। उदाहरण के लिए BDS पक्ष के लोगों की संख्या थोड़ी बढ़ी दिखती है, लेकिन उसके अलावा ज़्यादा कुछ नज़र नहीं आता
    • Firefox और Safari द्वारा Chrome OS platform APIs न अपनाने की शिकायतें, या Chrome को हर जगह फैलाने की वास्तविकता को देखें, तो मुझे नहीं लगता कि लोग ethical considerations निभाते हुए डटे हुए हैं

  • लेखक अंत में Bun की वे चीज़ें गिनाता है जो उसे पसंद हैं लेकिन pnpm में नहीं हैं। सूची मोटे तौर पर native TS support, Vite-शैली bundler, और Vitest/Jest-शैली test runner की है
    bundler को छोड़ दें तो Node में यह सब पहले से है। test runner की syntax अलग हो सकती है, लेकिन TypeScript मूल रूप से “बस काम करता है” और built-in test runner भी काफी उपयोगी है। इसलिए मुझे नहीं लगता कि Bun पर इतना शोक मनाने की ज़रूरत है

    • निष्पक्ष रूप से कहें तो Node में ये चीज़ें तब तक नहीं थीं जब तक Deno और Bun ने चुनौती नहीं दी। किसी कारण Deno अकेले इतना बड़ा बदलाव नहीं ला पाया, लेकिन Bun की मौजूदगी ने Node Technical Steering Committee पर वास्तविक असर डाला
      यह भी कहा जा सकता है कि Jarred Sumner की चतुर social media marketing ने मौजूदा momentum का बड़ा हिस्सा बनाया। उसने लोगों को बात करने पर मजबूर किया, और उसी का लाभ Node को भी मिला
      इसके अलावा Bun ने जितना संभव हो सके उतने Node APIs को support करने के लिए ज़ोर लगाया, उसी की वजह से Deno भी उसी स्तर की compatibility की दिशा में बढ़ा, और अब ज़्यादातर code वास्तव में runtime से कम बँधा हुआ है। मैं production environment में Bun चलाऊँगा या नहीं, यह नहीं जानता, लेकिन सिर्फ Bun के अस्तित्व से ही JavaScript ecosystem काफी बेहतर हुआ है, इसलिए यह अच्छी बात है
    • Node ने native TypeScript कब जोड़ा? क्या बिना dependencies के सीधे node main.ts चलाया जा सकता है?
    • TypeScript compiler rewrite को भी ध्यान में रखें तो Bun की प्रासंगिकता और कम हो जाती है

  • सच कहूँ तो Bun का मैंने मॉड्यूल टेस्टिंग के अलावा ज़्यादा इस्तेमाल नहीं किया। रोज़मर्रा में मैं ज़्यादातर Deno का इस्तेमाल करता हूँ, और पिछले कुछ सालों में मैंने बहुत-सी shell scripts भी Deno में लिखी हैं
    हाल की usability मुझे काफ़ी पसंद आई, और repository के modules को सीधे refer करने का तरीका shell scripts के लिए खास तौर पर अच्छा है
    लेकिन मुझे चिंता है कि क्या वह features खुले रखते हुए पर्याप्त monetization कर पाएगा, या कम-से-कम दूसरों को उसे clone करने देने की स्थिति में रहेगा। इसलिए कुछ चिंताएँ समझ में आती हैं
 
jjpark78 3 시간 전

https://github.com/oven-sh/bun/issues/17723

बस इतना सा भी ठीक कर दें तो लगता है बैकएंड में एक बार चलाकर देखूंगा...