Ubuntu का Rust इस्तेमाल करना क्या मायने रखता है?

• Ubuntu द्वारा Rust अपनाना यह दिखाता है कि technology adoption cycle में Rust early adopter चरण से chasm पार करके mainstream चरण की ओर बढ़ रहा है
• Canonical ने Rust को नए foundational software की default language के रूप में अपनाया है, जिससे C, C++, और कुछ Python उपयोग की जगह ली जा रही है, और memory-safe utilities के विकास में वित्तीय व प्रतिष्ठात्मक दोनों स्तरों पर निवेश किया जा रहा है
• क्योंकि early majority उपयोगकर्ता "industry standard" और मौजूदा workflow के साथ compatibility चाहते हैं, इसलिए drop-in तरीके से utilities को बदलना chasm पार करने की मुख्य रणनीति है
• Rust की standard library expansion समस्या फिर से उभरकर सामने आई है, और 2016 में अस्वीकार की गई "Rust Platform" अवधारणा शुरुआती बहुसंख्यक उपयोगकर्ताओं के लिए वास्तव में अधिक उपयुक्त हो सकती है—इस पर पुनर्विचार हो रहा है
• adoption को investment से जोड़ने वाली संरचना और open source community की empathy-आधारित समावेशिता Rust की अगली growth stage के लिए अनिवार्य है

---

Rust का 'chasm पार करना' हर क्षेत्र में अलग है

• Rust ने Technology Adoption Life Cycle में chasm पार किया है या नहीं, यह क्षेत्र पर निर्भर करता है
• Amazon के भीतर बड़े पैमाने के data plane या resource-aware agent बनाने में Rust ने मजबूत जगह बना ली है, लेकिन सामान्य development के लिए इसे अभी भी कई लोग जरूरत से ज्यादा मानते हैं
• Safety Critical Software क्षेत्र में सफलता के उदाहरण हैं, लेकिन उद्योग का बड़ा हिस्सा अब भी "wait-and-see" mode में है

"reference customers" का महत्व

• chasm पार करने की कुंजी है reference customers हासिल करना
• early adopters "change agent" खरीदते हैं, लेकिन early majority मौजूदा operations की productivity बढ़ाना चाहती है और discontinuity को न्यूनतम रखना चाहती है
• अपने जैसे किसी संगठन की सफलता देखना नई technology adoption के लिए सबसे प्रभावी प्रेरक तत्व होता है
• S3 टीम की Rust सफलता बड़े service teams के लिए प्रभावशाली है, लेकिन CRUD service teams के लिए उतनी सीधे तौर पर आश्वस्त करने वाली नहीं—यह इसका उदाहरण है

Ubuntu (Canonical) की Rust adoption strategy

• Rust Nation में Canonical के VP of Engineering Jon Seager ने "Rust Adoption At Scale with Ubuntu" keynote प्रस्तुत किया
• Canonical अब तक अपनी development languages को Python, C/C++, और Go तक सीमित रखता था, लेकिन हाल में Rust को जोड़कर नए foundational work की default language के रूप में अपनाया है
• यह Lars Bergstrom के Google के भीतर Rust adoption keynote की तरह vision और practicality दोनों को साथ लेकर चलने वाला दृष्टिकोण है
  • यही वे सटीक गुण हैं जो early adopters से early majority की ओर संक्रमण के लिए चाहिए

memory-safe utilities में निवेश

• Jon Seager ने कहा कि Ubuntu को memory-safe foundational utilities बनाने में "pay it forward" भावना के साथ समर्थन देना चाहिए
• Canonical, Trifecta Tech Foundation के sudo-rs, ntpd-rs विकास और uutils के coreutils कार्य को वित्तीय सहायता दे रहा है
• संरचना ऐसी है कि Ubuntu पहले नई चीज़ों को आज़माए और validate करे, ताकि बाद में अन्य distributions उसका लाभ उठा सकें
• मौजूदा workflow में सीधे फिट हो जाने वाली drop-in utilities early majority की "discontinuity न्यूनतम" रखने की आवश्यकता से मेल खाती हैं

नए adopters की मांग: standard library expansion

• डिनर के दौरान Jon Seager ने कहा कि Rust की छोटी standard library policy पर फिर से विचार किया जाना चाहिए
• यह कई वर्षों से दोहराई जा रही मांग है; विचार सिर्फ बड़ी standard library देने का नहीं, बल्कि "Battery Packs" नामक project-form alternative का है
• 2016 में प्रस्तावित Rust Platform (कुछ specific crates को extended standard library के रूप में मान्यता देने की अवधारणा) उस समय early adopters ने ठुकरा दिया था, लेकिन अब इसे early majority के लिए उपयुक्त माना जा रहा है
  • उस समय यह राय प्रमुख थी कि Cargo.toml में dependency जोड़ देना ही पर्याप्त है

growth के लिए बदलाव की आवश्यकता

• early adopters से early majority की ओर बढ़ने के लिए "state-of-the-art" नहीं बल्कि "industry standard" वाला संदेश चाहिए
• Rust उद्योग में पहचान बनाने में सफल रहा है; अब इसे "क्या बन सकता है" नहीं, बल्कि "वास्तव में क्या है" के आधार पर सबसे अच्छा विकल्प बनना होगा
  • ये दोनों बातें कभी-कभी तनावपूर्ण संबंध में हो सकती हैं
• pragmatists तक marketing करने के लिए धैर्य, उस उद्योग की समस्याओं की समझ, और industry conferences में भागीदारी जरूरी है

adoption को investment से जोड़ने वाली संरचना

• Rust adoption के विस्तार के साथ Rust project और ecosystem पर demand बढ़ती है
• Canonical जैसे open source संगठनों के लिए $$ से अधिक संगठनों के बीच संबंध बनाना और योगदान महत्वपूर्ण है
  • Rust for Linux developers को शुरुआत में Rust maintainers की मदद मिली, लेकिन धीरे-धीरे उन्होंने खुद bugs fix करने शुरू किए और maintainers mentor की भूमिका में आ गए
• एक दिलचस्प रुझान यह है कि funding अक्सर Rust को पहले से अपनाने वाली कंपनियों से नहीं, बल्कि अपनाने पर विचार कर रही कंपनियों से आती है
  • संगठन के भीतर मौजूद early adopter व्यक्ति adoption को आगे बढ़ाते हैं और "table stakes" features के विकास के लिए budget आवंटित करते हैं
• Rust Foundation Silver Member Directory के Alexandru Radovici के अनुसार, कई safety-critical software कंपनियों के पास Rust की कमियों को भरने के लिए धन तो है, लेकिन वे उसका उपयोग कैसे करें यह नहीं जानते

open source की भूमिका और empathy का महत्व

• open source chasm पार करने के लिए शानदार platform है, लेकिन cliques और "oral traditions" प्रवेश बाधा बन सकते हैं
• गलत शब्दावली के उपयोग पर ideas खारिज हो सकते हैं, या एक असभ्य जवाब नया contributor दूर कर सकता है
• Rust की अगली growth stage के लिए सबसे ज्यादा जरूरी है open source में empathy
• मुख्य बात यह है कि Rust वहाँ जाए जहाँ वह लोगों की मदद कर सकता है, और उन्हें support व empower करे

[GN⁺]

Hacker News की राय

• Ubuntu का GPL नहीं वाले लाइसेंस का userland इस्तेमाल करने का मतलब यह हो सकता है कि Linux ecosystem में TiVoization को और ज़्यादा जगह मिले
  अगर यह systemd पक्ष के Amutable की दिशा के साथ जुड़ता है, तो बंद Linux distribution भी आ सकती हैं जिनमें user modification संभव न हो
  कंपनियों के लिए पूरी तरह signature-verified बंद environment आकर्षक हो सकता है। ऐसा दुनिया जहां “ls” या “cd” भी closed source हों, कुछ अजीब तरह से प्रलय-जैसी लगती है

  • util-linux या BSD गायब नहीं हो रहे। Ubuntu पसंद नहीं है तो मत इस्तेमाल करो। Debian कहीं ज़्यादा स्थिर था
  • दरअसल इसे GNU/Linux कहने की वजह थी। Android/Linux भी GPL userland नहीं है, और embedded प्रतिद्वंद्वी भी ज़्यादातर GPL नहीं हैं। आखिरकार Linux सिर्फ kernel है
  • ऐतिहासिक नज़र से देखें तो शायद मैं भोला हूँ, लेकिन मुझे नहीं लगता कि ऐसा बदलाव ज़रूरी तौर पर बुरा है। मैं open source utilities को पसंद करता हूँ, लेकिन specs का पालन करने वाले closed alternatives का होना भी ठीक है। कंपनियाँ ऐसा करके open source projects में और ज़्यादा funding भी डाल सकती हैं
  • सच कहूँ तो Ubuntu मुझे quality से ज़्यादा marketing पर चलने वाला Linux का Apple लगता है। Debian परिवार को लोग कम maintenance cost की वजह से इस्तेमाल करते हैं, और मेरी राय में Fedora या OpenSUSE ही भविष्य हैं
  • अगर ऐसे बदलाव से Linux users के 95% लोग एक ही OS इस्तेमाल करने लगें, तो शायद यह इतना बुरा भी न हो

• Rust के सामने असली chasm है safe ABI के साथ dynamic linking support
  अगर एक library बदलने पर भी safety बनी रहे, और C-स्तर की ABI stability मिले, तभी C/C++ दुनिया में Rust adoption सच में बढ़ सकता है

  • Rust पहले से ही C ABI के ज़रिए communicate कर सकता है। यह C++ के बराबर dynamic linking capabilities देता है
  • C++ की ABI stability भाषा के विकास को रोकने वाली बड़ी वजह है। STL के class layout बदले नहीं जा सकते, और header में implement किए गए templates को बाद में optimize करना भी मुश्किल होता है। Rust को ऐसा “stable ABI” support नहीं करना चाहिए
  • Rust की efficiency compile-time monomorphization पर निर्भर करती है। ABI बनाना है तो link-time specialization पर भी सोचना होगा। यह सिर्फ code generation को linker तक ले जाने की बात नहीं है, बल्कि function parameters की “shape” को सावधानी से संभालना होगा
  • dynamic linking debug build में compile time घटाने में भी फायदेमंद है। जो libraries नहीं बदलीं उन्हें दोबारा build नहीं करना पड़ता, और runtime overhead भी बहुत कम होता है
  • अफसोस है कि Rust community, GPL से ज़्यादा MIT को पसंद करती है। GPL user-friendly है, MIT corporate-friendly। मुझे लगता है “Rewrite-it-in-Rust” आंदोलन user protection से ज़्यादा language adoption पर केंद्रित है

• Ubuntu के Rust अपनाने से भी बड़ा मुद्दा यह है कि वह अब भी महत्वपूर्ण builds के लिए curl|bash scripts पर निर्भर है
  firefox-snap का snapcraft.yaml यह साफ दिखाता है

  • “curl|bash” सुनते ही आम तौर पर random config changes या .bashrc editing याद आती है, लेकिन यहाँ बस static toolchain install script चल रही है। 90s वाला तरीका है, लेकिन तुलनात्मक रूप से सुरक्षित है
  • बहुत-सी distributions में Rust version बहुत पुराना है। Debian या Ubuntu LTS में Rust अक्सर काफी outdated version होता है, इसलिए शायद static linking से परहेज़ किया जा रहा है
  • curl से कुछ चलाना भी hash verification ठीक से हो तो स्वीकार्य है

• Rust Coreutils project का MIT license होना मुझे खटकता है
  FSF की philosophy पर आलोचना हो सकती है, लेकिन GPL open source की रक्षा करता है। अगर Canonical पूरे Ubuntu को MIT की ओर ले जाए, तो क्या होगा कहना मुश्किल है

  • GPL पहले बहुत शक्तिशाली था, लेकिन अब automatic copyright laundering systems की वजह से चीज़ें अक्सर MIT/BSD या commercial code में बदल जाती हैं। FSF के पास भी इसका हल नहीं है
  • license पर बहस कभी खत्म नहीं होती। GPL adoption को सीमित करता है, जबकि MIT ज़्यादा flexible है। आखिरकार बात आपका लक्ष्य क्या है पर निर्भर करती है — क्या आप ऐसा OSS चाहते हैं जिसे सब इस्तेमाल कर सकें, या आप यह रोकना चाहते हैं कि कंपनियाँ बिना योगदान के फायदा उठा लें
  • Coreutils के MIT होने से ठीक-ठीक कौन-सा “बुरा काम” संभव हो जाता है, यह जानने की उत्सुकता है

• rust-coreutils की वजह से CUDA Toolkit install नहीं हो पाया। संबंधित issue NVIDIA forum में है

  • linked thread देखकर लगता है कि समस्या gzip से जुड़ी थी। शायद dd की वजह से नहीं थी
  • सच कहूँ तो rust-coreutils के अस्तित्व की जरूरत समझ नहीं आती। Ubuntu install करने के बाद पहला काम होना चाहिए असल coreutils और sudo को फिर से install करना

• “Crossing the chasm” की अवधारणा दिलचस्प है। Ubuntu के coreutils मामले के अलावा भी Rust के सामने कई और अंतराल हैं
  Rust for Linux या automotive industry के लिए Rust जैसे प्रयास हैं, लेकिन अभी भी चीज़ें driver स्तर पर अटकी लगती हैं

  • Rust कई दिशाओं में फैल रहा है। pyo3 (Python modules का विकल्प), Dioxus (React-जैसा web framework), Ferrocine (automotive compiler) जैसे उदाहरण हैं। DARPA TRACTOR project भी Rust adoption को तेज कर रहा है
  • Rust के Project Goals दस्तावेज़(लिंक) को देखें तो पता चलता है कि community किस दिशा में निवेश कर रही है
  • Rust खुद बेहतरीन है, लेकिन community का एक हिस्सा स्थिर और परखे हुए software को बस “Rust में फिर से लिखो” कहकर brand hijack कर रहा है, यही समस्या है। Ubuntu भी शायद ऐसे virtue signaling में फँसा लगता है

• बाद में standard library बदल देने की दलील खतरनाक है। users को “chasm” नहीं, बल्कि स्थिर और उच्च-गुणवत्ता वाला system चाहिए

  • Rust में stdlib को “बदलना” नहीं, बल्कि उसमें जोड़ना आसान है। हर 6 हफ्ते में नया release आता है, और हर बार 10 से ज़्यादा features जुड़ते हैं। stdlib में पहले से सैकड़ों features हैं

• Rust ecosystem की अपरिपक्वता adoption रोकने वाली वजह है। कई crates अब भी 1.0 से पहले हैं या बस साधारण C wrappers हैं। crypto से जुड़ी चीज़ें ठीक हैं, लेकिन SAML जैसी चीज़ें ढूँढना कठिन है

  • pre-1.0 version को लेकर बहुत चिंतित होने की ज़रूरत नहीं। SemVer को सख्ती से मानने वाली culture की वजह से लोग 1.0 घोषित करने में देर करते हैं। libc जैसे crate, जो API से गहराई से जुड़े हैं, उनके लिए version bump करना मुश्किल होता है। मैं निजी तौर पर blessed.rs जैसी curated list देखता हूँ
  • gettext भी 30 साल बाद 1.0 तक पहुँचा
  • Python के cryptography module को Rust toolchain चाहिए था, इसलिए Termux environment में install संभव नहीं था। Rust dependency की वजह से Python projects तक भारी हो जाना असुविधाजनक है

• Rust में C++ code का सिर्फ “vibe-translate” करके license बदलने की एक प्रवृत्ति है। उदाहरण के लिए sudo-rs का safety record C version से भी खराब है

  • Rust, AI और safety को लेकर propaganda बहुत ज़्यादा है। शुरुआत में मुझे Rust बहुत पसंद था, लेकिन MIT license विवाद और अत्यधिक प्रचार अब थकाने लगा है

• .NET की बहुत बड़ी standard library सच में बहुत सुविधाजनक है। ज़्यादातर काम standard तरीके से हो जाते हैं, और अगर कोई अजीब implementation हो तो अधिकतर लोग उसे standardize करने की कोशिश करते हैं

  • मुझे लगता है Rust की छोटी stdlib एक गलती है। stdlib वह एकमात्र dependency है जो हमेशा मौजूद रहती है, इसलिए भले ही वह perfect न हो, उसमें और tools होने चाहिए
  • लेकिन system programmers के नज़रिए से बड़ी stdlib खुद समस्या बन सकती है। .NET में GC है इसलिए फर्क कम पड़ता है, लेकिन Rust या C++ को bare-metal environments में भी चलना होता है। बड़ी stdlib memory-constrained (<64K) environments में बोझ बनती है
    Rust का std/core पहले ही इतना बड़ा है कि microcontrollers पर weak symbol जैसी तरकीबें लगानी पड़ती हैं।
    छोटी stdlib API stability बनाए रखने और maintenance burden कम करने में मदद करती है। C++ इस समस्या से जूझ चुका है, इसलिए Rust को सावधानी रखनी चाहिए