Bun के Rust में दोबारा लिखे जाने पर मेरे विचार
(andrewkelley.me)- Zig के निर्माता Andrew Kelley Bun के Rust rewrite को भाषा फीचर्स की हार-जीत से ज्यादा Zig Software Foundation (ZSF) और Bun/Oven के बीच रिश्ते के टूटने को दिखाने वाली घटना मानते हैं
- शुरुआती Bun ने Zig को अपनी performance उपलब्धियों का आधार माना और ZSF को सालाना करीब $60,000 दान किया, लेकिन VC-backed startup बनने के बाद संगठन संचालन और code quality को लेकर असंतोष बढ़ा
- ZSF को Bun codebase में hacky implementations, assertions का जरूरत से ज्यादा इस्तेमाल, और तेज़ी से features जोड़ने की तुलना में bugs व technical debt साफ करने की कमी को लेकर चिंता थी; साथ ही Bun का Zig के representative example की तरह दिखना भी बोझ माना गया
- Kelley का कहना है कि Bun का Rust migration वाला लेख bug reduction को style guide vs language features के फ्रेम में रखता है; उनके हिसाब से असली मुद्दा bugs हटाने में लगाया गया engineering time और code quality management है
- ZSF Bun के donation के लिए आभारी है, लेकिन Anthropic acquisition के बाद donation और रिश्ता खत्म हो गया; Rust rewrite के चलते Zig और Bun के business interests अलग हो जाना वह सकारात्मक मानता है
Bun और Zig का शुरुआती रिश्ता
- Jarred करीब 5 साल पहले Zig community में शामिल हुए, और Kelley ने उन्हें तेज़ी से कोशिश करने और बहुत कुछ सीखने वाली मजबूत “beginner energy” वाला व्यक्ति माना
- Bun जब JavaScript toolchain के तौर पर ध्यान खींचने लगा, तो Zig में भी ज्यादा रुचि आने लगी
- Kelley का मानना है कि Jarred सिर्फ crowdfunding से भी San Francisco के हिसाब से स्थिर income बना सकते थे, लेकिन उन्होंने Thiel Fellowship जैसी सोच और Silicon Valley-style approach अपनाकर venture capital चुना
- शुरुआती Bun, Zig project के लिए supportive था
- Bun website पर performance उपलब्धियों के लिए Zig को credit दिया गया
- Zig Software Foundation को सालाना $60,000 के स्तर का monthly donation सेट किया गया
- Bun के Rust rewrite वाले लेख में भी Zig project के प्रति आभार genuine लगता है, ऐसा वे आकलन करते हैं
VC-backed startup बनने के बाद दरार
- Bun के VC-backed startup बनने के बाद Jarred, community के साथ open source बढ़ाने वाले developer से ज्यादा business operator जैसे हो गए
- Oven के hiring message में शुरुआती करीब 9 महीनों तक intense workload की बात थी, और कहा गया था कि अगर work-life balance का मतलब “काम न करने का बहुत समय” है, तो यह fit नहीं हो सकता
- Kelley कहते हैं कि Oven के interview candidates और employees से बात करते हुए उन्होंने Jarred की manager भूमिका को लेकर बार-बार negative बातें सुनीं
- जिन समस्याओं का जिक्र हुआ, वे थीं communication की कमी, unrealistic expectations, कम empathy, और experience की कमी
- नतीजतन, Zig में काम करना चाहने वाले community members Oven और Bun से दूर रहने लगे
- Jarred जितना productivity और startup exit strategy पर केंद्रित हुए, उतना ही Kelley के Zig के long-term vision से दूर होते गए
- उदाहरण के लिए, Jarred ने Language Server Protocol implementation और VSCode integration को प्राथमिकता देने की मांग की, लेकिन Kelley के पास इससे बड़ी योजना थी
ZSF की नजर में Bun की code quality समस्याएं
- Kelley के अनुसार मुख्य समस्या code quality है
- Zig team user projects का source code पढ़ती है, देखती है कि language changes users को कैसे प्रभावित करते हैं, और बदलावों से होने वाले breakage व performance regressions को test करती है
- Bun codebase में ZSF को चिंतित करने वाली programming practices बढ़ीं
- hacky implementations लगातार जमा होते गए
- assertion का अत्यधिक इस्तेमाल था
- तेज़ी से features जोड़ने की तुलना में reflection, bug removal और technical debt घटाने के लिए कम समय था
- Kelley को चिंता थी कि Bun का यह तरीका Zig पर होने वाली memory safety criticism से जुड़ सकता है, और वे Zig project से social distance रखना चाहते थे
- ZSF ने Bun को बेहतर programming practices की तरफ ले जाने की कोशिश की, लेकिन असर नहीं हुआ
Anthropic acquisition और Rust rewrite
- ZSF के अंदर यह धारणा बनने लगी कि Bun लगभग net liability है
- Bun Zig के representative example जैसा दिखता था, लेकिन असल में वह “Zig code ऐसे नहीं लिखना चाहिए” के example के ज्यादा करीब था — यह बात बोझ बन रही थी
- Kelley को Bun का “cloud से जुड़ी कोई चीज़ बेचने” वाला business plan शुरू से कमजोर लगा, और उनका मानना था कि अगर कभी sale हुआ तो Zig को भी अप्रत्यक्ष रूप से negative publicity मिल सकती है
- Anthropic acquisition के बाद ZSF ने राहत महसूस की
- donation चुपचाप बंद हो गया, और ZSF को इसकी उम्मीद थी
- Bun पक्ष ने monthly meeting न तो cancel की, न attend की, और रिश्ते को खत्म मान लिया गया
- ZSF को शक था कि कुछ ही दिनों में Rust rewrite आएगा, और उसने इसका समर्थन किया
- Anthropic acquisition के बाद सिर्फ इस indirect connection से कि Claude Bun से और Bun Zig से लिखा गया है, Zig community पर बोझ बढ़ा
- drive-by slop contributions बढ़े
- LLM output को forum posts में paste करने वाले AI enthusiasts आने लगे
- Kelley को चिंता हुई कि Zig AI से जुड़ी programming language के तौर पर जानी जाएगी
- Jarred ने जब Rust rewrite की घोषणा की, तो Kelley ने इसका बहुत स्वागत किया और “अब यह मेरी समस्या नहीं है” वाली भावना जताई
Bun के Rust rewrite लेख पर प्रतिवाद
- Kelley Bun के Rust rewrite लेख को अच्छी तरह लिखा हुआ मानते हैं, लेकिन कुछ key issues बताते हैं
-
bug reduction का core
- Bun का लेख ऐसा फ्रेम बनाता है जैसे bugs से बचने के लिए style guide और programming language features में से एक चुनना हो
- Kelley के लिए bugs हटाने का मुख्य तरीका engineering resources लगाकर bugs ढूंढना और खत्म करना है
- उनके अनुसार TigerBeetle ने bugs ढूंढने और हटाने में समय लगाया और ZSF के साथ healthy relationship बनाए रखा, लेकिन Bun ने दोनों नहीं किया
-
test suite को लेकर contradiction
- Kelley के अनुसार Bun का लेख 10 लाख lines के unreviewed code को deploy कर सकने की वजह के तौर पर पर्याप्त test suite होने की बात करता है
- Kelley सवाल करते हैं कि अगर ऐसा है, तो Zig code में इतने irritating bugs क्यों थे; क्या test suite Zig code के bugs नहीं पकड़ सकता लेकिन 10 लाख lines के unreviewed code के bugs पकड़ सकता है
-
performance और LTO
- Bun का लेख performance improvement का credit LTO को देता है, लेकिन Kelley कहते हैं कि Zig ने Bun के पूरे समय के दौरान LTO support किया था
- Zig ने पहले LTO को default enabled रखा था, लेकिन LLVM bugs बहुत ज्यादा होने की वजह से default से हटा दिया, और वे bugs Rust को भी प्रभावित करते हैं
- Kelley का मानना है कि ZSF ने शायद LTO enable करने की सलाह दी होगी और Bun ने नहीं सुना होगा
-
fuzzing
- Bun का लेख इशारा करता है कि Zig code पर ईमानदारी से fuzzing की गई, लेकिन Kelley कहते हैं कि एक call में Bun team ने कहा था कि वे कुछ भी fuzz नहीं करते
-
binary size और
comptime- Bun का लेख binary size घटाने के लिए कई engineering tasks को Rust rewrite के आधार की तरह पेश करता है, लेकिन Kelley का मानना है कि ये tasks rewrite से संबंधित नहीं हैं
- ये काम शुरुआत से ही Zig codebase में किए जाने वाले engineering tasks के करीब हैं
- ZSF ने कई सालों तक Bun को
comptimeके अत्यधिक इस्तेमाल को लेकर चेताया, औरcomptime/inlineusage व compile time audit करने के लिए time report feature भी बनाया
-
compile speed
- Kelley बताते हैं कि Bun लेख ने compile speed का जिक्र नहीं किया
- Zig compiler project करीब 600,000 lines का है, जो rewrite से पहले Bun के समान scale का है
- Kelley की measurement में clean cache से scratch build करने में 16 seconds, और incremental compilation enable करने के बाद हर बाद की edit में 90ms लगते हैं
- वे पूछते हैं कि Rust rewrite के बाद Bun के equivalent measurements क्या हैं
Kelley का निष्कर्ष
- Kelley के लिए core issue programming language features नहीं, बल्कि relationship breakdown है
- ZSF Bun से मिले donations के लिए ईमानदारी से आभारी है, और उसने उस पैसे का उपयोग Zig contributors compensation में किया
- Kelley साफ करते हैं कि वे Jarred पर personal malice के साथ criticism नहीं करना चाहते
- Jarred की पसंद और life goals उनसे अलग हैं, लेकिन उन्होंने अपनी चाही हुई जिंदगी सफलतापूर्वक बनाई है
- वे मानते हैं कि Jarred खुश और सफल हैं, और वे उनके प्रति कोई द्वेष नहीं रखते
- हालांकि Kelley इस बात से खुश हैं कि ZSF और Bun के business interests अब आपस में उलझे नहीं हैं
- जब Rust rewrite के अच्छे-बुरे को language choice के आधार पर लेकर public debate खत्म हो जाएगी, तो दोनों पक्षों की interaction भी खत्म हो जाएगी
2 टिप्पणियां
लेख पढ़कर लगता है कि अब zig और bun, दोनों में से कोई भी इस्तेमाल करने का मन नहीं हो रहा।
Hacker News की रायें
Andrew का कोड पढ़कर मैंने वाकई बहुत कुछ सीखा, और जैसा मूल लेख में भी कहा गया है, Zig के बिना Bun भी नहीं होता
“लेख में दावा किया गया है कि Zig कोड की fuzzing की गई, लेकिन कॉल के दौरान पूरी Bun टीम ने कहा कि वे कुछ भी fuzz नहीं करते। यह साफ़ तौर पर मनगढ़ंत लगता है” वाले हिस्से के बारे में Fuzzilli integration PR मौजूद है: https://github.com/oven-sh/bun/pull/24826
Fuzzilli ने Bun के Zig कोड में जो समस्याएँ खोजीं, उन्हें ठीक करने वाले merge PR भी हैं: https://github.com/oven-sh/bun/pull/28926, https://github.com/oven-sh/bun/pull/28934, https://github.com/oven-sh/bun/pull/29255, https://github.com/oven-sh/bun/pull/29210, https://github.com/oven-sh/bun/pull/29199
“Fuzzilli” खोजने पर और PR मिलते हैं: https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...
zig build test --fuzz, यानी Zig के built-in fuzzer की बात कर रहे थे, और उनके दायरे में आने वाला tool वही हैमैं दोनों में से किसी की पूजा नहीं करता; बस पूरी बातचीत बेहतर दिशा में जाने के बजाय बिगड़ती दिख रही है, इसलिए जिज्ञासा है
fact-checking वाला सवाल पूछने पर downvote मिलना काफ़ी अर्थपूर्ण है। जवाब इतना आसान भी हो सकता है कि “हाल तक fuzzer इस्तेमाल नहीं हो रहा था, इसलिए दोनों सही हैं”, लेकिन मैं नहीं जानता, इसलिए पूछ रहा हूँ
यह लेख Zig के लिए गैर-पेशेवर और शर्मनाक बात है
Jarred के बारे में मुझे लगभग कुछ नहीं पता, लेकिन कल पढ़ा उसका लेख Zig के प्रति आभार जताने जैसा था, और अब देखकर पता चला कि उसने Zig को अच्छी-खासी रकम donate भी की है
यह पूरा लेख सिर्फ़ इसलिए उस पर सार्वजनिक और निजी तौर पर हमला कर रहा है क्योंकि उसने कोई दूसरा product चुना
अगर Andrew सोचते हैं कि यह लेख Zig का पक्ष स्पष्ट करेगा, तो यह अजीब है; असल में यह उसे बचकाना ही दिखाता है। या शायद वे बस Jarred पर हमला करना चाहते हों
क्या हर किसी को चलते-फिरते brand बनकर हमेशा अपनी बातों को filter करना चाहिए, पतली बर्फ़ पर चलना चाहिए, और “professional” दिखने के लिए corporate भाषा के पीछे छिपना चाहिए?
आज दुनिया को कम ईमानदार discourse नहीं, बल्कि ज़्यादा ईमानदार discourse चाहिए, और online interactions लगातार कम authentic होती लगती हैं
Zig व्यवहार में लगभग एक-व्यक्ति project जैसा है, और वह एक व्यक्ति लगातार अधिक अस्थिर फैसले ले रहा है
बेशक यह उसका project है, इसलिए उसका अधिकार है, लेकिन लगभग trillion-dollar valuation वाली company इस तरह का supply chain risk नहीं लेना चाहेगी
Anthropic के नज़रिए से, Zig ecosystem में और निवेश करने के बजाय, not-so-BDFL के सीमा पार करने का जोखिम दिखते ही शुरुआत में ही उसे रोक देना बेहतर है
दूसरी ओर Zig में adoption scale और development अवधि को देखते हुए test coverage शर्मनाक रूप से कम है
AI को लेकर Zig का रवैया पूरी तरह बचकाना है। बहुत बड़ा फायदा मिल सकता है, फिर भी किसी भी उपयोग की संभावना पर विचार नहीं करता
PR spam रोकना अलग बात है, और अपने हाथ-पैर बाँधकर internally भी सबसे आसान और high-utility क्षेत्रों में AI का बिल्कुल उपयोग न करना अलग
AI से PR spam में मौजूद असली bug candidates को छाँटा भी जा सकता है, लेकिन कोई मदद न लेने के कारण असली bugs ज़रूरत से ज़्यादा लंबे समय तक पड़े रहते हैं
दुर्भाग्य से बहुत से open source developers इस तरह लिखने में बहुत सहज हैं, और यह मेरे open source activity छोड़ने के कारणों में से एक है
किसी समझदार workplace में ऐसा व्यवहार करने पर व्यक्ति को नौकरी से निकाला जाएगा या कम से कम अनुशासनात्मक कार्रवाई होगी
“Jarred की कोई निजी आलोचना नहीं है” — यह वाक्य लेख के अंत में कहना काफी तीखा लगता है, जबकि लगभग पूरा लेख हल्के-से ढके हुए निजी हमले जैसा दिखता है
किसी के बारे में कहना कि उसमें beginner energy है और उसे “असफल होकर सीखने वाला व्यक्ति” जैसे नकली सकारात्मक लहजे में पैक करना, या यह लिखना कि अफवाहों के मुताबिक उसे “smelly manager” कहा जाता है
यह कुछ ऐसा है जैसे, “मैं यह नहीं कह रहा कि वह बुरा है, लेकिन मुझे ब्लॉग पर लिखना होगा कि सब लोग मानते हैं कि यह व्यक्ति बुरा है”; सच भी हो तो यह बहुत खराब स्वाद का लगता है
मैं भी खराब managers के साथ काम करता हूँ, लेकिन व्यक्तिगत तौर पर उनसे द्वेष नहीं रखता
“अफवाहों की बेल बड़ी और स्वस्थ थी, रसदार अंगूरों से भरी हुई, और उन सभी अंगूरों का रस एक ही संदेश लिए था: Jarred एक smelly manager था”
“Jarred LLM इस्तेमाल करने से पहले ही कचरे जैसा लिख रहा था”
लेख अजीब तरह से बचकाना है। मुझे ऐसे लेख पसंद हैं जो corporate filter से गुज़रे बिना मन की बात कहते हैं, लेकिन ऐसे लेख यह भी दिखाते हैं कि वह व्यक्ति कैसे सोचता और चलता है
अच्छी leadership में corporate filter हटाने पर भी नतीजा पेशेवर रहता है; यह लेख उससे कहीं कमतर कुछ दिखाता है
जब यह सुरक्षित हो और कोई आप पर निर्भर न हो, तो यह पूरी तरह सामान्य है। management के काम से अलग है
यह हिस्सा प्रभावशाली लगा कि Anthropic acquisition पूरा होते ही ZSF ने राहत की सांस ली। मतलब, जब donation चुपचाप बंद हो गया तब भी खाता तैयार था, और जब उसने monthly meeting रद्द भी नहीं की और आया भी नहीं, तब भी वे चौंके नहीं। रिश्ता खत्म हो चुका था
ऐसी चीज़ें कई बार देखी हैं। जब कोई project या organization acquire हो जाता है, तो उनके किए जा रहे “अच्छे काम” शोर-शराबे से बंद नहीं होते; sponsor चुपचाप उन्हें ignore करना शुरू कर देता है और वे बस गायब हो जाते हैं
अच्छा हुआ कि उन्होंने संकेत पढ़े और तैयारी की। यह एक बेहतरीन सीख है जिसे खुद कठिन तरीके से सीखने की ज़रूरत नहीं है, और एक-दो बड़े donors पर निर्भर free/open source projects को सावधान रहना चाहिए
लगता है developer tools ecosystem में आगे ऐसी चीज़ें बहुत ज़्यादा देखने को मिलेंगी
इस thread में कहीं और लेख के tone पर तीखी प्रतिक्रियाएँ हैं, लेकिन इस लेख से Zig को लेकर मेरी उम्मीद कम हो गई
drama मज़ेदार है और Andrew की ईमानदारी शायद सम्मान के लायक हो, लेकिन गंभीर project के लिए जिस professionalism की ज़रूरत होती है, वह यह नहीं है
भले ही वह boring और inspiration-less लगे, tech stack और उसके operations में मुझे वही स्थिरता चाहिए
Jarred शुद्ध नुकसान रहा हो सकता है, लेकिन Bun Zig इस्तेमाल करने वाला बहुत बड़ा project था, और उस project का चले जाना Zig के लिए उतना अच्छा नहीं है जितना Andrew कहता है
वह भाषा की growth से कहीं ज़्यादा purity और ideology को प्राथमिकता देता दिखता है। एक गंभीर programming language के लिए adoption और critical mass भी महत्वपूर्ण factors हैं
यह कहने जैसा है कि Linus के email tone की वजह से Linux serious project नहीं बन सकता था
वह भी सीधे तौर पर नहीं लिखा, बल्कि personal blog में लिखा गया लेख है
महत्वपूर्ण बात यह नहीं है कि उसने भाषा में क्या योगदान दिया है?
adoption और critical mass आखिर अनिवार्य रूप से महत्वपूर्ण क्यों हैं? अगर कोई व्यापक adoption छोड़कर अपनी चाही हुई purity और ideology के हिसाब से भाषा बनाना चाहता है, तो इसमें गलत क्या है?
हर चीज़ को user growth और awareness के लिए optimize क्यों होना चाहिए?
भले ही वे ऐसा दिखाएँ
यह लेख बहुत refreshing था। Bun लेख की PR-style phrasing का और polished जवाब देने का बड़ा temptation रहा होगा, लेकिन उन्होंने ऐसा नहीं किया
वे Jarred को negative दिखाने वाले facts डाल सकते थे और अपनी राय सावधानी से छिपा सकते थे, जैसे “मैंने सुना है लोग उसे smelly manager कहते हैं। मैं नहीं कह रहा, दूसरे लोग कहते हैं” — लेकिन वे बस ईमानदार रहे, यह अच्छा लगा
हालांकि उस personality और thoughts की सामग्री काफी मुश्किल से स्वीकार्य है
लेख का पहला और सबसे बड़ा हिस्सा speculative ad hominem को देने की वजह से, लेखक की बात पर भरोसा करना मुश्किल है
Zig के merits को summarize करने का अच्छा मौका था। mitchellh के evangelism और प्रेरणादायक posts की वजह से हाल में Zig सीखने का मन हुआ था, लेकिन इस लेख ने Zig सीखने की इच्छा ठंडी कर दी
Andrew, Jarred और उसके काम करने के तरीके/काम के attitude को कैसे देखता है, इस पर काफी बातें दिखती हैं, लेकिन क्या personal attack है और क्या speculative है या नहीं, यह साफ नहीं दिखता
Jarred पर निजी हमले से Zig इस्तेमाल करने की दलील को खास मदद मिलती नहीं दिखती
ध्यान भाषा पर होना चाहिए था; “बदबूदार maintainer” जैसे शब्द नहीं लिखने चाहिए थे
सच कहूं तो यह लेख पढ़कर Jarred जितना ही Andrew से भी बचने का मन करता है
पिछले कुछ महीनों में समुदाय के कई लोगों ने भी यह देखा है
“Jarred ने अपनी पेशेवर भूमिका में हमारे समुदाय के कई लोगों को दूर कर दिया, और हम दूरी बनाना चाहते हैं” कहना “Jarred निजी तौर पर बुरा इंसान है” नहीं है
बेशक इस क्षेत्र में, VC लोगों ने काम के बाहर की निजी जिंदगी कितनी छोड़ी होगी, यह सोचें तो इसे लगभग वही अर्थ माना जा सकता है, लेकिन यह Andrew की समस्या नहीं है
मैं Andrew की लेखन-शैली का बचाव नहीं कर रहा। ज्यादा व्यापक neurotypical पाठकों से बात करते समय वह अपनी neurodiversity को थोड़ा और छिपा सकता था
फिर भी यह उसका project है, और उसका community पहले से इन traits को जानता है; यह भी एक known variable है
“Andrew Jarred के चरित्र की हत्या करने की कोशिश कर रहा है” जैसा अतिरिक्त उप-अर्थ जोड़े बिना, Andrew पूरी तरह ईमानदार है यह मानकर इसे फिर से पढ़ना मददगार हो सकता है
यह पहली बार नहीं है जब मैंने कोई पोस्ट देखी हो जो साफ तौर पर दुर्भावनापूर्ण लगी। इसे नरम शब्दों में “सीधा-सपाट” कहने लायक बात नहीं है
“क्या चुप रहना विकल्प नहीं था?”
“Jarred पर कोई निजी आलोचना नहीं है” कहने के उलट, पूरा लेख Jarred पर निजी आलोचना जैसा लगा
भले ही यह सच हो, इसे इस रूप में सार्वजनिक करना समझदारी नहीं है। अगर लक्ष्य Zig का बचाव करना था, तो कम निजी तरीके से भी किया जा सकता था
Bun को Zig से Rust में फिर से लिखने का यह पूरा काम एक बड़ा marketing move जैसा दिखता है
अगर Anthropic AI सचमुच इतना शक्तिशाली है, तो उसे bugs ठीक करने और मौजूदा Bun Zig codebase को redesign करने का ज्यादा महत्वाकांक्षी काम क्यों नहीं सौंपा जाता, ताकि न सिर्फ मौजूदा bugs बल्कि आगे वैसे bugs पैदा होने से भी रोका जा सके?
इससे Anthropic की भावनाएं आहत हुईं
मैं कल्पना कर सकता हूं कि Anthropic ऐसे gimmick के बिना भी Bun को acquire करना चाहता होगा
कुछ हफ्ते बाद Bun ने Rust rewrite शुरू किया। साफ तौर पर कहा नहीं गया, लेकिन मुझे लगता है कि दोनों घटनाएं जुड़ी हो सकती हैं
इनमें से कौन सा ज्यादा बुरा है, मुझे नहीं पता