Rust पर दांव लगाए 10 साल हो गए, और आगे क्या उम्मीद है

• Rust 1.0 रिलीज़ के तुरंत बाद से 10 वर्षों तक Rust को प्रोडक्शन में अपनाने के अनुभव और आने वाले 10 वर्षों से जुड़ी उम्मीदों को समेटने वाला लेख
• शुरुआती दौर में version compatibility समस्याएं, build time, और borrow checker के अनुकूल होना कठिन था
• Rust community और ecosystem “बेहतरीन programming sense” और मजबूत सामुदायिक संस्कृति के कारण तेज़ी से आगे बढ़े, और उत्कृष्ट डेवलपर्स का Rust की ओर आकर्षित होना विशेष रूप से दिखा
• अब सामान्य systems और backend क्षेत्रों में Rust एक “stable choice” बन चुका है, और standard library के विकास तथा crate ecosystem की परिपक्वता से अनिश्चितता काफी कम हुई है
• build speed, portability, const features, concurrency, और विभिन्न domains में विस्तार जैसे बाकी बचे मुद्दों और Rust की आगे की दिशा को ठोस रूप में रखा गया है
• अगले 10 वर्षों में और तेज़ compilation, व्यापक domain expansion, और developer experience में नवाचार जारी रहने की संभावना जताई गई है, और Rust ecosystem के सकारात्मक feedback loop के और तेज़ होने की उम्मीद है

---

• जून 2015 में, Rust 1.0 के सार्वजनिक होने का उत्साह ठंडा पड़ने के लगभग एक महीने बाद पहला Rust code लिखा
• C, Python, JavaScript का उपयोग करने के बाद Rust से परिचय हुआ, और फिर पीछे मुड़कर नहीं देखा
• Rust-आधारित दो startup और 5 लाख से अधिक lines of code लिखने के अनुभव के आधार पर 10 वर्षों की यह समीक्षा साझा की गई है

शुरुआती दिन कठिन थे - The early days were painful

• Rust को शुरुआती दौर में अपनाते समय crate और compiler के बीच version compatibility बहुत अस्थिर थी, और छोटी bug fix के लिए भी पूरे build environment को ज़बरदस्ती अपडेट करना पड़ता था
• borrow checker की अवधारणा और lifetime management कठिन लगते थे, और type जितने जटिल होते जाते, compilation time उतनी तेज़ी से बढ़ता, जो एक गंभीर समस्या थी
• हर बार जब नई feature या bug fix की ज़रूरत पड़ती, तब “दुनिया के सारे version” अपडेट करने पड़ते थे, और compatible version ढूंढने में बहुत समय खर्च होता था

Rust community की उत्कृष्टता - The people were and are exceptional

• Rust ecosystem में सरल और elegant implementation, तेज़ और मजबूत performance को लक्ष्य बनाने वाली असाधारण programming culture स्थापित हुई
• TypeScript या Python की तुलना में Rust की dependency structure कहीं अधिक साफ़-सुथरी है और build भी सरल है
• community volunteers के समर्पित योगदान और “अभी नहीं / अभी तक नहीं” जैसी सावधान सोच ने इसमें अहम भूमिका निभाई
• लंदन में Rust developers की hiring में बड़ा लाभ मिला, और Rust developers की औसत क्षमता बहुत ऊंची रही

Rust, (कुछ domains में) एक सुरक्षित विकल्प बन चुका है - Rust has become a safe bet (in some domains)

• शुरुआती दिनों में standard library (std) की कमी के कारण utility functions और patches खुद बनाने पड़ते थे, लेकिन अब ज़्यादातर सुविधाएं std और crates में शामिल हैं, जिससे अनिश्चितता बहुत कम हुई है
• build और upgrade की predictability, external dependencies में कमी, semver पालन, और borrow checker व inference engine में सुधार की वजह से Rust का उपयोग अनुभव काफी स्थिर हुआ है
• नए crates (जैसे: jiff, polars, tauri) अतीत के trial-and-error के आधार पर विकसित हो रहे हैं, और tokio, hyper, regex जैसे tools वास्तविक उपयोग में परखे जा चुके हैं
• पहले “reinventing the wheel” लगभग अनिवार्य था, लेकिन अब business logic पर ध्यान देकर high-performance और robust applications बनाना संभव हो गया है

आज का Rust वैसा लगता है जैसा programming को होना चाहिए - Rust today feels like what programming should be

• Rust में संक्षिप्त और मजबूत build system, बेहतरीन error messages और lint, शानदार documentation और IDE integration, तथा शक्तिशाली CI/regression testing जैसी programmer-केंद्रित संवेदनशीलता है
• बड़े open source projects में Rust जितनी programmer-friendly language बहुत कम देखने को मिलती है
• असंख्य communities और contributors का “long-term investment” आज के Rust को बनाने वाला मुख्य कारक है

आने वाले 10 वर्षों से क्या उम्मीद है - What I’m looking forward to over the next 10 years

और सरल व तेज़ builds - Simpler and faster builds

• जटिल या धीमी dependencies को सरल और तेज़ विकल्पों से बदलने का काम आगे भी जारी रहने की उम्मीद है
• pure Rust standard library, system linker और library dependencies में कमी, pure-Rust cryptography, persistent BTreeMap, और Rust-आधारित game engine जैसे नए प्रयोगों की उम्मीद है
• Tably में भी हाल के महीनों में frontend/backend compilation speed में 60% सुधार हुआ है

portability में सुधार और #[cfg()] का कम उपयोग - Improved portability and less #[cfg()]

• अलग-अलग platform/option combinations की testing कठिन है, और #[cfg()] की वजह से untested code, अधूरा documentation, और IDE समस्याएं पैदा होती हैं
• #[cfg()] को trait system के भीतर ले जाकर platform/option guarantees, कम recompilation, MIR cache, और तेज़ CI हासिल होने की उम्मीद है

हर code const बन सके - Everything being const

• compile time पर अधिक काम पहले से कर लेने से macro/build script पर निर्भरता कम हो सकती है, और runtime errors को भी पहले ही रोका जा सकता है
• अभी यह सीमित है, लेकिन आगे ऐसे Rust की दिशा में बढ़ने की बात है जिसमें “हर code const context में चल सके”

concurrency को सरल बनाना - Simpler concurrency

• मौजूदा Rust का async model ‘static bound, cancellation-safety, trait restrictions जैसी जटिलताओं के कारण वास्तविक काम में कठिनाई पैदा करता है
• पुराने user-space green thread (libgreen) की तरह language-level पर सरल concurrency की आवश्यकता है

और अधिक domains में प्रतिस्पर्धी बनना - Excelling in more domains

• Rust का web browser के भीतर उपयोग (खासकर wasm/rustwasm) अभी भी काफी हद तक अनछुआ है, और cross-browser stack trace जैसी कई चुनौतियां बाकी हैं
  • leptos, sycamore जैसे frameworks लगातार आगे बढ़ रहे हैं, लेकिन अभी भी सुधार की गुंजाइश है
• rapid prototyping, business logic, GUI, machine learning, game development जैसे वे domains जिनमें Rust अभी पूरी तरह नहीं छाया है, उनमें भी लगातार सुधार होने की उम्मीद है

निष्कर्ष

• Rust की वृद्धि का भविष्य बहुत स्पष्ट और आशाजनक है
• अपनाने का दायरा बढ़ने के साथ engineering/testing क्षमता भी बढ़ती है, और उससे व्यापक adoption व सुधार का एक सकारात्मक चक्र बनता है
• आने वाले 10 वर्षों में तेज़ compilation, विभिन्न क्षेत्रों में उपयोग, और अधिक सहज developer experience वास्तविकता बन सकते हैं
• Rust के नए 10 वर्षों को लेकर उत्साह है

[ndrgrd]

Rust में सब कुछ अच्छा है, लेकिन यह भाषा बहुत ज़्यादा अपेक्षाएँ रखती है।
Rust का उपयोग करते समय ऐसा लगता है कि विचार को लागू करने पर ध्यान देने के बजाय मैं Rust नाम की भाषा का ही अध्ययन कर रहा हूँ।

अगर C++ से माइग्रेट करना हो, यानी पहले से बने प्रोजेक्ट को स्थानांतरित करना हो, तो शायद कोई खास दिक्कत नहीं होगी,
लेकिन नए आइडिया को लागू करने के लिए इसका उपयोग करना सुविधाजनक है या नहीं, इस बारे में मुझे पक्का नहीं लगता।

[felizgeek]

प्रोटोटाइपिंग के लिए मैं Python recommend करता हूँ

[ndrgrd]

मुझे व्यक्तिगत रूप से type system पसंद है, इसलिए इस समय मैं C# इस्तेमाल कर रहा हूँ, और मुझे लगता है कि इस स्तर पर यह संतोषजनक है।

[codemasterkimc]

व्यक्तिगत तौर पर अगर पृथ्वी के पर्यावरण के बारे में सोचें, तो RUST. Legacy Spring कोड को Axum में !!!

[GN⁺]

Hacker News राय

• यह बहुत सकारात्मक लेख है और मेरे अनुभव से भी मेल खाता है। लेकिन अगर किसी नकारात्मक पहलू की बात करूँ, तो वह यह होगा:
  "async में static bound, cancellation safety, trait और dyn से जुड़ी सीमाओं आदि की वजह से अपेक्षाकृत अधिक complexity cost है। फिलहाल इस समस्या के हल होने के संकेत नहीं दिखते। synchronous/asynchronous primitives के बीच bifurcation और ecosystem की अंतर्निहित विशेषताएँ async tax (अतिरिक्त लागत) को बढ़ाती हैं। Effects-आधारित समाधान भी खास उम्मीद नहीं जगाते।"
  "Rust 1.0 से पहले libgreen नाम का एक समाधान था। यह bifurcation के बिना user-space में concurrency लागू करता था, लेकिन performance, portability और maintenance cost काफी अधिक होने के कारण अंततः हटा दिया गया। मेरा मानना है कि अगर पर्याप्त engineering क्षमता हो तो इसे फिर से विचार करने लायक है। कभी न कभी मैं std::{fs, net} और fiber::{spawn, select} को generator के साथ zero-cost wrapping करने वाला एक PoC बनाना चाहूँगा"
  • यह राय भी है कि "'static bound complexity बढ़ाता है" वाली चर्चा Tokio async runtime की design choice है, इसे Rust की पूरी design कहना उचित नहीं होगा। Embassy async runtime ऐसे bound के बिना भी काम करता है, लेकिन उसके बदले pinning को खुद संभालना पड़ता है। 'static bound का उद्देश्य वास्तव में complexity कम करना है
• 2022 के अंत में Rust में गहराई से रुचि लेकर इसे पढ़ने वाले व्यक्ति के तौर पर, 2015 जैसे और कठिन दौर में इस भाषा को सीखने वालों के अनुभव हमेशा दिलचस्प लगते हैं। मैं खुद को भाग्यशाली मानता हूँ कि Rust को उसके अधिक mature होने के बाद सीख पाया, इसलिए इसकी पहले से ही steep learning curve कुछ हद तक नरम हो चुकी थी। आजकल मुझे लगता है कि लेख में बताए गए शुरुआती Rust के अनुभव मैं Zig में फिर से जी रहा हूँ। Zig अभी Rust के शुरुआती दौर जैसी स्थिति में लगता है। फिर भी मैं इसे पहले से ही मज़े से इस्तेमाल कर रहा हूँ
  • "जिसे पाया उससे बेहतर स्थिति में छोड़ो" वाली संस्कृति बहुत मजबूत है। अगर tool या language ने भ्रम पैदा किया, तो गलती user की है—ऐसा नहीं माना जाता। अगर मुझे confusion हुआ है, तो और लोगों को भी होगा, इसलिए हर बार उसे बेहतर बनाना सबके लिए बड़ा लाभ है। इस पर वह कहावत लागू होती है कि पेड़ लगाने का दूसरा सबसे अच्छा समय आज है। इसी संस्कृति की वजह से, जिसने पहले Rust आज़माया और निराश हुआ, उसे एक साल बाद कहीं बेहतर अनुभव मिल सकता है। इसलिए Rust beginner को देने वाली सबसे अच्छी सलाह थी: "6 महीने इंतज़ार करके देखो"
  • अगर कोई भाषा MSFT, Google जैसी big tech कंपनियों या Linux जैसे बड़े open source projects में अपनाई गई है, तो यह इस बात का प्रमाण है कि उसका ecosystem पर्याप्त रूप से mature है। लेकिन Zig के बारे में ऐसी निश्चितता नहीं है, क्योंकि उसने अभी तक मौजूदा tools की तुलना में कोई (बड़ा) बदलाव दिखाया नहीं है
• मुझे लगता है Rust functional programming को प्रोत्साहित करता है। शुरुआत में मैं एक parser बना रहा था जो हर advance पर internal state बदलता था, लेकिन mutability और borrowing system के कारण दिक्कत हुई, इसलिए मुझे उसे stateless parser में बदलना पड़ा। internal index बदलने के बजाय index वापस करने वाली संरचना अपनानी पड़ी। क्या Rust में अक्सर ऐसा होता है कि पारंपरिक तरीका काम नहीं करता और नई तरह से सोचना पड़ता है?
  • मेरा अनुभव भी कुछ ऐसा ही है। साधारण मामलों में mutable, imperative style से भी काम चल जाता है, लेकिन जैसे-जैसे complexity बढ़ती है, मैं functional style की तरफ जाता हूँ और mutation को जितना हो सके टालता हूँ। Borrow checker और lifetime की वजह से पारंपरिक patterns मुश्किल हो जाते हैं और स्वाभाविक रूप से functional दिशा में जाना पड़ता है। अगर functional तरीके से implement करना सहज न हो तो यह कठिन लग सकता है, लेकिन compiler को संतुष्ट करना ज्यादा आसान महसूस होता है
• Async/await ही एकमात्र वजह है कि मैं Rust का इस्तेमाल नहीं करता
  • सच कहूँ तो async/await Rust इस्तेमाल करने की मुख्य वजहों में से एक है। यह concurrency patterns को बहुत सरल बना देता है। शुरुआत में ऐसा लगा था जैसे कोई बुरी संक्रामक बीमारी हो, जहाँ अंततः हर code को async बनना पड़ता है, लेकिन जब async code के साथ interact करना सीख लिया तो यह सहज हो गया। आम तौर पर spawn, spawn_blocking, futures::stream ही 90% उपयोग में आते हैं, और अगर सही तरह से "boundary" तय कर दी जाए तो async को हर जगह फैलने की जरूरत नहीं होती
  • मैं कुछ हद तक समझ सकता हूँ। लेकिन मेरे लिए Rust में async/await बहुत स्वाभाविक बैठता है, इसलिए यह इसका सबसे बड़ा उपयोग-कारण है। मुझे इसका syntax भी पसंद है और function colouring की समस्या भी खास परेशान नहीं करती। खासकर tokio के साथ, ज़रूरी standard functions के async versions उपलब्ध हैं, इसलिए समाधान अच्छा फिट बैठता है। यह कुछ लोगों के लिए barrier हो सकता है, लेकिन concurrency programs लिखना बहुत आसान हो जाता है और performance भी ठीक मिलती है, इसलिए मैं संतुष्ट हूँ। cancellation जैसी चीज़ों में कभी-कभी उलझन होती है, लेकिन उसे मैं अपनी skill की कमी मानता हूँ
  • क्या अब तक लगभग सब कुछ उपलब्ध नहीं है?