Zig के संस्थापक सच बोलते हैं, लेकिन Anthropic डींगें हाँक रहा है.

 (raymyers.org)
3 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Anthropic software engineering के अंत को भविष्य की वैल्यू के रूप में पेश कर रहा है, और इसी बीच Bun का Zig→Rust रूपांतरण भी इस प्रचार कथा में इस्तेमाल हुआ कि AI engineering की जगह ले सकता है
  • Bun ने memory bug को बदलाव की वजह बताया, लेकिन विकल्पों और उनके फायदे-नुकसान की तुलना पर्याप्त नहीं दी, और Rust की slow compile जैसी लागतें भी साझा नहीं कीं, इसलिए यह बाद में किया गया औचित्यकरण लग सकता है
  • Zig को अलग तरीके से चलाने के विकल्प भी थे, और TigerBeetle का TigerStyle static memory allocation और simulation testing के जरिए use-after-free को रोकने का उदाहरण दिखाता है
  • unsafe Rust में file-by-file porting का तरीका जोखिम घटाने और आगे redesign की गुंजाइश छोड़ने वाला एक तर्कसंगत approach था, लेकिन million-line स्तर के AI conversion को स्वीकार करते हुए इंसानों के पढ़ने लायक pointer management की कुछ lines को समस्या बताना एकसमान रुख नहीं दिखाता
  • agent harness, Rust का borrow checker, readability rules, और human review लगातार ज़रूरी हैं, इसलिए coding agents को अपनाना और software engineering को समाप्त मान लेना एक ही विकल्प नहीं है

Anthropic द्वारा पेश किया जा रहा software engineering का अंत

  • Anthropic coding के बाद software engineering और अधिकांश human labor के भी खत्म हो जाने वाली कथा को आक्रामक रूप से आगे बढ़ा रहा है
  • कंपनी ने 132 अरब डॉलर का निवेश जुटाया है और 1 ट्रिलियन डॉलर से अधिक valuation वाले IPO के करीब है, लेकिन profitability दिखाने में असफल स्थिति में उसे एक काल्पनिक भविष्य के प्रभाव को बेचना पड़ रहा है
  • इसी हित-संबंध के कारण Anthropic को unreliable narrator की तरह देखना चाहिए, और सवाल सिर्फ उसके संदेश की सच्चाई का नहीं, बल्कि executives, world leaders, और pension fund managers के फैसलों पर उसके असर का भी है
  • AI narrative architecture, product, और staffing decisions को प्रभावित करती है, और layoffs के डर, पीछे छूट जाने की चेतावनी, तथा Doom Trolling के बीच ठंडे दिमाग से निर्णय लेना मुश्किल बनाती है
  • software क्षेत्र में AI का मूल्यांकन करते समय Anthropic के हितों और उसके प्रचार उद्देश्य को ध्यान में रखकर संदेहपूर्ण समीक्षा की ज़रूरत है

Bun का Zig→Rust रूपांतरण और देर से दी गई सफाई

  • Anthropic/Bun ने Zig में लिखे गए Bun को Rust में ले जाने के फैसले को main branch में merge करने के दो महीने बाद जाकर सफाई दी
    • बड़े infrastructure project में आम तौर पर दिशा बदलने की बात पहले समझाई जाती है
    • सफाई देर से आने तक Anthropic’s Bun Rust rewrite merged at speed of AI जैसे शीर्षक यह धारणा फैलाते रहे कि AI ने rewrite बहुत तेजी से पूरा कर दिया
  • Zig के संस्थापक Andrew Kelley ने जवाबी लेख प्रकाशित किया और असामान्य रूप से सीधे लहजे में Bun की technology और organizational operation की आलोचना की
    • सिर्फ language बदलने के कारण पुरानी language के leader द्वारा व्यक्तिगत कमियों तक हमला करने जैसी मिसाल बनने का reputational risk इसमें था
    • कुछ लोगों ने इसे “meltdown” कहा, लेकिन यह भी माना जा सकता है कि उन्होंने उन समस्याओं को सार्वजनिक रूप से उठाया जिन्हें उठाना ज़रूरी था

इस सीधी आलोचना को परखने का मानदंड

  • बौद्ध धर्म की right speech के अनुसार हर कथन को इन पाँच मानकों पर खरा उतरना चाहिए
    • क्या यह सच है
    • क्या यह मददगार है
    • क्या यह समयोचित है
    • क्या यह दयालु है
    • क्या यह दयाभाव से निकला है
  • Andrew Kelley की प्रतिक्रिया सच लेकिन कठोर बात की श्रेणी में आती है, और विवाद का केंद्र यह है कि सामान्य शिष्टाचार से हटकर भी क्या इन समस्याओं को सार्वजनिक रूप से इंगित करना आवश्यक था

Bun, Zig, और AI contribution policy का संबंध

  • Bun एक TypeScript runtime है जिसकी तुलना तेज़ NodeJS से की जाती है, और Zig एक systems programming language है जिसकी तुलना आधुनिक C से की जाती है
  • हाल तक Bun Zig में लिखा गया था और यह Zig के सबसे बड़े codebase में से एक था
  • दोनों projects की AI contribution policy बिल्कुल उलटी है
  • Anthropic द्वारा Bun के अधिग्रहण के बाद संस्थापक Jarred Sumner ने Zig code को unsafe Rust में ले जाने का बड़े पैमाने का agent experiment चलाया, और नतीजा कुछ ही दिनों बाद merge होकर official version बन गया
  • संबंधित पक्षों में ऐसा कोई पक्ष दिखाई नहीं देता जो Bun को Zig में ही बनाए रखने की मांग कर रहा हो; बहस रूपांतरण से अधिक उसके कारणों और उसके प्रचार तरीके पर केंद्रित है
  • agents की मदद से बड़े पैमाने पर language conversion, सही परिस्थिति में, दोबारा आज़माने लायक एक तकनीकी प्रयोग है

एक ही फैसले की तीन व्याख्याएँ

  • Zig और Rust में से एक चुनने वाले developers के लिए, Zig के सबसे बड़े users में से एक का अपना फैसला पलटना महत्वपूर्ण संकेत बनता है
  • Anthropic/Bun की व्याख्या यह है कि उन्होंने सभी तर्कसंगत तरीकों को आज़माया, लेकिन Zig में memory bug संभालना मुश्किल था
  • Andrew Kelley की व्याख्या के अनुसार Bun के engineering decisions — जैसे AI agents पर code writing और review के लिए अत्यधिक निर्भरता — ने codebase को अव्यवस्थित बना दिया
  • एक अधिक साधारण संभावना यह है कि वास्तविक memory समस्याओं के कई समाधान थे, लेकिन management के लिए Rust rewrite चुनना आसान था
    • इससे नए Fable model की क्षमता का प्रचार किया जा सकता था
    • Anthropic पहले से Rust इस्तेमाल कर रहा था
    • Zig project ने सार्वजनिक रूप से Anthropic products के उपयोग का विरोध किया है
  • Rust में बदलाव business के लिहाज़ से तर्कसंगत हो सकता है, लेकिन प्रचार का फोकस इस बात पर रहा कि AI इतना शक्तिशाली है कि rewrite कर सके
    • यह तथ्य कि AI use-after-free को पहले से पकड़ नहीं पाया, इस narrative से टकराता है
  • Anthropic के amplification ने Jarred Sumner और Andrew Kelley के निर्णयों की सीधी तुलना की स्थिति बनाई, और अनजाने में Zig की प्रतिष्ठा पर भी असर डाल सकता है

तकनीकी बहस में व्यक्तिगत विश्वसनीयता क्यों आ गई

  • सबसे पहले जवाबदेही Bun के संस्थापक व्यक्ति से अधिक Anthropic पर डालनी चाहिए, क्योंकि वही इस घटना को AI narrative में इस्तेमाल कर रहा है
  • चूँकि Anthropic, Jarred Sumner की credibility का उपयोग अपने संदेश को मजबूत करने में कर रहा है, इसलिए जवाब में उसके निर्णय और आचरण का मूल्यांकन भी अनिवार्य हो जाता है
  • सिर्फ technical issues पर चर्चा करना बेहतर होता, लेकिन जब Anthropic का संदेश तकनीकी तुलना से अधिक दिखावे और प्रचार पर निर्भर हो, तो व्यक्तिगत credibility भी बहस में आ जाती है
  • अगर सार्वजनिक रूप से कही और की गई बातों को क्रम से रखने भर से वह निंदात्मक लगे, तो संभव है कि वह आचरण खुद भी समस्या का हिस्सा हो

लगातार crunch और Bun का organizational environment

  • Bun की 2022 hiring notice में चेतावनी दी गई थी कि शुरुआती 9 महीने बेहद कठिन होंगे, और अगर कोई काम-जीवन संतुलन का ऐसा रूप चाहता है जिसमें काम न करने का समय अधिक हो, तो यह उसके लिए नहीं है
  • लगातार crunch mode स्वास्थ्य और productivity दोनों के लिए हानिकारक है, और knowledge work पर empirical research में यह बार-बार दिखाया गया है
    • संबंधित सामग्री के लिए Empirical Software Engineering के Human Factors भाग को देखा जा सकता है
  • सप्ताह में 90 घंटे काम पर गर्व करने वाले manager की बजाय उस manager को चुनना चाहिए जो team को रात में सो पाने लायक सुरक्षा दे
  • Andrew Kelley के अनुसार Bun team के एक संबंधित व्यक्ति से मिली राय communication की कमी, अवास्तविक अपेक्षाएँ, कम empathy, और अनुभव की कमी में संक्षेपित होती है, लेकिन यह hearsay होने की सीमा भी रखती है
  • फिर भी यह आकलन hiring notice में सार्वजनिक रूप से बताए गए चरम कार्य-पर्यावरण से मेल खाता है
  • खराब work environment में भी बेहतरीन technology निकल सकती है, और Bun स्वयं एक उपयोगी और दिलचस्प tool है
  • code में bugs अधिक थे और उसे maintain करना कठिन था — यह सिर्फ बाहरी आलोचना नहीं, बल्कि वही स्थिति है जिसे Bun ने Rust रूपांतरण के आधार के रूप में पेश किया है

unsafe Rust पोर्टिंग तरीके का वास्तविक मूल्य

  • ट्रांज़िशन प्रक्रिया के तकनीकी विवरण अन्य modernization projects में भी दोबारा इस्तेमाल करने लायक हैं
  • Bun ने शुरुआत से safe Rust में redesign करने के बजाय unsafe Rust के साथ file-level porting किया
    • मौजूदा structure को बनाए रखकर शुरुआती ट्रांज़िशन जोखिम घटाया
    • बाद में safety सुधारने और redesign करने की नींव तैयार की
  • AI-आधारित automation से language choice को पहले की तुलना में आसानी से पलटना संभव हो सकता है, लेकिन automatic rewriting में अब भी फायदे-नुकसान और meaning gap मौजूद हैं
  • कई rewriting techniques को मिलाकर formal methods से उन्हें मजबूत करना भी संभव है
  • DARPA का TRACTOR सभी C code को Rust में ले जाने वाला एक research program है, और सार्वजनिक evaluation report automatic conversion technology की मौजूदा स्थिति पर चर्चा करती है
  • भले ही agents पुराने code के लिए ज्यादा options दें, modernization goals तय करने के लिए judgment और communication की जरूरत बनी रहती है
    • संबंधित संदर्भ पुस्तक Marianne Bellotti की Kill It With Fire है

बहुत कुछ छोड़ देने वाला technical decision document

  • किसी technical decision को समझाने के लिए कम से कम तीन चीजें चाहिए
    • motivation क्या है
    • किन alternatives पर विचार किया गया
    • हर alternative के pros and cons क्या हैं
  • Richard Feldman ने Roc compiler को Rust से Zig में ले जाने के कारणों को जिस document में समेटा है, वह इन तीनों तत्वों वाला comparative case है
  • Bun की सफाई ने memory bugs जैसी motivation तो दी, लेकिन जिन alternatives की समीक्षा की गई उन्हें केवल आंशिक रूप से छुआ, और pros and cons की तुलना लगभग गायब है
  • खासकर जब pros and cons छोड़ दिए जाते हैं, तो यह ऐसा लग सकता है जैसे पहले से निष्कर्ष तय था और बाद में उसके समर्थन में तर्क जोड़े गए हों — यानी post-hoc justification
  • यह संभावना भी खारिज नहीं की जा सकती कि कुछ अलग कारण सार्वजनिक नहीं किए गए हों, और decision की reliability बढ़ाने के लिए प्रतिकूल लागतों को भी साथ में बताना चाहिए

केवल Rust के फायदे गिनाने वाली तुलना

  • “Bun is better in Rust” वाला हिस्सा सिर्फ Rust migration के फायदों पर बात करता है और लागत लगभग नहीं बताता
  • बड़े Rust codebases आम तौर पर safety के बदले slow compile times की कीमत चुकाते हैं
  • Bun ने अतीत में compile speed को महत्वपूर्ण मानते हुए Zig compiler को fork करके 4x faster compilation times हासिल करने की कोशिश की थी
  • अगर Rust porting से contributors का build time बढ़ा है, तो उसे सार्वजनिक करना और यह बताना कि उस लागत से safety क्यों ज्यादा महत्वपूर्ण है, decision की विश्वसनीयता बढ़ाएगा
  • migration के बाद किए गए दूसरे improvements को भी Rust rewrite के फायदों की सूची में मिला देने से language change का सीधा असर बढ़ा-चढ़ाकर दिख सकता है

style guide के अनदेखे विकल्प

  • Bun में memory bugs अकेला defect source नहीं थे, लेकिन निजी tally के मुताबिक वे इतने बार आते थे कि हर हफ्ते 4 fix commits की जरूरत पड़ती थी
  • हर memory bug का मतलब है कि object के creation, ownership, और release के बारे में कोई rule कहीं न कहीं टूटा, इसलिए सबसे पहले ऐसे तरीकों की समीक्षा की जा सकती है जो context के हिसाब से expected behavior को साफ़ तौर पर परिभाषित करें
  • manual memory management rules का दायरा बढ़ा देता है, लेकिन भाषा चाहे जो हो, प्रभावी usage guidelines की जरूरत रहती है, और Rust में भी API style guide है

  • TigerBeetle जो विकल्प दिखाता है

    • Zig का एक और प्रमुख codebase, financial transaction database TigerBeetle, memory bugs से परेशान नहीं दिखता और सबसे विश्वसनीय databases में से एक प्रतीत होता है
    • यह TigerStyle और simulation testing को reliability की नींव मानता है
    • TigerStyle सिर्फ coding style नहीं, बल्कि design, memory, और testing को जोड़ने वाला एक engineering philosophy है
    • सारी memory शुरुआत में statically allocate की जाती है
    • initialization के बाद dynamic allocation या free के बाद re-allocation की अनुमति नहीं है
    • इससे अनुमान लगाना कठिन performance changes से बचते हुए use-after-free रोका जाता है
    • design stage में ही संभावित memory usage patterns पर विचार करके यह ज्यादा simple, faster, और reasoning व maintenance के लिए आसान structure की ओर ले जाता है
    • सभी applications इस तरीके को ज्यों का त्यों लागू नहीं कर सकते, लेकिन यह दिखाता है कि memory policy पूरे design decisions से जुड़ी होती है

  • Bun की सफाई में बचे खाली स्थान

    • Bun ने TigerStyle और Google की 31,000-word C++ style guide का ज़िक्र करने के बाद यह निष्कर्ष दिया कि style guides को enforce करना कठिन है और परंपरागत रूप से code review, linters, और static analyzers पर निर्भर रहना पड़ता है
    • लेकिन Bun वास्तव में कौन-सी style guide इस्तेमाल कर रहा था, वह क्यों विफल हुई, और 4 साल में उसमें क्या सुधार हुए, इस पर बात नहीं करता
    • अगर किसी बड़े project में memory issues लगातार बने रहे, तो यह अहम है कि क्या मौजूदा language को अलग तरीके से इस्तेमाल करने वाले विकल्पों को गंभीरता से परखा गया था, लेकिन इसे समर्थन देने वाला आधार कम है
    • ऐसा operating model जिसमें एक व्यक्ति सारा context दिमाग में रखता हो और meetings न करता हो, explicit rules और shared design बनाना कठिन कर देता है

agent review और style guide के बीच विरोधाभास

  • Bun style guide को enforce करना कठिन मानता है, फिर भी उसने migration के लिए PORTING.md लिखा और बताया कि agents ने पूरे rewritten code को सख्त guidelines के अनुसार review किया
  • PORTING.md खुद transition scope के लिए विशेष रूप से तैयार की गई एक style guide है, इसलिए अगर agent review सफल रहा, तो guideline enforcement की समस्या भी मानो पहले ही हल हो चुकी थी
  • सही परिस्थितियों में agent review काम कर सकता है, लेकिन इसके लिए पर्याप्त रूप से designed rules और review methods पहले से होने चाहिए
  • यही मानसिक प्रयास Zig code के redesign और rules को मजबूत करने में भी लगाया जा सकता था, लेकिन Bun ने re-architecture के बजाय rewrite चुना
  • कई अप्रकाशित कारणों से rewrite सही चुनाव रहा हो सकता है, लेकिन मौजूदा सफाई से alternatives की तुलना पर्याप्त नहीं लगती

दस लाख लाइनों का rewrite और pointer code की तीन लाइनें

  • Bun का मानना है कि Zig में ownership expectations को type level पर दिखाने के लिए SharedPtr(TCPSocket) और deref() जैसे code जोड़ने पड़ते हैं, जिससे यह मौजूदा pointer usage की तुलना में कम सुविधाजनक हो जाता है
  • इस उदाहरण में interface boundary पर pointer passing को स्पष्ट करने के लिए लगभग तीन lines of code बढ़ती हैं
  • review करना कठिन, दस लाख लाइनों के AI-generated PR को स्वीकार करना, लेकिन pointer ownership को स्पष्ट करने वाली कुछ लाइनों को readability की समस्या कहकर ठुकराना, एक असंगत रुख दिखता है
  • Jarred Sumner ने कहा था कि कई महीनों तक इंसानों ने सीधे code टाइप नहीं किया
  • अगर code इंसानों के लिए नहीं है, तो SharedPtr wrapper के असुविधाजनक दिखने का तर्क कमजोर पड़ता है; और अगर code इंसानों के लिए है, तो readability, reviewability, और maintainability पर विचार जारी रहना चाहिए
  • AI कंपनियां यह मानने से हिचकती हैं कि code readability अब भी महत्वपूर्ण है, लेकिन इसे नकारना उस कथा से तो मेल खाता है कि software engineering खत्म हो रही है, जबकि maintenance की वास्तविकता से टकराता है
  • ऐसे benchmarks भी हैं जो दिखाते हैं कि coding agents डिफ़ॉल्ट रूप से maintainability को खराब कर सकते हैं

वही घटना यह दिखाती है कि ‘सिर्फ AI काफ़ी नहीं है’

  • Bun के बड़े पैमाने के agent rewrite ने तकनीकी सुधार के साथ-साथ Anthropic के “AI ही काफ़ी है” संदेश को बढ़ावा देने वाला व्यावसायिक काम भी किया
  • लेकिन उसी उदाहरण की बिल्कुल उलटी व्याख्या भी की जा सकती है
    • सिर्फ LLM काफ़ी नहीं थे, इसलिए उन्हें agent harness में लपेटा गया
    • सिर्फ AI से memory safety की गारंटी नहीं दी जा सकती, इसलिए Rust का borrow checker चुना गया
    • इंसानों को पढ़ना होता है, इसलिए pointer wrapper की readability को लेकर चिंता की गई
    • इंसानों को maintenance भी करना होता है, इसलिए पहले से परिचित code structure पर ज़ोर दिया गया
    • Project Bunsen ने hybrid approach के ज़रिए Zig version Bun में 50 bugs खोजे
    • open source maintainers AI slop से बन रहे बोझ, contributors के verification की समस्या, AI contributions के screening policy, generative AI policy के पुनर्गठन से निपट रहे हैं
  • इस धारणा के तहत कि agents द्वारा बनाई गई समस्याएँ भी और ज़्यादा agents से सुलझाई जा सकती हैं, बेहतर tools बनाने के बजाय tokens खरीदने और skills सीखने के बजाय SKILL.md जोड़ने का तरीका फैल रहा है
  • software teams की psychology को समझने के बजाय parallel agent sessions को Team कहना, मानवीय संगठन और automated execution sessions को आपस में गड्डमड्ड करना है

coding agents को अपनाना और engineering को छोड़ देना अलग बातें हैं

  • Anthropic का software engineering के अंत वाला अभियान, AI tools बनाने वालों और उन्हें इस्तेमाल करने वालों दोनों के लिए उलटा असर डाल सकता है
  • coding agents अपनाने पर भी, ऐसे Dark Software Factory को आदर्श मॉडल मानने की ज़रूरत नहीं है जहाँ इंसान code को समझते ही नहीं
  • लक्ष्य यह है कि लोग जो चाहते हैं वह बनाया जाए और वह सही तरह काम करे, जबकि AI bubble ऐसी चीज़ें कम गुणवत्ता में बनाने का दबाव डाल सकता है जिन्हें लोग चाहते ही नहीं
  • AI का उपयोग करते हुए भी निर्णय, सीखना, संवाद, readability, maintainability को छोड़े बिना आगे बढ़ने की दिशा चाहिए

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

2 टिप्पणियां

 
hmmhmmhm 1 분 전

Rust ज़िंदाबाद, बार-बार ज़िंदाबाद
 
GN⁺ 4 시간 전
Hacker News की रायें

  • इस लेख में अच्छी बातें बहुत हैं, लेकिन यह उन AI-जनरेटेड projects की याद दिलाता है जो कुछ ही महीनों में छोड़ दिए जाते हैं। किसी project की कीमत generated code की मात्रा से ज़्यादा इस बात में है कि उसका real-world validation कितना हुआ है, और mature मौजूदा code किसी नए rewrite से बेहतर होता है
    मौजूदा Zig codebase पहले ही validate हो चुका है, लेकिन Rust rewrite में tests pass करने के अलावा validation लगभग शून्य है; और अगर unsafe Rust में file-by-file सीधा translation किया गया है, तो यह भी स्पष्ट नहीं कि starting point Zig से बेहतर क्या है। आगे चलकर इसे safe Rust में ले जाकर production environment और बहुत-से users से validate करवाया जाए, तभी इसका मतलब बनेगा
    असल में Bun का fork हो गया है; Zig version बचे या Rust version, इससे फर्क नहीं पड़ता, और इसे Zig की suitability की समस्या मानने की भी कोई वजह नहीं है

    • AI projects तात्कालिक ढंग से generate किए जाते हैं, इसलिए छोड़ दिए जाते हैं। sunk cost उल्टा मुश्किलों और सुस्ती के दौर को झेलने में फायदा हो सकता है, लेकिन किसी क्षणिक idea और Claude prompt से बने output से लगाव नहीं बनता
      मुझ जैसा सामान्य programmer भी रोज़ दर्जनों शानदार ideas सोचता है, लेकिन review झेल पाने वाले बहुत कम होते हैं, और कुछ दिन बाद वे भी मेहनत के लायक नहीं लगते। Ideas पहले भी सस्ते थे, अब proof of concept भी सस्ता हो गया है, इसलिए ऐसे Show HN में रुचि नहीं होती जिसमें एक महीना भी निवेश नहीं किया गया
    • काफी real-world validation से गुज़रे safe Rust तक पहुँचना है तो कहीं से शुरू करना होगा, इसलिए पहले सीधा translation करके फिर धीरे-धीरे सुधारने का फैसला किया गया
      Zig camp को शायद चिंता है कि Zig शुरुआत से ही बेकार भाषा है, क्योंकि C की तुलना में उसके पास serious use के लिए पर्याप्त फायदे नहीं हैं और उसका flagship project भी छोड़कर चला गया। Zig issue tracker में segfault खोजकर देखें तो Rust जैसे alternatives के सामने उसके future utility पर शक क्यों होता है, समझ आ जाएगा
    • Zig के उलट, अब स्पष्ट और सीमित scope वाली unsafe boundary है, और इसे एक-एक करके ठीक किया जा सकता है—यह बेहतर है
    • लेख की शुरुआत जरूरत से ज़्यादा cynical है। Anthropic और OpenAI में मेरे परिचितों को देखकर लगता है कि वे सचमुच मानते हैं कि निकट भविष्य में agents programming का अधिकांश काम संभाल लेंगे और वे खुद भी jobs खो देंगे
      वे anti-AI camp को सीख देने के लिए messaging manage नहीं कर रहे
    • AI-generated projects जल्दी छोड़ दिए जाते हैं, इसकी वजह real-world validation की कमी ही है, ऐसा पक्का नहीं कहा जा सकता। सामान्य personal projects भी अक्सर कुछ समय बाद छोड़ दिए जाते हैं, और code बहुत तेज़ी से लिख पाना शायद personal utility, learning और enjoyment की diminishing marginal utility के point तक जल्दी पहुँचा देता है

  • Andrew ने सीधे-सीधे बात कही, यह अपने-आप में उतनी बड़ी बात नहीं; बड़ी समस्या यह है कि लेख साफ़ तौर पर personal attack है, फिर भी दावा करता है कि ऐसा नहीं है—यह दोहरा रवैया है
    इसे पढ़कर Zig में कुछ बनाने की इच्छा खत्म हो गई। आप कोई भी technical decision लें, Zig का आजीवन benevolent dictator for life (BDFL) ऐसा लेख लिख सकता है; Python या Rust जैसी दूसरी communities की leadership को इस तरह बर्ताव करते हुए imagine करना मुश्किल है

    • इससे भी गंभीर बात यह है कि ऐसा रवैया Zig community में फैलने के संकेत दिख रहे हैं। अभी यह बहुमत न भी हो, अगर अच्छे लोग ज्यादा warm communities में चले जाएँ, तो बचे हुए group में ऐसी प्रवृत्ति का अनुपात बढ़ेगा
    • Andrew सही चीज़ को सच में महत्व देते हैं, इसलिए उनके मजबूत विचार हैं; लेकिन मैं उनका बचाव करना चाहूँगा कि वे दूर से judge करने की तुलना में ज्यादा धैर्यवान और inclusive व्यक्ति हैं
      कोई Andrew को Bun पर हमला करते हुए देख सकता है, और मैं Andrew के खिलाफ reactions को personal attacks मान सकता हूँ। अगर preconceived notions हटा दें, तो या तो दोनों पक्षों को गलत मानना होगा या किसी को भी नहीं; और दूर से स्थिति judge करते समय व्यक्तिगत bias का असर बहुत ज्यादा होता है, इसे ध्यान में रखना चाहिए
    • जाते समय Zig को खराब दिखाने वाला misleading लेख न लिखें, और Zig Foundation के साथ तय meeting में बिना बताए absent न रहें, तो सब ठीक रहेगा
    • Andrew का लेख कई बार edit हुआ है, इसलिए latest revision पढ़ने से चिंताएँ दूर हो सकती हैं: https://github.com/andrewrk/andrewkelley.me/commits/master/p...
    • Rust में design के स्तर पर BDFL नहीं है, और मेरी याद में Python भी इस model से आगे बढ़ चुका है। कोई individual contributor गुस्से में aggressive post लिख सकता है, लेकिन Zig की तरह language को represent करने वाला कोई single person नहीं है

  • मैं Andrew के पक्ष में खड़ा होना चाहूँगा। Sumner के काम को कई सालों से देखते हुए, Kelley की आलोचना भले ही अनkind हो, लेकिन काफी हद तक सच है; output useful और शानदार हो तो भी यह शुरू से अंत तक self-promotion के लिए influence operation जैसा था
    मैं खुद भी दिन में 8 घंटे agent-based development करता हूँ और team को Node की जगह Rust और Deno इस्तेमाल करने की सलाह देता आया हूँ, लेकिन इस rewrite की justification कमजोर थी और यह Dario वगैरह की सफल long PR campaign का extension लगता है। अगर wording ज्यादा सभ्य होती तो इसे अच्छी तरह लिया जाता, लेकिन PR team से ghostwritten लेख के बजाय ईमानदार विचार रखने की बात की मैं कद्र करता हूँ

    • इस हंगामे से मिली सीख यह है कि तीखा reply publish करने से पहले उसे 1–2 दिन रोककर करीबी दोस्त को दिखाना चाहिए। Andrew ने बाद में जो सुधरा हुआ conclusion दिया, वैसा पहले revision से ही देना बेहतर होता
    • rewrite की prior justification कमजोर थी, लेकिन Jarred क्यों परेशान था, यह examples के बिना भी समझ आ गया
      JavaScript garbage collector के साथ interaction से Bun में खास तरह की मुश्किलें पैदा होती हैं—यह explanation उपयोगी था, लेकिन Andrew ने इसे बिल्कुल address नहीं किया। यह explanation भी कि नए code को मौजूदा test suite से validate किया गया, उस गलतफहमी को दूर करता है कि tests तक vibe coding से translate किए गए होंगे और भरोसेमंद नहीं होंगे। Tests हर bug नहीं पकड़ते—यह बात Zig समेत सभी software पर लागू होती है
      आखिरकार यह memory-unsafe languages भारी defect costs पैदा करती हैं वाले नज़रिए और “skill बढ़ाओ ताकि bugs न लिखो” वाली प्रतिक्रिया का टकराव था; इसमें AI debate, Anthropic की involvement और Andrew की Linus-style भाषा जुड़कर मामला फैल गया
    • company के बाहर किसी को rewrite justify करना जरूरी है—ऐसा mindset ही अजीब है
    • technical मामलों में PR copy की जगह Linus की तरह सीधी और साफ़ बात करने वाला attitude बेहतर है; PR-style wording non-technical customers के लिए रखनी चाहिए

  • मुझे संदेह है कि क्या Anthropic और Andrew Kelley के लेख को उसी तरह पढ़ा गया है। Anthropic कोई programming language बेचने वाली कंपनी नहीं है, और Bun के Rust में rewrite वाले लेख में ऐसे बहुत से technical details थे जो दिखाते थे कि product end users के लिए कैसे बेहतर हुआ
    दूसरी ओर Zig की प्रतिक्रिया व्यक्तिगत हमलों से भरे तीखे column जैसी लगती है। मैं Codex इस्तेमाल करता हूँ और Zig या Rust, किसी में भी मेरा कोई stake नहीं है, इसलिए बाहर से देख रहा हूँ

    • Anthropic का भी साफ तौर पर programming language market में stake है। अगर AI किसी खास language में rewrite करना आसान बना दे, तो success stories उस language और AI company को जोड़ती हैं, और AI से लिखने में आसान Rust की सफलता Anthropic के लिए भी फायदेमंद है
      साथ ही, किसी सफल rewrite को promote करते समय अक्सर story के लिए नुकसानदेह पहलू छिपा दिए जाते हैं, जैसे मौजूदा code कितना खराब था, और इस बार भी अहम पहलू गायब थे
      Andrew Kelley का लेख(https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) Jarred के कमज़ोर engineering standards, Zig Foundation के साथ meeting में बिना बताए न आना जैसे खराब external relations, Rust में transition के दौरान Zig को खराब choice के रूप में दिखाने से हुए नुकसान, और उससे ZSF के गुस्से पर बात करता है
      सतही तौर पर देखने पर चिंता हो सकती है कि language creator अपने पूर्व user पर हमला कर रहा है, लेकिन Kelley ने बताया कि सिर्फ Bun का लेख पढ़कर मुझे भी जो impression हुआ था, वह क्यों अनुचित था। कुछ व्यक्तिगत हमले साफ हैं, और बाद में जोड़े गए आखिरी section में भी इस पर बात है
    • कल्पना करें कि कोई studio Unity से Unreal पर switch करे और Unity मौजूदा code quality और working environment पर हमला करने वाला लेख निकाले; तब समझ आएगा कि Zig का प्रतिक्रिया देना अपने-आप में अजीब है
    • यह craftsmanship और industrialism का पुराना टकराव है। Andrew उस परंपरा से आते हैं जो चाहती है कि हर developer गर्व करने वाला craftsman हो
      Java, JavaScript, Python, C# ने ऐसे safety mechanisms दिए जिनसे perfectionist न होने वाले developers भी बड़ी दुर्घटनाओं के बिना काम कर सकें, और C++-centric industry पर कब्ज़ा किया। C और C++ का performance advantage बड़ा था, लेकिन वे लगातार अधिक hostile environment में काफी skill मांगते थे
      Rust और Swift ने garbage-collected languages की तुलना में अधिक predictable performance के साथ समान या उससे मजबूत safety दी, और Rust के ideas ने इस क्षेत्र में नई languages की बाढ़ ला दी। हालांकि उनमें से काफी, industrial needs से निकले Rust की तुलना में craftsmanship के अधिक करीब हैं
      कारों से तुलना करें तो Java और JavaScript वगैरह आम safety vehicles हैं, C/C++ दोपहिया motorcycles हैं, Rust तेज़ लेकिन सवारों की रक्षा करने वाली rally car है, और Zig चारपहिया ATV या open-wheel kart जैसा है। आसानी से फिसलता नहीं, लेकिन पलट जाए तो बहुत खतरनाक है
      समय और cost constraints को नज़रअंदाज़ करने वाले craftspeople मानते हैं कि बस सावधान developers चाहिए, लेकिन industry में अच्छा code लिख सकने के बावजूद 90% लोग constraints के भीतर काम करते हैं, इसलिए अपने code या दूसरे के code पर भरोसा करना मुश्किल है। Zig में कई खूबियाँ हैं, लेकिन शुरू से ही यह safety से ज्यादा hacking की freedom पसंद करने वाले लोगों के लिए language रही है
    • binary size और speed improvements का Rust rewrite से सीधे बहुत संबंध नहीं है, और Zig codebase पर इसी तरह की मेहनत की जाती तो शायद संभव था। rewrite को promote करने के लिए इन numbers को अच्छा दिखाने की खातिर extra work किया गया लगता है
      memory safety भी AI, tests, और higher-level fuzzing के बजाय अगर Zig team के सुझाए integrated fuzzer का उपयोग किया गया होता तो शायद इसी तरह हासिल की जा सकती थी। फिर भी Bun जैसे project के लिए अधिक mature Rust बेहतर choice हो सकता है
      Andrew का नजरिया यह समझने के लिए जरूरी था कि क्या हुआ। कुछ expressions नरम हो सकते थे, लेकिन अगर खराब management ही रिश्ते बिगड़ने और कमजोर engineering outcomes की direct वजह थी, तो इसे बताना व्यक्तिगत हमला नहीं बल्कि जरूरी context है
    • जो product programmers की productivity बढ़ाने के लिए उनकी जगह code लिखने का दावा करता है, उसे सिर्फ इसलिए language market से असंबंधित मानना कि वह अपनी language नहीं बेचता, दूरदर्शिता की कमी है
      खासकर Zig leadership ने vibe coding को खुले तौर पर नापसंद किया है और industry की आलोचना की है, और project उस product से बने contribution requests को reject कर रहा है

  • इस debate में असल technical substance की कमी है। मुझे Bun के Rust port, Andrew के aggressive लेख, या gold rush में shovels बेचने वाले Anthropic में interest नहीं; मैं concrete technical content देखना चाहता हूँ
    Jarred ने Rust transition के लिए जो कारण दिए वे evidence में कुछ कमजोर हों तो भी valid लगते हैं, लेकिन Andrew ने यह rebut नहीं किया कि वे असली problems क्यों नहीं हैं या Zig में उन्हें idiomatically कैसे solve किया जाए। खासकर चाहता हूँ कि Bun के actual Zig code के आधार पर arguments का analysis किया जाए

    • Bun की तरफ से बताए गए facts ही देखें तो rewrite की technical validity कमजोर है, और ज्यादातर मामलों में rewrite खराब engineering होता है, इसलिए यह हैरानी की बात नहीं
      Bun एक ऐसे व्यक्ति ने शुरू किया जिसके पास Zig का अनुभव कम था, जबकि scope और complexity बहुत बड़ी थी, और शुरुआत से ही यह दूसरी language के code को rewrite करने वाला project था। अगर esbuild के JavaScript/TypeScript transformer को Go से Zig में line-by-line port करने के बाद कुछ ही सालों में पूरे codebase को छोड़कर फिर किसी और language में rewrite कर दिया गया, तो सवाल है कि अब और क्या चर्चा करनी है
    • Andrew का मुख्य point यह है कि Bun code मूल रूप से खराब था, और यह भी संकेत मिलता है कि Jarred toxic व्यक्ति हैं, इसलिए इस debate में भाग लेने लायक भी नहीं
    • Bun तेज़ी से move करना और चीजें तोड़ना चाहता है, जबकि Zig धीरे और सावधानी से move करवाता है
      Bun shell language, SQLite/PostgreSQL client जैसी features जल्द से जल्द ship करना चाहता है, इसलिए memory management की चिंता खुद नहीं करना चाहता। Zig memory management और lifetimes को सीधे handle करवाता है और जानबूझकर Drop जैसी feature भी नहीं जोड़ता, लेकिन Rust Drop की वजह से बेहतर fit है
      जैसे Python से SQL database नहीं बनाते, वैसे ही Zig Bun के लिए सही tool नहीं है, और यह Zig में idiomatic तरीके से solve करने की चीज़ से ज्यादा Jarred के project को तेज़ी से आगे बढ़ाने के तरीके का फर्क है
    • original text इस issue को सीधे address करता है, लेकिन उसने लगभग सिर्फ अच्छे पहलू चुनकर रखे। उदाहरण के लिए build time सुधारने के लिए Zig compiler तक rewrite किया गया बताया गया है, तो आम तौर पर कहीं ज्यादा धीमे Rust build time की चर्चा बिल्कुल क्यों नहीं की गई?
    • gold rush में shovels बेचने वाले data centers और energy बनाने वाली कंपनियाँ हैं, और tokens ही gold हैं

  • Kelley के कुछ views से मैं सहमत हूँ, लेकिन समस्या tone है
    अगर Bun को Rust से Zig में rewrite किया गया होता, तो संभावना कम है कि Rust core team का कोई member Sumner को target करते हुए व्यक्तिगत हमलों वाला लेख लिखता और दावा करता कि यह हमला नहीं है। जैसे Kelley को अपनी पसंद का लेख लिखने की freedom है, वैसे ही लोगों को भी growing language के BDFL द्वारा बनाई गई Zig की public image पर react करने की freedom है

  • Bun के Rust में बदलाव वाले पोस्ट में विकल्पों की ठोस तुलना और प्रभाव के आँकड़े नहीं थे, और नतीजे को पक्षपाती ढंग से पेश किया गया, इसलिए वह इंजीनियरिंग ब्लॉग पोस्ट जैसा नहीं लगा
    लगता है लोग पोर्टिंग के तकनीकी आधार से ज़्यादा एजेंट के इस्तेमाल में रुचि दिखा रहे थे, और तकनीकी रूप से यह बहुत निराशाजनक था

    • संदेह है कि क्या हमने वही पोस्ट पढ़ी थी। किसी खास code की एक लाइन पर बात नहीं की गई थी, लेकिन उसमें गहरी architectural details, memory safety और bugs से जुड़े तर्क, और बड़े पैमाने के agent coding patterns बार-बार शामिल थे

  • हमें यह कम करके नहीं आंकना चाहिए कि management और executives पर marketing का प्रभाव कितना बड़ा होता है, खासकर CEO जैसे पदों पर पहुँचने वाले लोग कितनी छोटी-छोटी भावनाओं से प्रभावित हो सकते हैं
    नया Fable model promote करने का मौका होना और Zig का Anthropic products के इस्तेमाल का सार्वजनिक रूप से विरोध करना — सिर्फ ये बातें ही Bun को Rust में rewrite करने का फैसला लगभग तय कर चुकी हो सकती थीं

    • यह समझ नहीं आता कि किसी भी रूप में management के दखल का अनुमान लगाने की वजह क्या है। यह कहीं ज़्यादा संभव लगता है कि Jarred ने वही किया जो वह खुद करना चाहता था, और वह खुद भी ऐसा कहता रहा है

  • भाषा बदलने की बहस में काम के घंटों की अपेक्षाओं तक बात क्यों लाई जा रही है, समझ नहीं आता। भले ही वह खराब manager हो, ऐसा लगता है जैसे जबरन नकारात्मक मुद्दे खोजे जा रहे हों
    यह भी अर्थपूर्ण है कि Zig पक्ष rewrite के तकनीकी फायदों पर लगभग ध्यान नहीं दे रहा। Anthropic ने कई सुधारों का दावा किया, लेकिन उनका खंडन करने की कोशिश तक मुश्किल से दिखती है
    अगर मेरे project को किसी large language model से rewrite करने पर बिना किसी नुकसान के सुधार निकल आए, तो मैं काफी चिंतित होकर जवाब देता; लेकिन यहाँ तो अलग ही दिशा में काम के घंटों पर चर्चा हो रही है

  • Anthropic के स्वामित्व वाले project और AI-generated code का सार्वजनिक रूप से विरोध करने वाले language community leadership के बीच स्पष्ट conflict of interest है
    Andrew Kelley को बस यह बात कहकर रुक जाना बेहतर होता, और Bun founder की energy और motivations पर आकलन जोड़ने से लगभग कोई मूल्य नहीं जुड़ता

    • AI के कट्टर समर्थक और कट्टर विरोधी — दोनों पक्षों के लिए समझौता करना मुश्किल है। अधिकांश technical arguments और attacks बाद में दी गई rationalizations हैं; बस हर organization का context और goals अलग होते हैं
      Kelley को भी यह पता था, लेकिन लगता है वह मुख्य बात को धुंधला करने के प्रलोभन से बच नहीं पाए। तीखा लेख ([0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) हद से आगे चला गया था, लेकिन आगे बढ़ने की बात वाला appendix स्वस्थ है। मेरे हिसाब से BDFL का बहुत फीका होने के बजाय थोड़ा मसालेदार होना बेहतर है