Rust की learning curve को समतल करने की गाइड

(corrode.dev)

38 पॉइंट द्वारा GN⁺ 2025-05-14 | 4 टिप्पणियां | WhatsApp पर शेयर करें

Rust एक ऐसी भाषा है जो पूरी तरह नई सोच की मांग करती है, और mindset सीखने की गति पर बड़ा असर डालता है
compiler के साथ सहज होना सबसे महत्वपूर्ण है; error message को सिर्फ ठीक करना नहीं, बल्कि उसके कारण को समझने का दृष्टिकोण ज़रूरी है
शुरुआत में clone(), unwrap आदि का खुलकर उपयोग करके छोटे से शुरू करना और धीरे-धीरे refactor करना बेहतर है
हाथ से बहुत सारा code लिखते हुए गलतियों और trial-and-error के जरिए intuition और muscle memory बनानी चाहिए
Rust की विकास-दर्शन type system-केंद्रित है, इसलिए documentation ध्यान से पढ़ना और types के साथ modeling का अभ्यास करना ज़रूरी है

Flattening Rust's Learning Curve

Rust को सीखना कठिन माना जाता है, लेकिन यह लेख लेखक के अनुभव के आधार पर Rust को अधिक प्रभावी ढंग से सीखने के लिए mindset और approach पर ठोस सलाह देता है

Let Your Guard Down

Rust मौजूदा भाषाओं से अलग mental model की मांग करता है
कभी-कभी शुरुआती लोग experts से भी तेज़ सीख लेते हैं → रवैया और openness ही कुंजी है
borrow checker को दुश्मन नहीं, सह-लेखक की तरह देखना चाहिए, और error messages को समझने की कोशिश करनी चाहिए
compiler lifetime parameters क्यों मांगता है, इसे गहराई से समझने का रवैया महत्वपूर्ण है
जितना code बदसूरत और जटिल दिखे, उतनी ही संभावना है कि design गलत हो, इसलिए इसे बेहतर तरीका खोजने का संकेत मानना चाहिए
Rust की verbosity बड़े ऐप्स में मदद करती है और refactoring के लिए फायदेमंद होती है
clippy lints को शुरुआत से ही पूरी तरह चालू करके इस्तेमाल करना चाहिए

Baby Steps

शुरुआत में String, clone(), unwrap का खुलकर उपयोग करें; बाद में refactor करना बिल्कुल ठीक है
जटिल method chains की बजाय सरल if, match statements से शुरू करें
async को पहले हफ्ते में टालना बेहतर है
छोटे code snippets को Rust Playground में प्रयोग करके सीखें
हर concept के लिए एक main.rs file पर अभ्यास करें, और ज़्यादातर code को फेंक देने लायक अभ्यास मानकर लिखें

Be Accurate

Rust में सटीकता survival condition है
typo या छोटी गलती भी तुरंत compile error बन सकती है, इसलिए सावधानी ज़रूरी है
&, mut को अपने-आप जोड़ने की आदत मददगार हो सकती है
Tsoding जैसे developers की streaming videos अच्छे reference material हैं

Don’t Cheat

LLM और code autocomplete पर निर्भर रहने से सीखना धीमा पड़ता है
खुद हाथ से type करने और समझ न आए तो docs देखने की आदत डालनी चाहिए
auto-pilot mode में coding न करें
गलतियों को स्वीकारें, और उनके जरिए compiler के काम करने का तरीका समझें
code चलाने से पहले यह अनुमान लगाने का अभ्यास भी करें कि क्या यह compile होगा
दूसरों के code को पढ़ने और विश्लेषण करने की आदत भी महत्वपूर्ण है
सीखते समय बाहरी crates का उपयोग सीमित रखें, serde, anyhow जैसे कुछ अपवाद छोड़कर

Build Good Intuitions

lifetime, ownership जैसे concepts को visual तरीके से समझना मददगार होता है
excalidraw जैसे tools से data flow, architecture आदि खुद बनाकर देखने की आदत सुझाई जाती है
कई बेहतरीन engineers और mathematicians भी visualization tools का अच्छा उपयोग करते हैं

Build On Top Of What You Already Know

Rust परिचित concepts में भी अलग तरह से काम करता है (जैसे mut, value move आदि)
फिर भी मौजूदा भाषाओं के साथ तुलना करके सीखना उपयोगी है

उदाहरण:

Trait → Interface जैसा, लेकिन बिल्कुल वही नहीं
Struct → inheritance के बिना class जैसा एहसास
Closure → lambda के समान
Module → namespace
Borrow → single-owner pointer
Option → Maybe monad
Enum → Algebraic data type

Rosetta Code कई भाषाओं के बीच code तुलना से सीखने के लिए उपयोगी है
किसी परिचित भाषा के code को Rust में port करके सीखना भी असरदार है
list comprehensions, loops जैसी language idioms को Rust में कैसे व्यक्त किया जाए, इस पर सोचना भी अच्छा अभ्यास है

Don’t Guess

Rust अनुमान से नहीं चलने वाली भाषा है
"hello".to_string() जैसे code को क्यों लिखना पड़ता है, इस कारण पर विचार करें
error messages बहुत उपयोगी होते हैं, इसलिए उनमें छिपे संकेतों को कभी नज़रअंदाज़ न करें
खासकर borrow-checker से जुड़े errors में data flow को हाथ से trace करके विश्लेषण करना चाहिए

Lean on Type-Driven Development

Rust एक type system-केंद्रित भाषा है
function signatures, type definitions आदि से बहुत-सी जानकारी मिल सकती है
standard library की docs और source को बार-बार पढ़ें
पहले types design करना और फिर उसी के अनुरूप code लिखना ज़्यादा सटीक और reusable structure बनाने में मदद करता है
invariants को types में व्यक्त करने से गलत code शुरू से ही compile नहीं होता

Invest Time In Finding Good Learning Resources

Rust सीखने की सामग्री अभी बहुत अधिक नहीं है, इसलिए शुरुआत में अपने लिए सही resources ढूँढना समय बचाने के लिए महत्वपूर्ण है
Rustlings जैसे learning tools पसंद-नापसंद के हिसाब से अलग अनुभव दे सकते हैं
Advent of Code, Project Euler जैसे problem-solving आधारित resources ज़्यादा उपयुक्त हो सकते हैं
YouTube videos को जानकारी से ज़्यादा entertainment के रूप में इस्तेमाल करें
किताब खरीदकर, ऑफलाइन पढ़ते हुए और खुद code लिखते हुए सीखना सबसे असरदार तरीका है
अगर संभव हो, तो किसी expert की training या coaching लेना भी लंबी अवधि में बड़ा समय बचा सकता है

Find A Coding Buddy

किसी कुशल साथी के code को shadowing की तरह फॉलो करते हुए देखना भी फायदेमंद है
Rust forum, Mastodon आदि पर code review माँगकर या खुद review करके भी कौशल बढ़ाया जा सकता है

Explain Rust Code To Non-Rust Developers

जो लोग Rust नहीं जानते, उन्हें समझाकर देखना भी सीखने में असरदार है
open source projects के unmaintained code में योगदान देना भी सुझाया गया है
Rust की terminology को अपने work-domain की language से map करके glossary बनाना भी अच्छा है

Believe In The Long-Term Benefit

Rust short-term productivity से अधिक long-term quality के लिए बनी भाषा है
एक दिन में expert बनना मुश्किल है, लेकिन एक महीने तक ध्यान से सीखने पर बहुत कुछ पाया जा सकता है
Rust एक ‘Day 2 language’ है; पहला दिन कठिन हो सकता है, लेकिन लगातार इस्तेमाल करने पर इसकी कीमत बढ़ती जाती है
सफल होने के लिए इसे सिर्फ resume के लिए नहीं, बल्कि programming से सचमुच प्यार होना चाहिए

4 टिप्पणियां

aer0700 2025-05-17

पहले मैंने सीखने के मकसद से C में पहले लिखे गए कोड को Rust में दोबारा लिखने की कोशिश की थी, लेकिन pointers को संभालना बहुत ही कष्टदायक अनुभव था... rc या refcell जैसी चीज़ों के काम करने का तरीका दिमाग में ठीक से बैठ नहीं पाया था...

q8840 2025-05-15

बेसिक docs और Nomicon को एक-एक बार क्रम से पढ़ने के बाद मुझे Rust में कभी अटकना नहीं पड़ा, इसलिए सोचता हूँ कि क्या इसकी learning curve सच में इतनी ऊँची है।

freedomzero 2025-05-15

अरे, अगर unwrap और clone की आदत पड़ गई तो बाद में ownership की वजह से बहुत तकलीफ़ होगी, हाय...

GN⁺ 2025-05-14

Hacker News राय

यह “A Discipline of Programming” पढ़ने जैसा लगता है। Dijkstra की नैतिक-शैली वाली व्याख्या पहले ज़माने में शायद इसलिए ज़रूरी थी क्योंकि लोग प्रोग्रामिंग कॉन्सेप्ट्स को ही ठीक से नहीं समझते थे। Rust में ownership की व्याख्या अक्सर बहुत ज़्यादा लंबी होती है। ज़रूरी कॉन्सेप्ट्स ज़्यादातर मौजूद होते हैं, लेकिन उदाहरणों के नीचे छिपे रहते हैं। Rust में हर data object का ठीक एक owner होता है। इस ownership को इस तरह आगे सौंपा जा सकता है कि हर समय सिर्फ़ एक ही owner रहे। अगर कई owners चाहिए हों, तो असली owner एक reference-counting cell होना चाहिए। इस cell को clone किया जा सकता है। जब owner ख़त्म हो जाता है, तो उसके owned objects भी ख़त्म हो जाते हैं। ref का इस्तेमाल करके किसी data object तक पहुँच अस्थायी रूप से borrow की जा सकती है। Ownership और reference साफ़ तौर पर अलग चीज़ें हैं। References को pass और store किया जा सकता है, लेकिन वे उस object से ज़्यादा देर तक जीवित नहीं रह सकते। वरना “dangling pointer” error होता है। इन नियमों को compile time पर borrow checker सख़्ती से लागू करता है। यही Rust का ownership model है। इसे समझ लेने पर सारी बारीकियाँ आख़िरकार इन्हीं नियमों पर आ टिकती हैं।
- पता नहीं सिर्फ़ मुझे ऐसा लगता है या नहीं, लेकिन इस तरह की conceptual explanation के साथ चलना मुश्किल होता है। Encapsulation के साथ भी यही लगा था। बस इतना कहते हैं कि information को hide किया जाता है, लेकिन यह concretely कैसे/क्यों होता है, उसमें नहीं जाते। उदाहरण के लिए, Rust में owner आख़िर है कौन, यह समझ नहीं आता। क्या stack frame owner है? LIFO structure के हिसाब से ownership callee को क्यों देनी है? callee का stack तो पहले मिट जाएगा, तो क्या उसमें ख़तरा नहीं होना चाहिए? अगर optimization के लिए है, तो क्या object को जल्दी साफ़ करने के लिए? और अगर owner stack frame नहीं है, तो फिर वह कौन है, यह भी स्पष्ट नहीं। यह भी उलझन है कि mutable reference सिर्फ़ 1 बार ही क्यों दी जा सकती है। Single-threaded environment में तो वैसे भी एक function के ख़त्म होने से पहले दूसरा शुरू नहीं होता, तो दोनों को mutable reference मिल जाए तो भी ठीक लगना चाहिए। अगर समस्या सिर्फ़ multi-threaded environment में आती है, तो वहीं error दे दिया जाए, ऐसा नहीं हो सकता? इन्हीं सवालों की वजह से Rust पढ़ते-पढ़ते मैं बार-बार छोड़ देता हूँ।
- यह ownership की explanation नहीं, बल्कि motivation देने वाली explanation है। सबसे कठिन और सबसे अहम हिस्सा यह है कि function signatures में जब lifetimes जटिल रूप से उलझे हों, तो उन्हें कैसे पढ़ा जाए, और ऐसे function calls पर आने वाले compiler errors को कैसे समझकर ठीक किया जाए।
- जो लोग ये concepts पहले से जानते हैं, उनके लिए सही और परिपूर्ण लगने वाला summary बनाना, किसी नए learner को समझाने से कहीं ज़्यादा आसान है। अगर इस तरह समझाया जाए, तो क्या कोई ऐसा व्यक्ति जो अब तक सिर्फ़ call-by-sharing इस्तेमाल करता रहा हो, तुरंत समझ जाएगा? मुझे नहीं लगता।
- जिसे Rust नहीं आता, वह यह summary पढ़कर भी Rust के बारे में कुछ नहीं समझेगा। बस यही लगेगा कि “इस language में compiler के अंदर जैसे कोई black magic भरी हुई है।”
- Ownership और borrowing का concept अपने-आप में समझना आसान है। Rust सच में मुश्किल इसलिए है क्योंकि function signatures और actual usage code को मिलकर यह साबित करना पड़ता है कि reference object से ज़्यादा देर तक नहीं जीएगा। वैसे, referenced objects को types में store न करना बेहतर विकल्प है, क्योंकि इससे proof कम जटिल होता है।
- मैं काफ़ी समय से ऐसे लेख ढूँढ रहा था जो बताएँ कि 60s के लोग assembly level पर system/application state को कैसे संभालते थे। सुना था कि Sutherland की Sketchpad paper में data structures पर काफ़ी detail है, लेकिन मैंने सिर्फ़ chapter 2-3 ही पढ़े हैं।
- यह explanation मुझे meaningful नहीं लगती। इसमें ownership और borrowing को साफ़ तौर पर define नहीं किया गया। दोनों ही ऐसे शब्द लगते हैं जो financial asset management की किसी metaphor पर आधारित हों। मुझे Rust नहीं आता, लेकिन लगता है कि ऐसे शब्दों का चुनाव ही concept को समझना कठिन बना देता है। Metaphors अक्सर दोधारी तलवार होती हैं। शायद ज़्यादा सीधे memory-related terms में समझाना मददगार होगा।
- Model की explanation में exclusive/shared, या mutable/immutable, borrowing का महत्वपूर्ण फ़र्क़ पूरी तरह छोड़ दिया गया है। Rust ने यह तय करने में बहुत से choices किए हैं कि ऐसे borrows को कैसे allow किया जाए, और यह सहज नहीं है। उदाहरण के लिए, no aliasing rule intuition से नहीं, बल्कि function optimization के उद्देश्य से आया है। Borrowing में सबसे जटिल बात यह है कि lifetime elision rules की वजह से compiler error messages कभी-कभी असली कारण की बजाय किसी और जगह इशारा करते हैं। ये elision rules सहज नहीं हैं; इन्हें simplification के लिए चुना गया था।
- Brown University का rust book का revised version borrow checker को वाक़ई बहुत अच्छी तरह समझाता है।
- Explanation अधूरी लगती है। उदाहरण के लिए, borrowed side के ख़त्म हो जाने पर क्या होता है, इस बारे में कुछ नहीं कहा गया।
- “असली owner एक reference-counting cell होना चाहिए” कहा गया, लेकिन यह ऐसे समझाया गया है जैसे सुनने वाला पहले से जानता हो कि उसका मतलब क्या है।
- अपना borrow checker ख़ुद implement करने पर ही borrow checker सच में समझ आता है।
- दूसरे section की दूसरी item बहुत ज़्यादा बढ़ा-चढ़ाकर कही गई है। असल में ऐसे बहुत से cases हैं जहाँ Rust compile नहीं करता, जबकि code सुरक्षित होता है। यह जटिलता इसलिए आई है ताकि compiler क्या साबित कर सकता है, उसकी सीमाएँ साफ़ हो सकें।
Rust का ownership model, lifetimes, enum, और pattern matching पहली बार में बेहद भारी लगे थे। पहली कोशिश में मैं बहुत जल्दी overwhelmed हो गया था, और दूसरी कोशिश में किताब की हर लाइन पढ़ने की कोशिश करते-करते धैर्य जवाब दे गया। उसी दौरान मुझे समझ आया कि Rust ऐसी language है जो programming और software design के बारे में गहरी insight देती है। तीसरी कोशिश में जाकर मैंने अपने पहले लिखे छोटे programs और scripts को Rust style में फिर से लिखते हुए सीखना शुरू किया, और उसी दौरान Rust-style error handling, types का सक्रिय उपयोग करके data को express करना, pattern matching वगैरह भी सीखा। इस अनुभव के बाद मुझे यक़ीन हो गया कि Rust सीखना मेरी programmer life के सबसे अच्छे फ़ैसलों में से एक था। Types, structs, और enum पहले से define करना, और immutable data व pattern matching के आधार पर functions लिखना अब दूसरी languages में भी मुझे स्वाभाविक लगता है।
- मेरा अनुभव भी मिलता-जुलता था। Rust तीसरी बार सीखते हुए जाकर चीज़ें सच में समझ आने लगीं, और मैं कुछ programs को प्रभावी ढंग से लिख पाने लगा। लंबे programming career के बावजूद कभी-कभी बार-बार सीखना पड़ता है। पहले JVM dependency injection framework Dagger को समझने में भी मुझे ठीक 3 बार कोशिश करनी पड़ी थी। शायद जटिल चीज़ें सीखते समय यह मेरे साथ बार-बार होने वाला pattern है।
- C++ developers जब पहली बार Rust सीखते हैं तो यह अक्सर दिखता है: C++ की सोच से काम करोगे तो “borrow checker” से लगातार लड़ाई होगी। लेकिन Rust की conventions ठीक से सीख लो, तो वही conventions बाद में C++ में भी लेकर जा सकते हो और ज़्यादा robust code लिख सकते हो, भले ही C++ में borrow checker न हो।
“Compile करने से पहले पूरे code को ध्यान से पढ़कर typos ठीक कर लो, तो अनुभव बेहतर होगा” — यह सलाह मुझे अजीब लगती है। Rust compiler अपने बहुत helpful error messages के लिए मशहूर है, तो फिर मुझे typos ढूँढने के लिए code को घूरते क्यों रहना चाहिए? मैं चाहता हूँ कि computer मेरी typos पकड़ ले।
- cargo fix कुछ समस्याएँ अपने-आप ठीक कर देता है, लेकिन सब नहीं।
“विरोध मत करो”, “सीखने के लिए अहंकार छोड़ो”, “हार मानने की घोषणा ज़रूरी है”, “resistance is futile, जितनी जल्दी स्वीकारोगे उतना कम कष्ट होगा”, “जो जानते हो उसे भूल जाओ” जैसी सलाहें दी गई हैं। यह देखकर लगा कि Orwell का telescreen OS शायद Rust में लिखा गया होगा।
- मैं इससे सहमत हूँ। Rust सीखते समय मेरी सबसे बड़ी ग़लती यह थी कि मैं object-oriented paradigm के हिसाब से Rust को ज़बरदस्ती चलाने की कोशिश कर रहा था। जैसे ही मैंने मान लिया कि चलो Rust जिस तरह चाहता है उसी तरह करके देखते हैं, चीज़ें तुरंत बेहतर चलने लगीं।
Rust beginners के लिए काफ़ी बड़ा hurdle है। यह दूसरी languages से बहुत अलग है — जानबूझकर, लेकिन उसी वजह से entry barrier भी है। Syntax जटिल है और बहुत condensed है, कभी-कभी ऐसा लगता है जैसे keyboard पर कोहनी मार दी गई हो। एक character पूरा अर्थ बदल सकता है, और nesting भी बहुत होती है। कई features ऐसे हैं जिन्हें theoretical background के बिना समझना मुश्किल है, इसलिए complexity और बढ़ जाती है। Type system और borrowing mechanism इसके बड़े उदाहरण हैं। एक सामान्य Python या JavaScript user के लिए यह लगभग alien language जैसी है। ऐसे दौर में जब अधिकांश programmers के पास practically master's-level CS background नहीं होता, Rust शायद उपयुक्त नहीं लगती। ऊपर से macros इसे और जटिल बना देते हैं। अगर उनकी definition नहीं पता हो, तो code का मतलब समझना मुश्किल हो जाता है। हाल में मुझे उम्मीद हुई है कि LLMs इस barrier को कम कर सकते हैं। अभी तक मुझे Rust सीखने की ज़रूरत महसूस नहीं हुई, लेकिन LLMs की वजह से कभी भविष्य में फिर कोशिश करने का मन हो सकता है। Rust सच में अनोखे ढंग से कठिन language है।
- Rust सीखते समय मेरे लिए सबसे मुश्किल चीज़ macros ही थे। जिन materials का मैंने इस्तेमाल किया, उन्होंने बिना explanation के शुरुआती हिस्से में macros ला दिए, जिससे काफ़ी confusion हुआ।
मुझे लगता है कि हर स्थिति में Rust से बेहतर कोई न कोई विकल्प होगा। फिर भी मैं open-minded हूँ। अगर कभी Rust काफ़ी आम हो जाए, तब शायद इसका मतलब बने।
- अगर लगभग 20 साल पहले Rust को उसी मूल उद्देश्य के लिए डिज़ाइन किया गया था, तो browser को शुरू से फिर से बनाने के लिए यह एकदम उपयुक्त language है। अब तो इस क्षेत्र में Rust पहले ही dominant है। और language creator का “unix” दुनिया पर छा गया था; किसी के बनाए Ladybird जैसी चीज़ उससे कभी replace नहीं हुई।
अगर किसी language के लिए लोगों को मेहनत करके उसे सीखने के लिए मनाने वाले लेख तक चाहिए, तो क्या यह शक नहीं होना चाहिए कि समस्या language design में ही है? (मैंने Rust सीखी नहीं है, इसलिए इसे बहुत गंभीरता से न लिया जाए।)
- तुम्हारी comment को मैं बस “जो कठिन है, वह करने लायक नहीं” के रूप में ही पढ़ पा रहा हूँ। हर चीज़ के trade-offs होते हैं। क्या सिर्फ़ downside होने का मतलब यह है कि कोशिश भी न की जाए? अगर कोई harp बजाने की कठिनाई पर उत्साह से लिखे, तो क्या इसका मतलब है कि harp बजाना ख़राब hobby है?
- Senior developer बनने तक कई बार ऐसा होता है कि Rust जिन lessons को बहुत महत्व देता है, उन्हें लोग किनारे-किनारे देख चुके होते हैं, पर सच में महसूस नहीं किया होता। बहुत लोग सोचते हैं, “मैं तो पहले से garbage-collected language इस्तेमाल करता हूँ, Rust मुझे नया क्या सिखाएगा?” असल में mutability और shared references के उलझने पर बहुत बड़ा confusion पैदा होता है, इसलिए लोग immutable objects ज़्यादा इस्तेमाल करने लगते हैं। फिर immutable objects होने पर दोबारा यह सोचना पड़ता है कि इन्हें सुविधाजनक रूप से बदला कैसे जाए, और कभी-कभी वे mutable objects से कम usable लगते हैं। “यह object कभी mutable है और कभी immutable” जैसी बात express करने की कोशिश करते-करते आख़िर borrow checker की ज़रूरत सामने आती है। Borrow checker आ जाए, तो फिर सवाल बचता है: “तो फिर garbage collection की ज़रूरत क्यों है?” आख़िरकार लोग garbage collection इसलिए इस्तेमाल करते हैं क्योंकि object lifetimes को साफ़-साफ़ समझना झंझट लगता है। Rust आपको इन बुनियादी सवालों का सामना सीधे कराता है।
- Rust के design decisions कई बार समझना कठिन होते हैं। Mojo में भी borrow checker है, लेकिन वह Rust से काफ़ी आसान लगता है, और इसकी वजह कुछ choices हैं। पहली है value semantics। Rust में beginners को अक्सर हर समय clone() इस्तेमाल करने को कहा जाता है, जबकि आम static languages (C, C++, Go आदि) में value semantics सामान्य आधार होती है। दूसरी बात, Mojo में lifetimes यह तय नहीं करतीं कि value scope के हिसाब से usable है या नहीं, बल्कि यह तय करती हैं कि deletion कब होगा। अगर references बचे हों, तो lifetime बढ़ जाती है, और उपयोग ख़त्म होते ही deletion हो जाता है। इसलिए Mojo में “value ज़्यादा देर तक नहीं जीती” जैसे errors से नहीं जूझना पड़ता। सिर्फ़ इन दो design choices से ही बोझ काफ़ी कम हो जाता है।
- Beginners के लिए कोई भी language कठिन हो सकती है, इसलिए Rust को अलग से विशेष नहीं कहा जा सकता। Programming में learning curve तो होता ही है।
- मुझे लगता है कि ऐसे लेख language से ज़्यादा लेखक के बारे में बताते हैं। यह लेखक की आलोचना नहीं है; मुझे अच्छा लगता है कि कोई इस तरह अपना उत्साह साझा करे।
- यह लेख Rust किन समस्याओं को हल करती है, इस पर कम और learning curve पर ज़्यादा लगता है। किसी को यह तय करना हो कि कोशिश करनी चाहिए या नहीं, तो दोनों पक्षों का संतुलित विवरण ज़रूरी है।
- Rust पर design debate तो बहुत हो सकती है, लेकिन सिर्फ़ यह तथ्य कि इस तरह का लेख मौजूद है, अपने-आप में Rust language का फ़ैसला नहीं कर देता। उल्टा, मुझे लगता है Python ऐसी language है जिसे ऐसे लेखों की और ज़्यादा ज़रूरत है। जैसे-जैसे non-engineering background वाले programmers बढ़ते जा रहे हैं, Python paradoxically ऐसी language है जिसे लगभग कोई भी इस्तेमाल कर सकता है, जबकि Rust ऐसी है जिसे हर कोई नहीं। कुछ लोगों के लिए Rust, C या Zig जैसी languages की तुलना में कहीं आसान है। मुझे Python भी पसंद है, लेकिन मैं मानता हूँ कि बुनियादी तौर पर यह एक भयानक language है। LLM के दौर में भी लोग optimized Python इस्तेमाल करना ज़्यादा नहीं जानते। हमारे AI दोस्त भी अगर निर्देश न दिए जाएँ, तो बस inefficient Python ही बनाते रहेंगे।
- “क्या यह language design की समस्या नहीं?” इस सवाल पर मेरा जवाब है: “क्यों?”
- Rust सीखने वाले के रूप में कहूँ तो, भले ही आप मुख्यतः Python ही इस्तेमाल करते हों, मैंने Rust में कोई language flaw महसूस नहीं किया। उल्टा, यह इतनी strict language है कि अगर आप इसे बार-बार un-Rusty बनाने की कोशिश करेंगे, तो बस मुश्किल बढ़ेगी। Rust style में काम करो, तो complexity बढ़ने के साथ यह और मददगार होती जाती है। दूसरी languages में errors runtime पर एक-एक करके सामने आते हैं, जबकि Rust compile time पर काफ़ी कुछ पकड़ लेती है। हाँ, logical errors को यह नहीं रोकती, लेकिन testing integration बहुत मज़बूत है, इसलिए उनसे निपटा जा सकता है। Downsides हैं, फिर भी Rust को कम-से-कम एक बार सीखना ज़रूर चाहिए। Errors कम करने के लिए Rust ने जो तरीका चुना है, उससे दूसरी languages में भी अच्छे development habits सीखे जा सकते हैं।
- सच है कि Rust इतनी जटिल है कि LLM के लिए सही Rust code पहली ही बार में बनाना मुश्किल होता है। फिर भी मुझे यह JavaScript या दूसरी weakly typed/dynamic languages की कई समस्याओं से बेहतर लगता है।
- मैंने Rust सीखी है और मैं तुम्हारी बात से सहमत हूँ। Rust सच में complex है और “committee-designed” language जैसी लगती है। Tooling बढ़िया है, और यह C++ से कम जटिल है, लेकिन सीखने में आसान बिल्कुल नहीं।
- ऐसे लेखों की समस्या यह है कि वे मूल बात तक नहीं पहुँचते। Rust में कुछ programs ऐसे होते हैं जिन्हें लिखने की अनुमति ही नहीं है। इसके अच्छे कारण हैं, लेकिन यह बात लगभग उन सभी languages से बुनियादी रूप से अलग है जिन्हें ज़्यादातर लोग इस्तेमाल करते आए हैं। साफ़ है कि कुछ programs Rust में लिखे ही नहीं जा सकते, इसलिए इसे स्वीकार करना पड़ेगा; वरना Rust आपके लिए उपयुक्त नहीं है।
Rust सीखने का एक कम चर्चित तरीका यह है कि पहले language का सिर्फ़ एक subset सीखा जाए। उदाहरण के लिए, मेरी Rust introductory book lifetimes को शुरू में सिखाती ही नहीं। Lifetimes के बिना functions के साथ भी पर्याप्त काम करने वाले programs लिखे जा सकते हैं। Macros के साथ भी यही है — आसान तो नहीं, लेकिन फिर भी पहले subset सीखना चाहिए। और मेरा मानना है कि शुरुआत से ही copy() या clone() पर निर्भर रहने के बजाय borrowing को पहले सीखना बेहतर है। Borrowing ही इस language का केंद्र है।
Rust सीखने का एकमात्र तरीका यह होगा कि 300k डॉलर से ज़्यादा salary वाली नौकरियाँ बड़ी संख्या में आने लगें। मुझे यह भी लगता है कि भविष्य में Rust quant क्षेत्र में C++ की जगह लेने की क्षमता रखती है। लेकिन OCaml पहले से मौजूद है, और अगर मुझे इतनी कठिन और जटिल language सीखनी ही पड़े, तो पहले पैसे दिखने चाहिए। अब तक सबसे ज़्यादा salary वाली नौकरियाँ Python की रही हैं।
इन comments को देखकर मुझे समझ आया कि पुराने programmers को जब टोका जाता है, तो वे अक्सर कैसी प्रतिक्रिया देते हैं। जितने लंबे समय तक काम करो, उतना ज़िद्दी होना आसान हो जाता है। हर किसी को अपने-आप से पूछना चाहिए कि वे compiler के सुझावों का विरोध क्यों कर रहे हैं। आप अलग क्या करना चाहते हैं, और आपको क्या रोक रहा है — इसे सीधे जाँचकर देखना चाहिए।