आपके योगदान का स्वागत करने वाला D भाषा fork, OpenD

• मौजूदा D नेतृत्व के जरिए योगदान लंबे समय से अटका हुआ था—इस नाराजगी के जमा होने के बाद कुछ contributors OpenD नाम के D भाषा fork की ओर चले गए
• मुद्दा यह नहीं है कि D closed source है या नहीं; बल्कि यह है कि GPL रिलीज और gdc जारी होने के बाद भी development process और decision-making समुदाय के लिए पर्याप्त रूप से खुले नहीं थे
• Ares/Tango का बाद में druntime में बदलना, Phobos activity में कमी, PRs का अनदेखा रहना, और “D gripes and wishes” के बाद execution की कमी—इन सबको fork के आधार के तौर पर पेश किया गया
• OpenD में जाने के बाद upstream D के लिए PRs, bug reports, user support, DLF meetings और DConf Online में भागीदारी बंद कर दी गई; dpldocs.info तब तक maintained रहेगा जब तक लागत कवर होती रहेगी
• जिन मौजूदा D libraries और applications के लिए paid support contract नहीं है, उन्हें upstream D compatibility की guarantee नहीं मिलेगी; long-term support का रास्ता OpenD में भागीदारी की ओर शिफ्ट हो गया है

---

OpenD में जाने की वजह

• OpenD D भाषा का fork है, और इसकी शुरुआत इस समझ से हुई कि मौजूदा D leadership के जरिए upstream में contribution करने की प्रक्रिया लंबे समय से बेहद निराशाजनक रही है
• यह बार-बार कहा जाना कि D एक closed source language है, सही नहीं है
  • compiler के D-specific हिस्से 2002 में GPL के तहत जारी किए गए थे
  • पूरा GPL compiler, gdc, 2004 में जारी हुआ था
• हालांकि D की development methodology पर्याप्त रूप से open नहीं थी, और decision-making में community से meaningful input बहुत कम था—ऐसी आलोचना जारी रही
• D की core features और concepts, और मौजूदा D code का बड़ा हिस्सा community input और काम से आया है, लेकिन केवल accepted cases को देखने पर survivorship bias हो सकता है

योगदान की पुरानी bottleneck और Ares/Tango का मामला

• D के इतिहास में accepted patches भी बहुत रहे हैं, लेकिन लंबे समय तक छोड़े गए patches भी बहुत थे
• आज जिसे druntime के रूप में जाना जाता है, वह code उस fork से शुरू हुआ था जो इसलिए बना क्योंकि Walter community contributions स्वीकार नहीं कर रहे थे
  • 2004 में upstream के साथ collaborate करने की कोशिश कर रहे developers ने अपने contributions खोने से बचाने के लिए D को fork किया
  • इस fork को शुरुआत में Ares कहा गया, और बाद में यह दूसरी community efforts के साथ मिलकर Tango बना
• Tango ने खुद को “The Developer's Library for D” कहा, और यह ऐसी जगह बना जहां developers के contributions का वास्तव में स्वागत होता था
  • Tango ecosystem में कई चीजें थीं जो Phobos ecosystem में नहीं थीं
• fork चार साल तक maintained रहा और लोकप्रिय हुआ, उसके बाद upstream ने समझौते की कोशिश की, और वही धारा आज के druntime तक पहुंची
• इसके पीछे यह आकलन है कि अगर Ares/Tango fork नहीं होता, तो D बाजार में meaningful position हासिल नहीं कर पाता, और इसी fork ने D को संकट से बचाया

golden age के बाद घटती भागीदारी

• Tango के core developers के लौटने और Andrei Alexandrescu जैसे लोगों के जुड़ने का दौर D development के अपेक्षाकृत खुले होने का समय था, और 2013 के आसपास activity बढ़ने वाली golden age के रूप में वर्णित है
• यह भी रेखांकित किया गया कि लगभग सभी commercial D users सीधे Ares fork से आए code पर निर्भर थे
• लेकिन पुरानी आदतें खत्म नहीं हुईं, और golden age के कई contributors community में नहीं रहे
  • कुछ लोग साफ तौर पर इसलिए चले गए क्योंकि उन्हें लगा कि उनके काम को महत्व नहीं देने वाली broken process है
  • कुछ अन्य लोगों की activity निजी कारणों से कम हुई, और नए contributors पर्याप्त रूप से टिके नहीं
• Phobos development activity 2018 के मध्य में बहुत कम हो गई, और उसके बाद activity में दो छोटी बढ़ोतरी हुईं
  • berni44 द्वारा CTFE-capable floating-point formatting जोड़ना
  • Paul Backus के sumtype module को std.sumtype के रूप में स्वीकार किया जाना
• berni44 ने 2020 में PR review के लिए लगभग 3 महीने इंतजार करने के बाद community छोड़ने की बात कही, और एक साल बाद लौटकर हालिया Phobos development activity में बढ़ोतरी लाई, लेकिन कुछ महीनों बाद फिर चले गए
• dmd में भी Walter का व्यक्तिगत contribution volume मोटे तौर पर स्थिर है, लेकिन दूसरों के कम होने से उनका proportion golden age के लगभग 1/6 से अब लगभग 1/3 हो गया है

बार-बार grievances जमा करना और execution की कमी

• 2022 के Christmas के आसपास Mike Parker ने लोगों से “D gripes and wishes” list भेजने को कहा
• कई लोगों को लगा कि इसका कोई नतीजा नहीं निकलेगा, लेकिन responses बहुत आए
• करीब 6 महीने बाद, 18 मई 2023 को responses को इकट्ठा करने वाला public document प्रकाशित किया गया
• इसके बाद publicly confirmed result अगले goals तय करने तक सीमित रहा
  • language, compiler और standard library को stabilize करना
  • tools और third-party library support सहित ecosystem improvement
  • website cleanup, पुराने documents और tutorials update करना, website redesign आदि community strengthening
• अनुरोध था कि “general बात न लिखें, specific लिखें”, लेकिन कई specific complaints का जवाब बड़े categories वाले goal bullets तक सीमित रहा
• 2016H1 Vision Document में भी participation बढ़ाने, tools, language stability और specification improvements, libraries जोड़ने जैसे समान goals थे, इसलिए रुख यह है कि goal-setting से ज्यादा execution की जरूरत है

OpenD में shift से क्या बदलेगा

• upstream D में योगदान की कोशिशें बंद की जाएंगी, और पूरे compiler को target करने वाले fork OpenD में जाया जाएगा
• dpldocs.info documentation hosting की लागत Patreon से मुश्किल से कवर हो रही है, और जब तक लागत बनी रहती है, dub package support सहित इसे चलाया जाता रहेगा
  • upstream D updates नहीं लिए जाएंगे
  • माना जा रहा है कि existing features शायद ठीक से काम करते रहेंगे
• blog में upstream D-specific support वाला हिस्सा बंद हो जाएगा
  • statistics अब शामिल नहीं होंगे
  • नाम “This Week in ARSD” हो जाएगा, और बाद में “This Week in OpenD” हो सकता है
• upstream D के लिए PRs और bug reports तुरंत बंद हो जाएंगे
  • जो चीजें खुद के लिए उपयोगी होंगी, उन्हें upstream में भेजने के बजाय OpenD में merge किया जाएगा
• D user support भी बंद हो जाएगा
  • पहले अलग-अलग skill level वाले D users को हर हफ्ते कई घंटे support दिया जाता था, लेकिन अब upstream D questions के जवाब की guarantee नहीं होगी
  • अगर जवाब दिया गया, तो संभवतः OpenD try करने को कहा जाएगा
• governance changes को precondition मानने पर सहमति न हो, तो DLF meetings में भाग नहीं लिया जाएगा
• DConf Online livestream का invitation आए तो भी उसे ठुकराया जाएगा
• D libraries के लिए, केवल उन targets पर internal versions और external compiler updates के बीच compatibility promise बनाए रखा जाएगा जिनके पास paid support contract है
  • बाकी users के लिए upstream D compatibility तुरंत cancel हो जाती है
  • code जैसा है वैसा ही दिया जाता है, बिना किसी explicit या implied warranty के
  • OpenD fork में शामिल होने पर उन libraries का support जारी रहेगा
• D applications के लिए भी libraries की तरह upstream D compatibility promise नहीं है, और वे मूल रूप से खुद के उपयोग के लिए design की गई थीं, इसलिए compatibility guarantee और भी ढीली है

बाकी रुख

• बताया गया कि पिछले 16 वर्षों में D पर बहुत समय लगाया गया, और programming career का अधिकांश हिस्सा D और उससे पहले Digital Mars C++ की वजह से बना
• Walter Bright और उनके साथियों ने जीवन पर बड़ा असर डाला, और Walter को programming language project का शानदार contributor माना गया
• फिर भी अब Walter Bright के D को छोड़कर OpenD नाम का अलग रास्ता चुना जा रहा है
• OpenD को सफल बनाने के लिए बहुत काम करना होगा और असफल होने की संभावना भी बहुत ज्यादा है, लेकिन अब failure की जिम्मेदारी सिर्फ OpenD वालों की ही होगी

[GN⁺]

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

• कम से कम Walter और शायद अन्य D नेतृत्व के लोग भी यहाँ सक्रिय हैं, इसलिए संभावना है कि वे ये टिप्पणियाँ देखेंगे
  बस इतना याद रखना चाहिए कि वे भी इंसान हैं, D की सच में परवाह करते हैं, और मेरे अनुभव में मूलतः अच्छे लोग हैं जो अपनी तरफ़ से पूरी कोशिश करना चाहते हैं

  • 20 साल से ज़्यादा हो गए, लेकिन असल में लगभग कुछ भी नहीं बदला
    अब यह क्यों अलग होगा, समझ नहीं आता, और यह Tango भाग 2 जैसा दोहराव लगता है
    फ़र्क सिर्फ़ इतना है कि अब तक तो जहाज़ बहुत पहले ही निकल चुका है
  • यह बात सही है और मैं मानता हूँ कि सब इंसान हैं, लेकिन यहाँ D की परवाह करने वाला सिर्फ़ Walter नहीं है
    अगर किसी दूसरे नेतृत्व में यह प्रोजेक्ट बेहतर चल सकता है, तो उस संभावना पर विचार होना चाहिए
    मैं सच में चाहता हूँ कि D फिर से जीवित हो जाए; यह अब तक मेरी सबसे पसंदीदा भाषा रही है
    यह Walter या किसी और पर हमला नहीं है, बस उन लोगों की कोशिश है जो अपनी पसंदीदा चीज़ को बचाना चाहते हैं

• दुर्भाग्य से, ऐसा होना लगभग तय ही था। कई सालों से D fork की बात बहुत बार उठती रही है
  2010 में Andrei Alexandrescu की किताब आने के समय D में जो लगभग सारी अच्छी चीज़ें थीं, वे C#, Java, C++ में पहुँच गईं
  उनका implementation D जितना साफ़-सुथरा न हो, फिर भी अगर बेहतर tools और library ecosystem के भीतर उन्हें किसी न किसी रूप में इस्तेमाल किया जा सकता है, तो वह फ़र्क इतना मायने नहीं रखता
  लोगों को आकर्षित करने वाले किसी golden feature के पीछे बहुत समय बर्बाद हुआ, और उन features को स्थिर भी नहीं किया जा सका
  Andrei भी आजकल D से ज़्यादा C++ और CUDA में व्यस्त दिखते हैं
  पिछले 10 वर्षों में native compile होने वाली programming languages का पुनर्जागरण भी हुआ, जिससे प्रतिस्पर्धा और कड़ी हो गई
  इसलिए और अफ़सोस होता है, क्योंकि समुदाय में खुद बहुत अच्छे लोग हैं जिनसे बात करना सुखद है

  • अगर इससे भाषा फिर जीवित हो जाए और अब तक का काम नष्ट न हो, तो मैं इसे अच्छी बात ही मानूँगा
    मैं रोज़ Python इस्तेमाल करता हूँ, लेकिन D की कई चीज़ें याद आती हैं
    performance की तो बात ही अलग है

• एक बाहरी व्यक्ति के तौर पर D को देखते हुए मैंने कुछ ऐसा ही देखा था
  जब Rust नया था, तब lifetime की अवधारणा D समुदाय में प्रस्तावित की गई थी, लेकिन Walter ने उसे अनावश्यक माना
  कुछ साल बाद Walter Rust से काफ़ी अलग अपना lifetime प्रस्ताव लेकर आए, इसलिए वह समुदाय के पहले के प्रस्तावों की तुलना में कम परखा हुआ भी था
  अब D में मेरी दिलचस्पी नहीं रही, इसलिए नहीं जानता कि नया lifetime feature कितना परिपक्व है, लेकिन अगर वह Rust जितना उपयोगी है तो मुझे हैरानी होगी

  • मैं Rust या D के lifetime approach से बहुत गहराई से परिचित नहीं हूँ, लेकिन फ़ोरम को जल्दी से देखने पर लगा कि D में Rust-style lifetime लाने के लिए भाषा के design में बड़ा बदलाव करना पड़ता
    किसी भी feature के साथ दूसरी language features के interaction, cognitive burden, compilation speed में गिरावट, standard library design की जटिलता, और backward compatibility टूटने जैसे trade-off आते हैं
    सिर्फ़ दूसरी भाषा के किसी पसंदीदा feature को support करने के लिए इतने बड़े बदलाव की उम्मीद करना मुझे तर्कसंगत नहीं लगता
  • अब कम से कम ऐसा प्रोजेक्ट तो हो सकता है जिसमें Walter की राय की जगह किसी और की राय शामिल हो

• मेरा research group कुछ साल पहले response की कमी और language development की ख़राब दिशा के कारण D छोड़कर Rust पर चला गया था
  मैं Adam और बाकी लोगों की OpenD के साथ सफलता की कामना करता हूँ, लेकिन अच्छा होता अगर वे इस मौके पर कोई ज़्यादा अनोखा और याद रहने वाला नाम चुनते

• नया governance model इस तरह शुरू नहीं होता कि पहले नई features की सूची घोषित कर दी जाए या कहा जाए कि कुछ features हटा दिए जाएँगे, बल्कि इस तरह शुरू होता है कि संबंधित पक्षों की एक quorum के साथ governance पर चर्चा हो
  यह model change नहीं, सिर्फ़ सत्ता परिवर्तन है
  शिकायतें जायज़ हो सकती हैं, और D का Walter पर gatekeeper की तरह निर्भर रहना कुछ लोगों को ज़रूरत से ज़्यादा सख़्त लग सकता है
  लेकिन जिस तरह यह fork शुरू किया गया है, वह लंबी अवधि के लिए अच्छा संकेत नहीं है
  fork को सफल होने के लिए व्यापक समर्थन चाहिए, और अंततः सिर्फ़ कुछ बहुत सक्रिय contributors नहीं, बल्कि D community के लगभग बहुमत को साथ लाना होगा
  नहीं तो fork भी असफल हो सकता है, और मूल प्रोजेक्ट में बची हुई रुचि भी और बिखर जाएगी, जिससे उसकी बची-खुची viability भी खत्म हो सकती है
  साथ ही, दशकों तक support देने की क्षमता और इच्छा भी चाहिए

• लगता है एक update आया है: https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h... और शायद इसे कुछ ध्यान भी मिला है
  व्यक्तिगत रूप से मुझे लगता है कि इसका नाम Died रखा जाता तो ज़्यादा मज़ेदार होता
  “It never Died” जैसी बढ़िया tagline भी बन सकती थी, fork होने की बात भी साफ़ हो जाती, और बाद में ज़रूरत पड़ने पर भाषा को नई दिशा में ले जाने की गुंजाइश भी रहती
  OpenD से पूरी compatibility जैसी छाप पड़ती है
  बेशक, मेरा इसमें कोई सीधा हित नहीं है, और मैं इसके सफल होने की कामना करता हूँ

• D फ़ोरम में इस विषय पर एक बड़ा thread है: https://forum.dlang.org/thread/[e-mail]...

  • यहाँ जिस बड़े thread की ओर इशारा किया गया है, वह fork को आगे बढ़ाने वाले लोगों का है; अभी तक यह 2 लोगों द्वारा शुरू की गई पहल लगती है, और ऊपर की पोस्ट में जो कमी है, वह D पक्ष की विस्तृत प्रतिक्रिया यहाँ काफ़ी मिलती है
    मूल पोस्ट का ज़ोर लोगों के बीच के टकराव की शिकायतों पर है, लेकिन इस लिंक में तकनीकी चर्चा कहीं ज़्यादा है
    इसे पढ़कर लगता है कि fork करने वाले लोग असल में एक अलग भाषा चाहते हैं, और इसके लिए कई compatibility-breaking changes स्वीकार करने को भी तैयार हैं

• व्यक्तिगत रूप से मुझे यह उलझन होती है कि अगर D पूरी तरह garbage collector पर फोकस करता है, तो वह किस niche market को निशाना बना रहा है
  पहले भी उसका कोई खास स्पष्ट niche नहीं था। मूल रूप से वह “10% बेहतर C++” था, और उसमें ऐसा कोई killer feature नहीं था जो उसे साफ तौर पर अलग खड़ा करे, इसलिए उसे आगे बढ़ाना मुश्किल था
  ज़्यादातर लोग मौजूदा support, codebase और industry base की वजह से C++ पर ही टिके रहेंगे, या नए प्रोजेक्ट्स के लिए Rust चुनेंगे, या अगर सादगी चाहिए तो Zig लेंगे
  खासकर C++20 के बाद तो मानो “10% बेहतर C++” पहले से ही मौजूद है
  और यह भी नहीं लगता कि garbage collector पर फोकस करना बहुत मददगार होगा
  तब उसे C# और Java से प्रतिस्पर्धा करनी होगी, और ये दोनों शुरू से ही garbage collection वाले, safe और संक्षिप्त C++ successors के तौर पर बनाए गए थे, इसलिए इस समय इनके साथ कैसे प्रतिस्पर्धा करेगा यह साफ नहीं दिखता
  खासकर C# में raw pointers, reference types/value types पर नियंत्रण, memory layout control जैसे काफ़ी अच्छे low-level और unsafe features हैं, और एक पुरानी object-oriented first language होने के बावजूद इसका type system और reflection भी ठीक-ठाक है, साथ ही यह लगातार ML family features भी अपना रही है
  सच कहूँ तो D का vision हमेशा उलझा हुआ लगा है
  मैंने BetterC, safe mode, lifetimes जैसे कुछ खास language feature documents पढ़े हैं, लेकिन वे syntax के स्तर पर पढ़ने में कठिन थे, और उनमें विवरण बहुत था पर कुल मिलाकर बात अच्छी तरह समझाई नहीं गई थी
  मुझे भाषा के किसी सुसंगत design vision या उद्देश्य का एहसास नहीं हुआ
  लेखक ने इस समस्या का ज़िक्र तो किया है, लेकिन उनका vision भी कोई ज़्यादा स्पष्ट नहीं लगता
  यह अच्छा है कि कुछ ठोस मध्यम-अवधि के तकनीकी लक्ष्य हैं, लेकिन यह साफ नहीं है कि वे लक्ष्य आखिर किस लिए मौजूद हैं
  मैं Rust programmer हूँ, इसलिए नए personal projects में क्या इस्तेमाल करूँगा यह तो तय है, लेकिन अगर कुछ और चुनना पड़े तो मैं OCaml, C++, यहाँ तक कि C# को भी प्राथमिकता दूँगा

  • लंबे समय तक D को बेहतर C++ के रूप में प्रचारित किया गया, लेकिन वह दो कारणों से गलत था
    पहला, D भले C++ का विकल्प हो, लेकिन वह C++ नहीं है, और कई C++ developers इस अंतर से निराश हुए
    दूसरा, D सिर्फ C++ replacement से कहीं ज़्यादा काम कर सकता है
    इसे scripting, general-purpose programming language के रूप में, और खास तौर पर ImportC तथा BetterC जैसी C interoperability के लिए इस्तेमाल किया जा सकता है
    fork के लक्ष्यों में से एक यह है कि garbage collector के बारे में अब और सफ़ाई न दी जाए
    standard library में अभी भी reference counting, unique pointer वगैरह मौजूद हैं
    अगर कोई garbage collector से बचने वाले functions का योगदान देना चाहे, तो मुझे लगता है कि उसे स्वीकार किया जाएगा
    बस इस fork में यह संभावना कम है कि Adam standard library में नए functions जोड़ते समय garbage collector से बचने के लिए हद से ज़्यादा मेहनत करते दिखें
    उनका मानना है कि garbage collector का डर बढ़ा-चढ़ाकर पेश किया जाता है

• पिछले 10 वर्षों में programming language governance के बारे में सीखने को बहुत कुछ मिला है
  उभरती हुई और बदलाव के दौर से गुजर रही भाषाओं को देखें तो उन्होंने भी governance से जुड़े बड़े टकराव या गलतियाँ झेली हैं
  अब मुझे लगता है कि programming language को देखते समय governance ही सबसे अहम चीज़ है
  यह देखना चाहिए कि वे अपने संचालन के तरीके के बारे में क्या कहते हैं, व्यवहार में क्या करते हैं, अब तक नतीजे कैसे रहे हैं, और आगे क्या होने की संभावना है

  • मैं मानता हूँ कि यह महत्वपूर्ण मुद्दा है, लेकिन मुझे नहीं लगता कि इसका कोई संतोषजनक जवाब है
    programming language का विकास लगभग complexity management जैसा है, और साथ ही कई stakeholders की ज़रूरतों के बीच संतुलन भी बनाना पड़ता है
    लगभग हर governance conflict तब पैदा हुआ जब एक stakeholder group ने दूसरे group के लिए अनिवार्य requirements पर आपत्ति जताई, और दोनों पक्षों को हमेशा संतुष्ट करना संभव नहीं होता
    Rust का async इसका जाना-माना उदाहरण है, जो काम तो करता है, लेकिन कुल मिलाकर संतोषजनक न लगने वाले design को समझाता है
    Go एक दुर्लभ अपवाद है, क्योंकि core team पर सभी stakeholders का सम्मान करने की कोई खास मजबूरी नहीं थी, और उनके पास ऐसा करने के लिए पर्याप्त संसाधन और इच्छाशक्ति भी थी, फिर भी कुछ टकराव हुए
  • स्थिति बेहतर नहीं हुई है
    1960~80 के दशक का standards-writing model कहीं बेहतर था, और उसने राजनीतिक लड़ाइयों को भी कम अवधि तक सीमित रखा

• कई compiler implementations होने में क्या नकारात्मक पक्ष है, यह मुझे समझ नहीं आता
  व्यक्तिगत रूप से मुझे लगता है कि यही C के इतने व्यापक रूप से फैलने का मुख्य कारण है
  compilers अलग-अलग दिशाओं में खोजबीन कर सकते हैं, और जिन language extensions का मूल्य साबित हो जाता है वे अंततः दूसरी implementations में भी अपनाए जाते हैं, और कभी-कभी committee consensus की प्रक्रिया में ज़्यादा बिगड़े बिना standard में भी शामिल हो जाते हैं

  • मैं उलझन में हूँ, क्योंकि क्या पहले से ही लगभग 3 नहीं थे?
    कम से कम मुझे लगा था कि gcc और dlang वाली implementations मिलाकर 2 तो हैं ही