Russ Cox, Go तकनीकी लीड की भूमिका से हटे

• Go प्रोजेक्ट 12 साल से अधिक समय तक Russ Cox-केंद्रित leadership से Austin Clements और Cherry Mui-केंद्रित नए ढांचे में transition कर रहा है
• 1 सितंबर 2024 से Austin, Google Go टीम और पूरे Go प्रोजेक्ट के technical leader होंगे, और Cherry compiler, runtime और releases सहित Go core को lead करेंगी
• Cox का मानना है कि लंबी अवधि की single leadership stability देती है, लेकिन नए leaders के grow करने की जगह कम कर सकती है; वे Python के 2018 leadership transition को सकारात्मक precedent मानते हैं
• Cox Go नहीं छोड़ रहे हैं; वे design discussions, CL reviews, issue filing, कुछ standard library work, GoLab talk आदि में individual contributor के रूप में बने रहेंगे
• आगे वे Gaby और Oscar पर ज्यादा focus करेंगे, ताकि Go issue tracker की productivity बढ़े और open source maintainers के लिए मददगार तरीकों को दूसरे projects तक फैलाया जा सके

---

Go leadership transition

• 1 सितंबर 2024 से Austin Clements Go के technical leader की भूमिका संभालेंगे
  • इसका scope Google की Go team और पूरा Go project, दोनों हैं
  • Austin अभी “Go core” कहलाने वाले area के technical leader हैं
• Cherry Mui Go core area को lead करने की भूमिका में आगे बढ़ेंगी
  • Go core में compiler toolchain, runtime और releases शामिल हैं
• Russ Cox Go project नहीं छोड़ रहे हैं, लेकिन decision-making के केंद्र से एक कदम पीछे हट रहे हैं

12 साल की leadership के बाद बदलाव की जरूरत क्यों है

• Cox के लिए technical leader कोई honorary position नहीं, बल्कि service role के ज्यादा करीब है
  • उन्होंने 12 साल से अधिक समय तक Go project को lead करते हुए इस बात पर focus किया कि contributors अच्छा काम कर सकें, इसके लिए सही conditions बनें
• बड़े projects को stable leadership का फायदा मिलता है, लेकिन किसी point पर नए leaders की strengths और fresh perspective भी जरूरी होते हैं
• Cox का मानना है कि Go ने 12 साल से अधिक की single leadership के जरिए पर्याप्त stability बना ली है
• वे BDFL model को व्यक्ति और project, दोनों के लिए healthy नहीं मानते
  • नए leaders के लिए जगह बनाना मुश्किल होता है
  • यह single point of failure बन जाता है
  • project के और grow करने की गुंजाइश कम हो जाती है
• Python का उदाहरण दिया गया है, जिसे 2018 में Guido van Rossum के हटकर दूसरों को lead करने देने से काफी फायदा हुआ

Austin Clements और Cherry Mui पर भरोसा

• Austin 2014 से और Cherry 2016 से Google में Go पर काम कर रहे हैं
• Cox दोनों की judgment और Go तथा जिन systems पर Go चलता है, उनके बारे में knowledge को शानदार मानते हैं
• general design questions या compiler, linker, runtime details को और गहराई से समझने की जरूरत पड़ने पर वे Austin और Cherry पर निर्भर रहे हैं
• मौजूदा leaders भी अपने-अपने areas को lead करते रहेंगे
  • Roland Shoemaker Go security को lead करते रहेंगे
  • Rob Findley और Hana Kim Go tools और IDE support को lead करते रहेंगे

Russ Cox आगे क्या भूमिका निभाएंगे

• Cox consciously decision-making से पीछे हटेंगे ताकि Austin और अन्य leaders के आगे आने की जगह बने
• Go के अंदर वे individual contributor के रूप में बने रहेंगे
  • Go design discussions में भागीदारी
  • CL reviews
  • पुराने history-related questions के जवाब
  • जरूरत पड़ने पर support
  • issues file करना और CLs लिखना
  • कुछ संभावित नए standard library work
  • industry में Go advocacy
  • नवंबर में Italy के GoLab में Go-related talk
• transition की details अभी तय नहीं हुई हैं और public discussion के लिए mailing list पर share की गई हैं
• Cox और Austin चाहते हैं कि यह बदलाव Go project को और strong और better बनाने के अलावा किसी बड़े incident जैसा न लगे

Gaby और Oscar की ओर focus shift

• Cox आगे Gaby and Oscar पर अधिक focus करेंगे
• लक्ष्य Go issue tracker में useful contributions बनाकर Go workers को अधिक productive ढंग से काम करने में मदद करना है
• Oscar पर काम के जरिए वे open source maintainers के लिए मददगार तरीके खोजना चाहते हैं और उम्मीद करते हैं कि दूसरे projects भी उन्हें अपनाएंगे
• Oscar के high-level goals तीन हैं
  • कुछ useful बनाना
  • कुछ नया सीखना
  • दूसरे projects के लिए रास्ता बनाना
• ये goals उन broader goals से जुड़े हैं जिन्हें Go में हमेशा pursue किया गया है, इसलिए Oscar Cox के लिए natural next step लगता है

Community reactions और transparency की मांग

• Daniel Martí ने पिछले 10 सालों में Go के बड़े changes और milestones के रूप में modules और generics का उल्लेख करते हुए कहा कि Cox ने long-term success में key role निभाया
• उन्होंने transition discussion के साथ-साथ compiler और runtime से जुड़ी transparency बढ़ाने के उपाय सुझाए
  • compiler and runtime meeting notes thread फिर शुरू करना
  • compiler and runtime office hours calls फिर शुरू करना
  • तुलना में कहा कि tools team Slack और regular golang-tools calls के जरिए community के साथ transparently communicate कर रही है
• Cherry Mui ने जवाब दिया कि meeting notes और office hours, Google की compiler/runtime team और community के बीच transparency और participation बढ़ाने का अच्छा मौका हैं
  • अगला office hours schedule तय होने पर mailing list में update post किया जाएगा
• कई participants ने Cox की 12 साल की leadership और Go में उनके contributions के लिए धन्यवाद दिया, और Austin व Cherry की नई roles के लिए बधाई दी

[GN⁺]

Hacker News की रायें

• rsc, अब तक किए गए सभी कामों के लिए धन्यवाद। पिछले 12 वर्षों में Go development race condition detector, standardized error wrapping, modules, generics, toolchain updates वगैरह की वजह से कहीं ज़्यादा सुखद हो गया है
  अभी भी कुछ इच्छाएँ बाकी हैं। व्यक्तिगत रूप से sum types, बेहतर enum/range types, immutability, non-nilness मेरी wishlist में हैं, फिर भी Go अब तक जिन ecosystems में मैंने development किया है, उनमें सबसे enjoyable में से एक है

  • RSC का सबसे बड़ा technical contribution मैं module versioning को मानूँगा। यह language ecosystem के लिए बिल्कुल बुनियादी चीज़ है
    https://research.swtch.com/vgo-intro
  • non-nilness देखकर मुझे अब भी यह thread याद आता है
    https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
  • यह हाल के वर्षों में Go को बेहतर language बनाने वाली चीज़ों की अच्छी तरह संकलित सूची है। इसमें मैं iterators भी जोड़ना चाहूँगा, जिन्हें Russ ने हाल में काफ़ी ज़ोर से आगे बढ़ाया
  • अगर Go में शुरुआत से ही nullable types या sum types होते, तो लगता है यह कहीं ज़्यादा popular होता
  • पारंपरिक 3-clause for loop के semantics change को भी नहीं भूलना चाहिए: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
    इस बदलाव की वजह से, Go 1.22 को मैं वास्तव में Go 1 compatibility को गंभीर रूप से तोड़ने वाला पहला Go version मानता हूँ, भले ही Go की आधिकारिक टीम इसे स्वीकार न करे

• निजी तौर पर Go मुझे अब तक के सबसे अच्छे से managed open source projects में से एक लगता है। इसे support करने के लिए Google को भी सम्मान

  • उत्सुकता है कि किसी project को अच्छी तरह managed मानने के कारक क्या हैं
  • व्यवहार में Go की “ownership” किसके पास है, यह जानने की उत्सुकता है
    सिद्धांत रूप में शायद कोई independent organization या committee जैसी चीज़ होगी, लेकिन असल में काम करने वाले ज़्यादातर लोगों का खर्च कौन उठाता है? Google?
  • लगता है Go, C++ या Java को replace करने के mission में fail हुआ और side effect के तौर पर API side में Ruby/Python आदि को replace करने वाली language बन गया
    इसलिए project goals अब world domination नहीं, बल्कि users से match होने लगे, और वह लड़ाई Rust, Zig आदि ने ले ली
  • सिर्फ glibc behavior support करना और ELF standard को मनमाने ढंग से ignore करना ही तो “सबसे अच्छे से managed” project की योग्यता होगी। /s

• “मैं नहीं मानता कि BDFL (benevolent dictator for life) model किसी व्यक्ति या project के लिए healthy है” वाला हिस्सा दिलचस्प है। सबसे अच्छे projects में BDFL होता है, और सबसे अच्छे BDFL अपनी power को लेकर skeptical लगते हैं

  • leadership में रुचि न रखने वाले capable लोग अक्सर सबसे अच्छे leaders बन जाते हैं
    इसके उलट जो लोग “leader” के रूप में जाने जाने की इच्छा से leader बनना चाहते हैं, उनमें कभी-कभी न क्षमता होती है न जिम्मेदारी
  • शुरुआत के पूरे हिस्से से सहमत हूँ या नहीं, यह अलग बात है, लेकिन सबसे अच्छे BDFL का अपनी power को लेकर skeptical होना इतना surprising नहीं है
    मेरे हिसाब से एक व्यक्ति के पास unilateral decision लेने की power का मुख्य फायदा यह है कि कई stakeholders होने पर पैदा होने वाले deadlock को bypass किया जा सकता है। अगर किसी project में leader को strong consensus वाले decisions को भी जायज़ तौर पर पलटने का अधिकार महसूस होता हो, तो लोगों को जानने लायक community बनना कहीं ज़्यादा मुश्किल होगा
  • मुझे नहीं लगता यह बात सही है। Python में BDFL था, लेकिन लगता नहीं कि उसे बड़ा फायदा मिला। यह रवैया किन दूसरे projects से आया है, यह भी ठीक से समझ नहीं आता
    मोटे तौर पर देखें तो यह drama कम कर सकता है, लेकिन quality को noticeable तरीके से नहीं बढ़ाता—दूसरी bureaucracies जैसा ही दिखता है। दूसरी ओर ऐसे projects की भरमार है जो single owner के पर्याप्त flexible न होने के कारण fail हुए, लेकिन उन्हें चर्चा लायक नहीं माना जाता
  • power पाने लायक लोग सिर्फ वे हैं जो power नहीं चाहते
    यह बात open source projects से बहुत आगे तक जाती है
  • BDFL का idea अपने-आप में joke है, और नाम में भी दिखता है
    GvR ने Python creator के रूप में जो “ground reality” निभाई थी, उसे मान्यता देने वाला expression था; यह project management principle के रूप में गंभीरता से intended नहीं था। यह prescription नहीं, description था, लेकिन यह concept जरूरत से ज़्यादा reify हो गया

• rsc, इस language पर किए गए सारे effort के लिए सच में धन्यवाद, जिसने मुझे software engineering में खींचा
  मैंने कई programming languages आज़माई हैं, लेकिन Go अब भी घर जैसा लगता है। developer experience शानदार है, और मैं सच में सराहता हूँ कि language और उसके creators ने simplicity और जिम्मेदारी को बिना बहाने के बनाए रखा। आगे जो भी करें, उसके लिए शुभकामनाएँ और अच्छे परिणाम मिलें

  • आपका स्वागत है। इस comment के लिए भी धन्यवाद
    जब हमने Go शुरू किया था, तब बिल्कुल अंदाज़ा नहीं था कि Go लोगों की ज़िंदगी पर इतना positive असर डालेगा और नए लोगों को programming और software engineering की ओर लाएगा। वही impact वह हिस्सा है जिस पर मुझे सबसे ज़्यादा गर्व है

• RSC का blog बहुत अच्छा है: https://research.swtch.com/

  • अब जाकर पहली बार ध्यान आया कि rsc उस blog का acronym हो सकता है
  • कमाल का blog है। पहले भी इस site पर कहा है, उनकी regular expression series की quality अविश्वसनीय रूप से ऊँची है, और उसे सबके देखने के लिए बस यूँ ही उपलब्ध करा देना बड़ा privilege है

• Go में सभी contributions के लिए धन्यवाद
  हालांकि Go से असंबंधित एक बात से सहमत नहीं हूँ। GvR के हटने के बाद Python को फायदा नहीं हुआ। नई “leadership” non-technical और oppressive है, और उसने ज़्यादातर असली open source contributors को दूर कर दिया
  development कुछ questionable-quality corporate contributions को छोड़कर stagnant है, माहौल oppressive है, और मायने बस इस बात का है कि क्या आप Microsoft/Instagram/Bloomberg में power वाली position में हैं। ज़रूरी नहीं कि यह इन कंपनियों की गलती हो। हो सकता है उन्हें पता न हो कि उनकी generosity का misuse हो रहा है

  • “development stagnant है” कहने के समर्थन में कोई data है क्या, यह जानना चाहूँगा
    GitHub stats देखें तो activity healthy दिखती है। पिछले एक महीने में 120 से अधिक contributors से 700 से अधिक PRs merge हुए [1]
    हाल के वर्षों में नए contributors भी काफी बढ़े हुए लगते हैं [2]
    [1] https://github.com/python/cpython/pulse/monthly
    [2] https://github.com/python/cpython/graphs/contributors

• सिर्फ gofmt ने ही शायद दुनिया भर में जबरदस्त समय बचाया होगा। असल में इसी ने लगभग हर दूसरी language ecosystem को “ठीक है, बस auto-format कर देते हैं” कहने की दिशा दी
  auto-formatter मेरे code के साथ जो करता है, वह मुझे पसंद नहीं, लेकिन whitespace पर अब बात नहीं करनी पड़ती, यह अच्छा है

  • दिलचस्प बात है कि बाकी सभी languages में मैं auto-formatters को नापसंद करता हूँ और tabs की जगह spaces इस्तेमाल करता हूँ, लेकिन Go में शुरुआत से ही gofmt जिस तरह code format करता है, उसकी आदत पड़ गई
    फिर आप appreciate करने लगते हैं कि अब उस पर बहुत समय नहीं लगाना पड़ता, और कम से कम ज़्यादातर लोगों के लिए यह problem नहीं रहता

• आज पता चला कि वह जिस project पर focus करना चाहते हैं: https://go.googlesource.com/oscar/+/refs/heads/master/README...
  open source projects maintain करने में मदद करने वाला LLM-based architecture बताया गया है। अच्छा लग रहा है

• https://www.youtube.com/watch?v=wwoWei-GAPo — उस समय से project सच में बहुत आगे आ गया है
  खुशी है कि यह अब भी alive और thriving है। 2009 में शायद उम्मीद नहीं थी कि यह ऐसा बनेगा। Russ के बिना Go आज जहाँ है वहाँ नहीं पहुँच पाता। project में उनका contribution बेहद बड़ा था

• Russ को धन्यवाद। tooling support को first-class element बनाना revolutionary था, और आज भी Go की सबसे prominent विशेषता है