Git: Rust को अपनाने और build system में इसे अनिवार्य बनाने की घोषणा

 (lore.kernel.org)
15 पॉइंट द्वारा GN⁺ 2025-09-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Git प्रोजेक्ट ने आधिकारिक रूप से घोषणा की है कि आगे चलकर वह core में Rust को अपनाएगा, और Git 3.0 से Rust build के लिए अनिवार्य आवश्यकता होगा
  • यह patch series, अतीत में C99 features को अपनाने की तरह, परीक्षणात्मक अपनाने (test balloon) के रूप में आगे बढ़ रही है, जिसका उद्देश्य Rust adoption infrastructure को धीरे-धीरे तैयार करना है
  • पहले चरण में, लगभग बिना dependencies वाले varint.c module को Rust में बदलकर C-Rust interoperability और build tooling की जाँच की गई
  • फिलहाल केवल Meson build supported है, और आगे Makefile support के साथ CI में Rust build verification और cargo format आधारित format consistency checks जोड़े जाने की योजना है
  • यह Git community और distributors को नई Rust toolchain requirements के अनुकूल होने के लिए समय देते हुए, लंबे समय में code safety और scalability बढ़ाने वाला एक महत्वपूर्ण बदलाव है

Rust अपनाने की पृष्ठभूमि

  • Git स्थिरता और maintainability के लिए भाषाई evolution पर विचार करता रहा है
  • Rust को अपनाने का मतलब memory safety को मजबूत करना, modern toolchain का उपयोग, और performance optimization की संभावनाएँ सुनिश्चित करना है
  • साथ ही, modern language को अपनाकर एक अधिक मजबूत codebase बनाने का लक्ष्य भी है
  • Git 3.0 release के समय Rust का अनिवार्य होना पहले से घोषित करके ecosystem को तैयारी का समय देने का उद्देश्य है
  • चरणबद्ध तरीके से Rust code के दायरे को बढ़ाते हुए, अंततः कुछ core features को भी Rust में फिर से implement करने की योजना है

परीक्षणात्मक patch series

  • Rust के पहले target module के रूप में varint.c को चुना गया
    • यह बहुत सरल है और इसकी dependencies नहीं के बराबर हैं
    • C ↔ Rust interop verification संभव है
    • Git की पूरी functionality पर असर डाले बिना प्रयोग किया जा सकता है
  • सभी tests varint.rs version में pass हुए

build system में बदलाव

  • फिलहाल केवल Meson build system में Rust support जोड़ा गया है
  • आगे Makefile में भी Rust support जोड़ने की योजना है
  • CI से जुड़े काम की तैयारी भी ज़रूरी है
    • Rust build और behavior verification
    • cargo format के जरिए code style consistency सुनिश्चित करना
    • अन्य tooling और maintenance automation

आगे की योजना

  • यह काम Rust feature खुद से ज़्यादा adoption process के प्रयोग पर केंद्रित है
  • आगे चलकर xdiff module सहित Git की और internal functionality को Rust में फिर से लिखा जा सकता है
  • Rust को धीरे-धीरे व्यापक रूप से लागू करते हुए पूरे ecosystem को Rust-based build environment के अनुकूल बनने के लिए प्रेरित किया जाएगा

निहितार्थ

  • Git अपने इतिहास के सबसे महत्वपूर्ण भाषाई बदलाव की तैयारी कर रहा है
  • Rust को अनिवार्य बनाने से safety, maintainability, और long-term evolution की क्षमता सुनिश्चित की जा सकती है
  • distributors और developers के लिए आगे Git ecosystem में Rust development environment बनाना अनिवार्य हो जाएगा

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

1 टिप्पणियां

 
GN⁺ 2025-09-21
Hacker News राय
  • दूसरे थ्रेड में Rust को अनिवार्य रूप से अपनाने की चर्चा पर, लेखक का मानना है कि Rust को तुरंत अनिवार्य बनाने के बजाय पहले optional dependency के रूप में लाना बेहतर होगा, और बाद में जब gcc में Rust support जुड़ जाए तब उसे अनिवार्य किया जाए
    संबंधित चर्चा लिंक
    • gcc compiler की असंगतता पर ज़ोर दिया गया है; उदाहरण के लिए gcj (Java के लिए gcc) का लगभग कोई उपयोग नहीं करता
      चूँकि Rust support भी एक ऐसे भाषा इकोसिस्टम से जुड़ा है जिसका कोई मानक नहीं है, इसलिए शक है कि समय के साथ इसका implementation काफ़ी पीछे रह सकता है, जैसा पहले Java के साथ हुआ था
  • यह जानने की जिज्ञासा है कि Git में Rust क्यों लाया जा रहा है
    Git पहले से ही एक काफ़ी परिपक्व टूल दिखता है, और लगता है कि उसे बस maintenance या improvement की ज़रूरत है; इतना बड़ा नया codebase चाहिए, ऐसा नहीं लगता कि उसके लिए नई भाषा लानी पड़े
    Linux की तरह जहाँ लगातार नए drivers की ज़रूरत होती है, Git में ऐसा कारण दिखाई नहीं देता
    अगर मैं कुछ मिस कर रहा हूँ तो कोई समझाए, ऐसी अपेक्षा है
    • Git में लगातार features जुड़ते रहते हैं, भले ही वे ज़्यादा नज़र न आएँ
      Git के changes RelNotes में देखे जा सकते हैं, या GitHub ब्लॉग के Git category में उन्हें थोड़ा आसान रूप में देखा जा सकता है
    • jj या git-branchless जैसे टूल इस्तेमाल करने पर यह धारणा बदल सकती है कि git पूरी तरह complete हो चुका है
      git-branchless में Rust में लिखा गया in-memory merge जैसी capabilities हैं
    • इस लेख में कई जवाब हैं, इसलिए उसे देखना उपयोगी हो सकता है
      Rust से जुड़ी बातें उस mailing list में और खोजी जा सकती हैं
      (स्वयं पक्ष-विपक्ष का मूल्यांकन नहीं किया गया; बस कहा गया कि कोई न कोई वह कर देगा)
    • पुराने C projects में नए developers का आना लगातार कम हो रहा है
      C में Git develop करना चाहने वाले लगभग नहीं हैं, जबकि Rust में rewrite में रुचि रखने वाले developers उत्साह से जुड़ना चाहते हैं
    • C सुरक्षित नहीं है
  • यह सवाल उठाया गया कि Rust को बार-बार अलग-अलग जगहों पर क्यों लाया जा रहा है
    Git बहुत mature है, इसलिए लगता नहीं कि बहुत अधिक नया code जोड़ा जाएगा
    Rust, C की तुलना में काफ़ी अधिक complex है
    अगर वास्तव में object-oriented features चाहिएँ, तो सिर्फ़ C++98 तक का उपयोग भी recent C++ या Rust की तुलना में कहीं अधिक सरल और समझने में आसान होगा
  • शीर्षक थोड़ा भ्रामक बताया गया
    Rust भविष्य के patches के लिए अनिवार्य नहीं होगा, बल्कि build system के भीतर अनिवार्य होने वाला है
    • धन्यवाद देते हुए कहा गया कि शीर्षक में यह बात शामिल कर दी गई है
      अगर वह ग़लत हो तो फिर से सुधारा जा सकता है
    • इसके बाद पूछा गया कि इसका मतलब क्या है
      क्या build system को build करने के लिए इसकी ज़रूरत है, या application build में भी यह अनिवार्य होगा?
  • उम्र थोड़ी बढ़ने के साथ यह मानने के बावजूद कि बदलाव स्वीकार करने का समय आता है, शिकायत है कि पहले सिर्फ़ C जानकर Git या kernel development में भाग लिया जा सकता था, लेकिन अब Rust भी अलग से जानना होगा, और toolchain के लगातार जटिल होने से entry barrier बढ़ रहा है
    Git में गहराई से निवेश किया है और कई projects बनाए हैं, इसलिए Git की hackability खोना नहीं चाहता
    • नई चीज़ें सीखना न चाहने वाला रवैया इस उद्योग के लिए उपयुक्त नहीं माना गया
      वास्तव में Rust सामान्य C, खासकर bug-prone C, की तुलना में सीखना आसान है, और Git या Linux source को समझने से तो निश्चित रूप से आसान है
    • भले ही आपने Git client और web server खुद बनाया हो, Git repository format नहीं बदल रहा, इसलिए hackability पर असर नहीं पड़ेगा
    • जानकारी के लिए, Git पहले से ही कई भाषाओं में बना हुआ है
      GitHub के अनुसार C 50%, Shell 38%, Perl 4%, और बाकी TCL/Python आदि हैं
      Perl/TCL ही वास्तव में अधिक अपवाद जैसे हैं
      project बढ़ने के साथ जगह-जगह जोड़े गए hacky code काफ़ी जमा हो गए, और अब safety/performance सुधारने तथा पुराने hacky code को साफ़ करने का समय है
      Rust इसके लिए उपयुक्त माना गया
    • यह भी कहा गया कि एक software engineer के लिए कई भाषाओं को संभाल पाना सामान्य बात है, इसलिए एक और भाषा जुड़ना बड़ी समस्या नहीं है
    • मेरे समेत बहुत से युवा developers Rust को पसंद करते हैं और C सीखना नहीं चाहते
      Git अगर Rust का कुछ हिस्सा उपयोग करे, तो भी इससे मेरे खुद के Git client या server development में रुकावट नहीं आएगी
  • इस मत पर अतिरिक्त स्पष्टीकरण माँगा गया कि कुछ platforms पर Rust अपनाना असंभव है और अन्य जगहों पर भी कठिन है
    • Linux systems में किसी भी library को system library के रूप में उपयोग करना चाहिए, लेकिन Rust का stable ABI नहीं है, इसलिए उसे वास्तविक shared library के रूप में इस्तेमाल नहीं किया जा सकता
      Debian release notes में भी Rust/Go packages से जुड़े issues स्पष्ट रूप से बताए गए हैं
      Rust packages बनाते समय static linking की समस्या के कारण अक्सर दोबारा build करना पड़ता है, जिससे व्यावहारिक उपयोग में असुविधा होती है
      Linux OS में अनिवार्य stable ABI/shared library की समस्या को अगर Rust पक्ष नज़रअंदाज़ करता है, तो वह C से भी अधिक शिकायतें पैदा कर सकता है
      बड़े software architecture में इस पर अधिक सावधानी से सोचना चाहिए
    • कुछ कम दिखने वाले proprietary platforms अपने स्तर पर C compiler support देते हैं, लेकिन LLVM support संभव नहीं होता
      उदाहरण के लिए इस लेख में NonStop keyword खोजने को कहा गया
    • वजह यह है कि Rust compiler कुछ platforms (OS/architecture combinations) को support नहीं करता
      RESF आदि में अक्सर कहा जाता है कि "platform Rust को support नहीं करता", लेकिन वास्तव में काम तभी होगा जब Rust compiler उसे support करे
    • Rust, LLVM आधारित है, इसलिए वह GCC द्वारा supported platforms की तुलना में अधिक सीमित है
    • Rust के आधिकारिक documentation की platform support list में 'Tier 3' section देखने की सलाह दी गई
  • यह जिज्ञासा है कि git 3.0 में क्या बदलाव होंगे
    git 2.x इतना stable लगता है कि compatibility तोड़ने की कोई वजह नहीं दिखती
    • जवाब में git 3.0 Breaking Changes document देखने को कहा गया
    • default hash function के SHA-256 में बदलने की योजना है
  • पहले cross-compilation environment में build, run, और code editing अलग-अलग होना एक बुनियादी मान्यता हुआ करती थी
    अब संदेह है कि हाल की development culture ऐसे toolchain workflows से दूर हो गई है
    source control, build, और execution environment अलग होते थे, इसलिए remote copy या remote execution की ज़रूरत पड़ती थी, और build rules में target platform detection भी अनिवार्य था
    • उलटे, यह महसूस किया गया कि Rust toolchain किसी भी compiled language की तुलना में cross-compilation को आसान बनाता है
      सिर्फ़ --target flag से लगभग 100 platforms के लिए बिना ख़ास दिक्कत के build किया जा सकता है
      असली समस्या यह मानी गई कि Git development team के कुछ लोग अपने-अपने पुराने या fixed development machines की सीमाओं पर अड़े हुए हैं
    • यह भी राय थी कि अधिकांश developers ने cross-compilation को वास्तव में ठीक से सीखा ही नहीं है
      cross-compilation हमेशा second-class citizen रहा है, और बाहरी projects में उसके ठीक से काम करने की उम्मीद ही नहीं की जाती
      Linux distributions भी Raspberry Pi जैसी चीज़ों के लिए कभी-कभी केवल वास्तविक hardware पर build करना पसंद करती हैं
      इसी कारण कोई इसे सही ढंग से support करने में प्रयास नहीं करता
    • Rust/अन्य पक्षों से अलग, आज cross-compilation की स्थिति लगभग ‘आपदा’ जैसी मानी गई
      Linux इसमें विशेष रूप से गंभीर है, क्योंकि glibc की संरचना पुरानी हो चुकी है, जिससे किसी भी hardware के लिए minimum glibc target करना कठिन हो गया है
      अधिकांश projects cross-compilation support की कोशिश ही नहीं करते
      Zig इसे सुधारने की कोशिश कर रहा है
  • यह तर्क दिया गया कि gcc से संबंधित Rust frontend पर्याप्त mature होने तक अपनाने को टालना बेहतर होगा
    Git एक core project tool है, इसलिए बदलाव का जोखिम बड़ा है, और 6 महीने जैसे कम समय में उसे mandatory dependency बना देना जोखिमपूर्ण माना गया
  • Rust को functional languages की तरह steep learning curve और complex माना गया
    यह जटिलता compile time पर अधिक errors पकड़ने के लिए है, लेकिन नतीजतन भाषा स्वयं काफ़ी complex हो जाती है
    इसी वजह से इसके adoption की सिफ़ारिश नहीं की गई
    kernel के बारे में भी ऐसा समझा गया कि उसने Rust adoption को ठुकरा दिया
    पहले से complex kernel में अगर Haskell-स्तर का type system और Lisp-जैसा macro system जोड़ दिया जाए, तो complexity और बढ़ती है
    serde के ज़रिए Rust code को trace करना कठिन बताया गया
    इसके विपरीत Go का Unmarshal कहीं अधिक आसानी से trace किया जा सकता है
    • इसके जवाब में कहा गया कि functional languages और Rust, C या Go की तुलना में अधिक स्पष्ट लगते हैं
      क्योंकि उनमें compiler में अधिक जानकारी व्यक्त की जा सकती है
      Serde के साथ बहुत बड़ी समस्या कभी नहीं हुई, बल्कि Go के Unmarshal को debug करने की नौबत ज़्यादा आई
      यह दावा भी कि kernel ने Rust को ठुकरा दिया, वास्तव में दो developers के बीच header files कहाँ रखी जाएँ इस पर हुए टकराव तक सीमित था
    • C सरल है, लेकिन सुरक्षित और तेज़ C लिखना बेहद जटिल है
      Rust की entry barrier C से ज़्यादा है, लेकिन 'minimum viable Rust' और 'fast, safe Rust' के बीच का अंतर C की तुलना में बहुत छोटा है
    • यह भी इंगित किया गया कि Rust को complex कहा जाता है, लेकिन C भी किसी मायने में कम complex नहीं है
    • ऐसे compile-time checks की सुविधा ही Rust की विशिष्टता मानी गई
      इसे borrow checker जितना ही महत्वपूर्ण बताया गया
    • जिन लोगों को Typescript का अनुभव है, और जिन्होंने linter के माध्यम से references या Result unwrapping/error handling सीखी है, उनके लिए Rust काफ़ी आसान हो सकता है
      उसका syntax भी अपेक्षाकृत उदार है
      Linux kernel ने वास्तव में Rust को अस्वीकार नहीं किया है