2025 में Rust: foundational software का लक्ष्य

• Rust इस साल अपनी 10वीं वर्षगांठ मना रहा है और आगे चलकर foundational software विकास की एक प्रमुख भाषा के रूप में स्थापित हो रहा है
• foundational software से मतलब उस आधारभूत परत से है जिस पर सब कुछ टिका होता है, जैसे operating system kernel, cloud platform, embedded device, CLI tool आदि
• Rust, C/C++ स्तर का performance और reliability देता है, और साथ ही memory safety सुनिश्चित करने वाले type system के जरिए प्रवेश बाधा को कम करता है
• Rust का मिशन सिर्फ आधारभूत क्षेत्रों तक सीमित नहीं है; Dioxus, Tauri, Leptos जैसे प्रोजेक्ट्स के माध्यम से यह उच्च-स्तरीय application development पर भी प्रभाव डाल रहा है
• आगे language interoperability, type system विस्तार, ecosystem को मजबूत करना जैसी चीज़ों को प्रमुख निवेश क्षेत्रों के रूप में योजना में रखा गया है

---

Rust का विज़न: foundational software

• Rust का मुख्य विज़न foundational software को लिखना और maintain करना अधिक आसान बनाना है
  • foundational software में operating system kernel, cloud infrastructure, embedded device, CLI tool आदि शामिल हैं, जो हर system की नींव बनते हैं
  • इसे पहले से Windows और Linux kernel, VSCode search engine ripgrep, Deno, Python uv package manager जैसी कई जगहों पर अपनाया जा रहा है
• ऐसे software में performance, reliability, productivity तीनों एक साथ महत्वपूर्ण हैं
  • अगर नींव कमजोर हो जाए तो उसके ऊपर की पूरी परत प्रभावित होती है, इसलिए स्थिरता अनिवार्य है
  • performance में गिरावट ऊपर की परतों की performance सीमा तय कर देती है, इसलिए न्यूनतम overhead आवश्यक है

foundational software में performance, reliability, productivity

• foundational software में, हर दूसरे software की तरह, कई तरह की आवश्यकताएँ होती हैं, लेकिन यहाँ हर तत्व और भी अधिक महत्वपूर्ण हो जाता है
  • Reliability सर्वोच्च प्राथमिकता है। अगर नींव टूटती है, तो उसके ऊपर की हर चीज़ विफल हो जाती है
  • Performance overhead ऊपरी परतों की performance सीमा तय करता है, इसलिए इसे न्यूनतम रखना ज़रूरी है
• पहले इन आवश्यकताओं को पूरा करने के लिए दो विकल्प हुआ करते थे
  • C/C++: बहुत अधिक स्वतंत्रता देता है, लेकिन उसी अनुपात में पूर्णता और सावधानी भी मांगता है
  • Java, Go जैसे उच्च-स्तरीय भाषाएँ: performance बनाए रखने के लिए विशेष coding शैली की ज़रूरत पड़ती है, और abstraction व convenience के उपयोग पर सीमाएँ आती हैं
• Rust ने zero-cost abstraction और memory safety सुनिश्चित करने वाले type system के संयोजन से इस पुराने ढाँचे को बदल दिया
• यह ऐसा साधन बन गया है जो उच्च-स्तरीय code को सुरक्षित रूप से लिखते हुए, low-level performance और memory stability दोनों हासिल करने देता है

प्रवेश बाधा कम करना और डेवलपर क्षमता बढ़ाना

• Rust प्रस्तुतियों में type system और static checks को अक्सर "पालक" के रूपक से समझाया जाता है — यानी अच्छी चीज़, लेकिन खाने का मन न करने वाली
• व्यावहारिक रूप से देखें तो type system डेवलपर के लिए एक बेहद शक्तिशाली हथियार है
• शुरुआती डेवलपर type system सीखते हुए सफल software structure बनाना भी सीख सकते हैं
• अनुभवी डेवलपर अपनी खुद की structure design में गलतियाँ और जल्दी पकड़ सकते हैं

• Yehuda Katz का यह कथन भी इसे अच्छी तरह समेटता है: "ध्यान की अवस्था में बनाई गई abstraction मेरे थके हुए भविष्य की मदद करती है"

non-foundational software क्षेत्र

• Rust का मिशन भले foundational software पर केंद्रित हो, इसका मतलब यह नहीं कि अन्य क्षेत्रों को नज़रअंदाज़ किया जा रहा है
• Dioxus, Tauri, Leptos जैसे प्रोजेक्ट्स, Rust का उपयोग करके GUI, web page जैसे उच्च-स्तरीय application क्षेत्रों तक भी विस्तार कर रहे हैं
• Rust की मुख्य ताकत मूल रूप से foundational software पर केंद्रित है, लेकिन इन प्रयासों को नज़रअंदाज़ नहीं किया जाना चाहिए

stretch goals और growth

• foundational software में low-level details पर नियंत्रण की ज़रूरत होती है, इसलिए आम तौर पर accessibility और usability (ergonomics) को कम महत्वपूर्ण माना जाता है
• लेकिन जितना अधिक सूक्ष्म नियंत्रण चाहिए, उतनी ही अधिक usability भी महत्वपूर्ण हो जाती है
• अगर डेवलपर को सचमुच महत्वपूर्ण हिस्सों पर ही ध्यान केंद्रित करने में मदद मिले, तो productivity बहुत बढ़ सकती है

• Rust के उच्च-स्तरीय उपयोग को आगे बढ़ाने वाले प्रोजेक्ट्स, Rust programming को और सुविधाजनक बनाने के अवसर देते हैं
• ऐसे सुधार foundational software development में भी सीधे परिलक्षित होते हैं
• मूल बात यह है कि control और reliability खोए बिना usability बढ़ाई जाए

full stack support का महत्व

• Rust में उच्च-स्तरीय application development को सहज बनाने की एक और वजह यह है कि full stack को एक ही technology से बनाया जा सकता है
• कई डेवलपर जो शुरुआत में Rust को सिर्फ data plane services जैसे कुछ हिस्सों में इस्तेमाल करना चाहते थे, बाद में उसे पूरे क्षेत्र में फैलाते देखे गए हैं
• ऐसा इसलिए है क्योंकि Rust में productivity अधिक है, और एक ही भाषा में library व code sharing संभव है
• मूल रूप से सरल code, किसी भी भाषा में लिखा जाए, सरल ही रहता है

iterative deepening का अनुभव

• आदर्श रूप से Rust उपयोगकर्ता का पहला अनुभव सरल होना चाहिए, और जैसे-जैसे प्रोजेक्ट आगे बढ़े, वैसे-वैसे अधिक नियंत्रण को स्थानीय रूप से क्रमिक रूप से बढ़ाया जा सके
• यह सुनने में सरल लगता है, लेकिन वास्तविकता में यह बहुत कठिन चुनौती है
• कई प्रोजेक्ट्स या तो शुरुआती उपयोगकर्ताओं के लिए बहुत ऊँची प्रवेश बाधा रखते हैं, या फिर उच्च-स्तरीय नियंत्रण सीखने के लिए अत्यधिक ज्ञान मांगते हैं, और इसी कारण असफल हो जाते हैं
• Rust हमेशा इसमें सफल नहीं होता, लेकिन इसे बेहतर बनाने के लिए लगातार प्रयास कर रहा है

आगे की योजना

• यह लेख इस श्रृंखला का पहला लेख है, और आगे चार और लेखों में उन निवेश क्षेत्रों को प्रस्तुत किया जाएगा जिनकी Rust को foundational software के लिए और अधिक उपयुक्त बनने हेतु आवश्यकता है
  • smooth language interop और extensibility
  • type system के माध्यम से clarity of purpose
  • ecosystem को मजबूत करना: बेहतर guidelines, tools, और Rust Foundation का उपयोग
  • अंतिम लेख में Rust open source organization संचालन पर चर्चा होगी, और यह देखा जाएगा कि contribution और maintenance को यथासंभव अधिक सुलभ और आनंददायक गतिविधि कैसे बनाया जाए

[yeorinhieut]

मुझे लगता है कि Rust अकेली ऐसी भाषा है जो चाहे ठीक-ठाक लगती हो, लेकिन उसके toxic fandom(?) की वजह से उससे दूरी बनती है.

[aer0700]

काश C या C++ के लिए भी कोई standard package manager होता। Cargo को देखते ही हमेशा यही ख्याल आता है।

[cosine20]

पालक कितनी स्वादिष्ट होती है....

[t7vonn]

आजकल ऐसा कोई क्षेत्र नहीं बचा जहाँ Rust का इस्तेमाल न हो रहा हो।

[lostid]

मैं भले ही एक बड़ी कंपनी में काम करता हूँ, लेकिन वहाँ Rust इस्तेमाल होने वाला कोई क्षेत्र नहीं है। कृपया बढ़ा-चढ़ाकर पेश न करें।

[t7vonn]

झगड़ा मत शुरू कीजिए

[bobross0]

धत्त;;

[crawler]

बेवजह पंगा मत लो डोल डोल

[shakespeares]

ओह ;;;

[qwas5544]

वाह;;;

[lostid]

बाकी सब छोड़ दें, आजकल के Rust फैनबॉयज़ की वजह से हालत खराब होने लगी है। ऑफ़लाइन में तो यह माइनर में भी बहुत ही छोटा माइनर है, लेकिन ऑनलाइन पर तो लगभग ISIS जैसा... काश ये लोग कहीं एक जगह इकट्ठा होकर बस आपस में ही खेलते रहते...

[ifmkl]

Rust के बड़े समर्थकों में भी अक्सर यह शक होता है कि क्या वे खुद वास्तव में इसे ठीक से इस्तेमाल कर रहे हैं।

[skageektp]

फिर भी... आपको Rust पसंद है, है न?
Rust-इस्लाम से नफ़रत करें तो भी चलेगा, लेकिन Rust से प्यार कीजिए T_T

[taeunlee99]

FFmpeg की वजह से बुरी तरह पिटने के बाद भी कहते हैं कि सारा कोड Rust में ही लिखना चाहिए वगैरह।

[GN⁺]

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

• मुख्य सॉफ़्टवेयर की बात करते समय Rust में सबसे खलने वाली चीज़ ABI है। अगर Rust से OS बनाकर समृद्ध सेवाएँ देनी हैं, तो OS अपग्रेड होने पर भी एप्लिकेशन लाइब्रेरी को दोबारा compile किए बिना चलने चाहिए। Windows ने COM, Apple ने एक समय ObjC के dynamic dispatch (और अब Swift ABI), Android ने JVM और bytecode के जरिए इस समस्या को हल किया। Rust व्यावहारिक रूप से सिर्फ extern "C" ही सपोर्ट करता है, इसलिए dynamic library का उपयोग सीमित है। VM लेयर (JVM, .NET) के बिना ABI देना बहुत कठिन है, और एक बार तय किए गए implementation details को कभी बदलना नहीं पड़ना चाहिए, इसलिए इसका प्राथमिकता में पीछे रहना स्वाभाविक लगता है। वास्तव में इस मॉडल में सफल उदाहरण Swift और COM जैसे ही हैं। अगर Rust में एक पूर्ण ABI आ जाए, तो यह लगभग एक परफ़ेक्ट भाषा बन सकती है। (binary रूप में dependencies मैनेज करने से compile time भी बहुत घटेगा)

  • समझाया गया कि Rust मूल रूप से opt-in ABI stability ही इसलिए लाना चाहता है क्योंकि वह zero-cost abstraction का पीछा करता है। Stable ABI के साथ performance में गिरावट आती है, इसका समर्थन C++ के उदाहरण से भी मिलता है (C++ ABI पर विवरण)। Rust के बीच plugins को dynamic रूप से load (dlopen) करने के लिए stabby, abi_stable जैसे tools मौजूद हैं और काफ़ी अच्छे से काम करते हैं। अधिक सामान्य inter-language interoperability के लिए crABI (crABI प्रस्ताव) भविष्य का विकल्प हो सकता है। लेकिन यह ऐसी समस्या नहीं है जिसे सिर्फ Rust अकेले हल कर सके; दूसरी भाषाओं और Linux distribution जैसे कई समुदायों का समर्थन और सहयोग चाहिए होगा। यह भी कहा गया कि क्योंकि Rust I/O और memory allocation का तरीका स्पष्ट रूप से चुनने वाली भाषा है, इसलिए Swift की तरह सब कुछ shared libraries से हल करने वाला ढांचा इस पर फिट न भी बैठे
  • लगभग यही समस्या Wasm Components से हल करने की कोशिश की जा रही है। अगर WebAssembly एक portable instruction format है, तो WebAssembly Components एक portable execution/linking format है। यह पूरी तरह repr(wasm)/extern "wasm" जितना आसान नहीं है, लेकिन wit-bindgen या wasm32-wasip2 target का उपयोग करके इसे बिना ज़्यादा कठिनाई के इस्तेमाल किया जा सकता है। Wasm Components परिचय वीडियो
  • इस पर संदेह जताया गया कि क्या यह वास्तव में ज़रूरी है। interface के तौर पर और तरह की चीज़ें (slices, trait objects आदि) पास करना ज़्यादा सुविधाजनक होगा, लेकिन व्यवहार में extern "C" ABI से ही ज़रूरी काम हो जाते हैं। और extern ABI को अधिक प्रकारों तक बढ़ाने का प्रस्ताव भी देखा गया है
  • कहा गया कि Rust कॉन्फ़्रेंस में इस विषय पर Swift के तरीके से काफ़ी प्रेरित एक प्रस्तुति देखी थी। अनुमान है कि आगे चलकर विकास इसी दिशा में होगा
  • दरअसल ऐसा पहले से मौजूद है। उसका नाम ही C है

• Rust बहुत पसंद है, लेकिन कुछ पुरानी परेशान करने वाली समस्याएँ हैं जिन्हें और ध्यान मिलना चाहिए

  • 1. self-referencing struct की समस्या है। उदाहरण के लिए source file और parsed AST को एक ही struct में रखना चाहें तो अभी यह आसान नहीं है। offset reference जैसी कोई चीज़ उपयोगी होगी
  • 2. orphan rule। वजह समझ में आती है, लेकिन यह फिर भी परेशान करने वाला नियम है। नई सुविधाओं से इसे संभाला जा सकता है (कभी-कभी 2-3 परत wrapping भी चाहिए!), लेकिन क्या यह सचमुच इतना आवश्यक है, इस पर सवाल है
  • 3. उचित compile time पाने के लिए project को कई छोटे crates में बाँटना पड़ता है। वजह समझ में आती है, लेकिन नतीजा अच्छा नहीं है। crate को एक compile unit माना जाता है, और ऐसा इसलिए है क्योंकि cyclic dependencies की अनुमति होती है। लेकिन ज़्यादातर code में वास्तव में cyclic dependency नहीं होती, इसलिए या तो इसे opt-in होना चाहिए, या crate के अंदर items/files को dependency graph के आधार पर अपने-आप compile units में बाँट देना चाहिए
  • अभी जो याद आया वही लिखा, पर ऐसी और भी बातें होंगी। फिर भी Rust मेरी ज़िंदगी की सबसे बेहतरीन भाषा है, और यह आलोचना रचनात्मक है
    • बताया गया कि Rust crates के बीच cyclic dependencies की अनुमति नहीं देता, लेकिन crate के अंदर modules के बीच देता है। आम तौर पर ज़्यादातर code में cyclic dependency नहीं होती, लेकिन जैसे test submodule वाला कोई भी module इस चक्र में आ जाता है। tests को सचमुच अलग करना हो तो हर test function को crate root पर define करना पड़ेगा, जो व्यवहार में बहुत अक्षम है
    • 1 और 2 से पूरी सहमति जताई गई। 4 नंबर के तौर पर partial self borrows (ऐसी सुविधा जिसमें method struct के सिर्फ़ एक हिस्से को borrow करे) की इच्छा भी जोड़ी गई। 3 के मामले में पहले ऐसे बेहतर समर्थन की ज़रूरत मानी गई जिसमें कई crates को एक साथ publish किया जा सके
    • orphan rule को लेकर पूछा गया कि क्या Rust को कोई बेहतर विकल्प लाना चाहिए, या सिर्फ़ ऐसा feature चाहिए जो इसे replace कर सके
    • orphan rule से पूरी सहमति जताई गई। इच्छा जताई गई कि application crate में इसे बंद किया जा सके, या proc macro आदि के ज़रिए पर्याप्त hygiene सुनिश्चित होने पर नियम को ढीला किया जा सके

• “Smooth, iterative deepening” अभिव्यक्ति पर सोचते हुए कहा गया कि Rust अगर cross-language compatibility को बहुत ज़्यादा महत्व देगा तो उल्टा complexity बढ़ेगी और safety को नुकसान पहुँच सकता है। ऐसे में libc की तरह सिस्टम की निचली परत को बदलना ज़्यादा मददगार होगा। Go लगभग cross-language calls नहीं करता। Google ने core libraries खुद बनाकर मज़बूत आधार तैयार किया, लेकिन Rust में अलग-अलग versions की बुनियादी libraries बिखरी हुई हैं और बहुत-सी अधूरी हैं

  • बताया गया कि पिछले 20 वर्षों में computer science की मुख्य चुनौतियों में से एक यही रही है कि एक ही machine के भीतर कई programs कुशलता से कैसे संवाद करें। ज़्यादातर कोशिशें MS के DLL ढांचे को source और state के ज़रिए bypass करने की रही हैं, या CORBA जैसे object request brokers टिक नहीं पाए। qnx-शैली RPC का भी यही हाल रहा। इसलिए आज भी हम बार-बार ऐसे ढांचे थोपने की कोशिश करते हैं जो वास्तव में एक-दूसरे के लिए बने ही नहीं थे
  • व्यवहार में सब कुछ sockets से भी किया जा सकता है, लेकिन sockets raw byte stream हैं, यानी abstraction ग़लत है, फिर भी उनकी usability अच्छी होने से उनका उपयोग करना पड़ता है
    • मेरी नज़र में, पोस्ट में बात मौजूदा DLL/COM/Wasm components जैसे असली cross-language shared library replacement की नहीं, बल्कि C++ को धीरे-धीरे Rust में migrate करने की व्यावहारिक ज़रूरत की है। कुल मिलाकर memory safety सुधारने के लिए “मौजूदा programs का क्या किया जाए” बड़ा सवाल है, और अभी Rust तथा C++ के बीच interoperability पर्याप्त नहीं है। अगर दोनों भाषाएँ source level पर सहजता से साथ काम कर सकें, तो Rust के C++ के बड़े हिस्से को replace करने की वास्तविक संभावना भी बढ़ जाएगी
    • कभी-कभी लगता है कि अगर sockets और protocol मेल खाते हों, तो वही लगभग सबसे अच्छा cross-language abstraction बन जाता है। ऐसे में जिज्ञासा है कि आदर्श cross-language call abstraction आखिर किसे माना जा रहा है

• इस बात पर ज़ोर दिया गया कि “allocation से बचो, GC trigger मत होने दो” जैसी सोच आधुनिक GC और JIT की समझ से मेल नहीं खाती। आधुनिक GC में कई बार stop-the-world latency लगभग न के बराबर होती है, और कुल GC CPU usage मुख्य रूप से resident set और heap size के अनुपात पर निर्भर करती है। JIT को AOT की तुलना में optimization के ज़्यादा अवसर मिलते हैं, और वह ज़्यादा आक्रामक खोज कर सकता है (speculative optimization की वजह से)। असली महत्व startup/warm-up delay, memory overhead, और worst-case performance के बिगड़ने की बजाय average performance का है। इसके अलावा, manual memory management ज़रूरी नहीं कि हमेशा ज़्यादा efficient हो, और RAM usage 3 गुना बढ़ने पर भी लागत का अंतर शून्य हो सकता है। इस विषय पर अच्छी ISMM कॉन्फ़्रेंस प्रस्तुति भी सुझाई गई

  • JIT को ज़्यादा optimization अवसर मिलने से सटीक मतलब क्या है, इस पर विस्तार से पूछा गया। JIT आखिरकार AOT का पूरक ही है
  • यहाँ “आधुनिक GC” से किन implementations का मतलब है, यह भी पूछा गया

• माना गया कि flagged comments और चर्चा ने मुद्दों को अच्छी तरह पकड़ा। “औपचारिक specification वाला language standard बनाया जाए”, “कई implementations की ज़रूरत है” जैसे सवाल व्यवहारिक रूप से महत्वपूर्ण हैं। विशेष रूप से @infogulch ने यह बात सही पकड़ी कि अगर किसी language को industry का आधार बनना है तो औपचारिक specification ज़रूरी है (संदर्भ टिप्पणी)

  • यह चुटीले ढंग से कहा गया कि flag किए जाने का कारण भी स्पष्ट नहीं है, और व्यवहार में ऐसे कई examples हैं जहाँ बिना standard spec या multiple implementations के भी भाषाएँ industry foundation बनी हैं। जैसे Ruby का पुराना ISO standard है, लेकिन वह उसी version तक सीमित है; Python में तो व्यवहार में implementation ही standard है। Rust भी वैसा ही है, और मुख्यधारा के users ऐसी वजहों से भाषा नहीं बदलेंगे
  • “औपचारिक language standard” के बारे में जिज्ञासा से खोजने पर rust-lang/reference reference document मिला। Rust project language specification को लेकर काफ़ी गंभीर है। हाल की blog vision post में प्रगति का विस्तार से वर्णन है। specification का काम बहुत बड़ा और कठिन है, फिर भी weekend पर भी master branch में PR merge होने लायक सक्रियता से यह आगे बढ़ रहा है
  • कई implementations की ज़रूरत वाले बिंदु पर भी gccrs जैसे वैकल्पिक Rust compiler आधिकारिक रूप से विकसित हो रहे हैं, यह मददगार रहा हो ऐसी आशा जताई गई
  • LLM और Rust, दोनों को लेकर एक संशयपूर्ण नज़रिया व्यक्त किया गया कि वे मूल समस्या का सिर्फ़ कुछ हिस्सा ही हल करते हैं और productivity में मामूली बढ़त देते हैं। लेकिन community में गैर-जिम्मेदार तरीके से प्रभाव बढ़ाने वाली प्रवृत्ति से असहमति जताई गई
  • “published language standard” से सटीक मतलब क्या है, और व्यवहार में उससे क्या लाभ मिलता है, इस पर और स्पष्टीकरण माँगा गया
  • Rust से खुद कोई शिकायत नहीं है, लेकिन कुछ users के इस रवैये पर अफ़सोस जताया गया कि वे formal specification की अहमियत को नहीं समझते। हर computational system की उम्र और विश्वसनीयता इस पर निर्भर करती है कि specification कितनी formal है। अगर स्पष्ट spec नहीं है, तो हम पूरी तरह इस पर निर्भर हो जाते हैं कि “किसी implementation ने संयोग से किसी input पर क्या किया”, और इतनी कमज़ोर नींव पर systems बनाना ख़तरनाक है। computing में specification ही system है (implementation तो सिर्फ़ एक सहायक optimization है)

• लोग अक्सर यह पूछे जाने पर ही सवाल उठाते हैं कि Rust को specification की ज़रूरत है भी या नहीं, और यह दिखाता है कि software engineering में वास्तविक engineering कितनी कम है

  • कहा गया कि software engineering असली engineering नहीं है। पुल या गगनचुंबी इमारत की तरह चीज़ों को 3 बार बनाकर सही करना वहाँ संभव नहीं, लेकिन software में यह उल्टा एक अच्छा तरीका बन जाता है

• Rust को “ऐसी भाषा जिसे सिर्फ़ वे लोग इस्तेमाल करते हैं जो programmer जैसा दिखना चाहते हैं” कहने वाली टिप्पणी पर जवाब में कहा गया कि वह खुद programming से प्यार करता है और Rust उसके लिए एक ताज़ा झटका था। वह C++ के अत्यंत पीड़ादायक अतीत में लौटना नहीं चाहता। और language standard (ferrocene specification donation) या implementations की संख्या को इतना महत्वपूर्ण नहीं मानता। Python और Java भी एक केंद्रीय implementation पर निर्भर रहकर अच्छी तरह चलते हैं। C++ ने कई compilers को support करने की कोशिश में अंततः platform-specific complexity ही बढ़ाई। cargo का “mess” आखिर क्या है, यह स्पष्ट नहीं, और C++ पक्ष कहीं ज़्यादा असुविधाजनक लगा

  • cargo के बारे में खास तौर पर क्या समस्या है, यह पूछने वाली प्रतिक्रिया है
  • यह भी जोड़ा गया कि language/tool standardization या implementation diversity वास्तव में कितनी महत्वपूर्ण है, क्या यह अभी समय से पहले की माँग नहीं, और अगर Rust ने शुरू से ही इनमें ऊर्जा लगाई होती तो क्या वह आज जितना सफल होता? लेख शायद ऐसी “everything replacement” वाली व्यापक दलील नहीं दे रहा, बल्कि खास target use cases के लिए support/fitness पर ज़ोर दे रहा है
  • माना गया कि cargo इस समय दुनिया की प्रमुख भाषाओं में सबसे बेहतरीन package manager है। इसने पिछले package managers की विफलताओं से सीखकर सबसे polished और infrastructure के तौर पर भी उच्च स्तर का रूप लिया है। namespace, पूर्ण repeatable builds जैसी कुछ सुधारों की गुंजाइश हो सकती है, लेकिन आज के cargo को किसी दूसरी भाषा पर चढ़ा देना लगभग असंभव है। इतनी मज़बूत infrastructure वाली भाषाएँ बहुत कम हैं