Rust का मूल

 (jyn.dev)
36 पॉइंट द्वारा GN⁺ 2025-08-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust एक ऐसी भाषा है जिसमें कई कॉन्सेप्ट एक-दूसरे से गहराई से जुड़े हुए हैं, इसलिए बेसिक प्रोग्राम को समझने के लिए भी कई चीज़ें एक साथ सीखनी पड़ती हैं
  • function, generic, enum, pattern matching, trait, reference, ownership, Send/Sync, Iterator आदि सभी परस्पर interaction को ध्यान में रखकर डिज़ाइन किए गए मुख्य तत्व हैं
  • JavaScript की तुलना में, JS में कुछ कॉन्सेप्ट जानकर भी कोड लिखा जा सकता है, लेकिन Rust में भाषा के पूरे संदर्भ को समझने पर ही वास्तव में अर्थपूर्ण कोड लिखना संभव होता है
  • Rust की यही जटिलता सीखने की बाधा को बढ़ाती है, लेकिन साथ ही safety और consistency भी देती है, और कोड डिज़ाइन करने के तरीके पर बड़ा प्रभाव डालती है
  • ऐसी भाषाई संरचना Rust को खास बनाती है, और “smaller Rust” की विज़न हमें सटीक रूप से जुड़े हुए language philosophy पर फिर से सोचने के लिए प्रेरित करती है

Rust सीखने की कठिनाई

  • Rust में entry barrier ऊँचा है, फिर भी बहुत से लोगों ने documentation, API, diagnostic improvements में योगदान दिया है
  • बुनियादी कॉन्सेप्ट में first-class functions, enum, pattern matching, generic, trait, reference, borrow checker, concurrency safety, iterator आदि शामिल हैं
  • ये कॉन्सेप्ट एक-दूसरे पर निर्भर और गहराई से जुड़े हुए हैं, इसलिए इन्हें एक-एक करके अलग से सीखना कठिन है, और standard library भी अधिकांशतः इन्हीं फीचर्स का उपयोग करती है
  • लगभग 20 लाइनों के Rust कोड को समझने के लिए भी functional paradigm, Result और error handling, generic types, enum, iterator जैसे कई तत्वों को एक साथ समझना पड़ता है

Rust और JavaScript की तुलना

  • जब एक ही file change detection प्रोग्राम Rust और JS में लिखा जाता है, तो Rust में भाषा के कई कॉन्सेप्ट आपस में गुँथे हुए दिखाई देते हैं
  • JS में मूल रूप से सिर्फ function और null handling समझकर भी काम करने वाला कोड लिखा जा सकता है
  • इसका मतलब यह नहीं कि Rust बस अधिक कठिन है, बल्कि यह दिखाता है कि Rust ऐसा डिज़ाइन है जो पूरी भाषा की संरचनात्मक समझ की माँग करता है

Rust का परस्पर जुड़ा हुआ डिज़ाइन

  • Rust का मूल ऑर्गेनिक तरीके से डिज़ाइन किए गए फीचर्स के संयोजन में है
    • enum, pattern matching के बिना असुविधाजनक है, और pattern matching भी enum के बिना सीमित हो जाती है
    • Result और Iterator को generic के बिना implement करना संभव नहीं है
    • Send/Sync कॉन्सेप्ट और println की constraints को trait के बिना सुरक्षित रूप से व्यक्त नहीं किया जा सकता
    • borrow checker, closure capture analysis के माध्यम से Send/Sync safety की गारंटी देता है
  • यह परस्पर जुड़ाव Rust को सिर्फ फीचर्स के संग्रह के बजाय एक एकीकृत language system बनाता है

छोटे Rust की विज़न

  • 2019 में without.boats ने “Smaller Rust” का ज़िक्र करते हुए छोटे और परिष्कृत Rust की संभावना पर चर्चा की थी
  • आज Rust बहुत बड़ा हो चुका है, लेकिन छोटे Rust की अवधारणा अब भी सटीक रूप से आपस में फिट होने वाले language design के सार की याद दिलाती है
  • Rust का आकर्षण इस बात में है कि भाषाई तत्व आपस में स्वतंत्र होते हुए भी, साथ आने पर मज़बूत expressiveness और safety प्रदान करते हैं

निष्कर्ष

  • Rust सीखना कठिन है, लेकिन आपस में जुड़े कॉन्सेप्ट की consistency और integration इसकी बड़ी ताकत है
  • इसी संरचना की वजह से Rust डेवलपर को सिर्फ कोड लिखने तक सीमित नहीं रखता, बल्कि safety और performance दोनों को साथ लेकर सोचने का तरीका विकसित करता है
  • Rust का सार “छोटी लेकिन सटीक मुख्य भाषा” में है, और यह आज के विस्तारित Rust में भी एक महत्वपूर्ण philosophy बना हुआ है

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

1 टिप्पणियां

 
GN⁺ 2025-08-23
Hacker News राय
  • यह विडंबनापूर्ण लगता है कि एक "सरल" JS प्रोग्राम में भी बग हैं। fs.watch के docs में साफ़ लिखा है कि callback में filename null हो सकता है, इसलिए इसे ज़रूर check करना चाहिए। Rust में यह बात type system में दिखती और आपको इसे अनिवार्य रूप से handle करना पड़ता, लेकिन JS में कोड को ढीले-ढाले तरीके से लिखना आसान है। संबंधित docs
    • अगर TypeScript इस्तेमाल करें तो null check enforce होता है। इसलिए मुझे लगता है कि यह एक अच्छा उदाहरण है कि TS, JS में Rust जैसी correctness के काफ़ी करीब पहुँचने वाला, comparatively कम बोझ वाला कदम है
    • एक अतिरिक्त बग भी है: for path in paths की जगह for (const path of paths) होना चाहिए। JS में parentheses न हों तो तुरंत error आ जाएगा, लेकिन in और of का फ़र्क यह है कि in values नहीं बल्कि indices (iterable index) पर iterate करता है, इसलिए असल में index string में बदलकर fs.watch के पहले argument में चला जाएगा। TypeScript भी शायद इस गलती को पकड़ न पाए
    • जैसा बताया गया, loop syntax ही गलत है, और इसे चलाकर देखो तो तुरंत पता चल जाता है। यानी बेहतर यही मानना चाहिए कि लेखक ने उस JS कोड को ध्यान से नहीं लिखा, क्योंकि वह मुख्य तर्क के लिए बहुत मायने नहीं रखता था
    • शायद मैं चूक गया, लेकिन kind कहाँ से आया, यह जानना चाहूँगा। console.log("${kind} ${filename}") में kind नहीं, eventType (string) होना चाहिए
  • एक छोटा-सा technical point रखना चाहूँगा। Rust का println सिर्फ़ उन्हीं types को print कर सकता है जो Display या Debug trait implement करते हैं। इसलिए Path को सीधे print नहीं किया जा सकता। हर OS path को UTF-8 में नहीं रखता, जबकि Rust के string types पूरी तरह UTF-8 हैं। यानी Path को print करने में lossy conversion हो सकता है। Path का display method ऐसा type लौटाता है जो Display implement करता है। Rust ने इसे type system में समाहित किया है, लेकिन JS/TS में यह बताना मुश्किल है कि internal string UTF-16 है, और non-Unicode path को सही तरह handle करने के लिए सीधे TextEncoder/Decoder इस्तेमाल करने पड़ते हैं। पुराने अनुभव से कहूँ तो जब server Shift_JIS में text भेजता था और उसे response.text() से पढ़ते थे, तो runtime में सिर्फ़ empty string मिलती थी। अगर आपको encoding issues की आदत न हो, तो ऐसी स्थिति में debugging में कई दिन निकल सकते हैं। और JS example में ऐसे bugs और syntax errors हैं जो Rust code में नहीं हैं (loop में for-in की जगह for-of चाहिए)। इस example को सिर्फ़ "first-class functions" का मामला कहना ठीक नहीं होगा; Rust की तरह iterators की समझ भी चाहिए, और इसमें CommonJS भी इस्तेमाल हो रहा है। साथ ही async/await, Promises और top-level await भी अलग से सीखने पड़ते हैं, और top-level await को node सहित कुछ runtimes ने हाल में ही support किया है। अभी भी कुछ JS engines (जैसे React Native का Hermes) में यह supported नहीं है

    • यही वजह है कि मैं Rust इस्तेमाल करता रहता हूँ। यह example तो बस एक है, लेकिन ऐसी छोटी-छोटी समस्याएँ और pitfalls दूसरी भाषाओं में हर जगह बिखरी रहती हैं। वे अलग-अलग होकर शायद न दिखें, लेकिन पूरे program lifecycle में जमा होकर अजीब bugs पैदा करती रहती हैं, और आपको लगातार उन्हें ढूँढना पड़ता है। Rust में ऐसा नहीं होता। इसका type system बेहिसाब मामलों को पहले ही रोक देता है। सच में, जब आप Rust में feature-complete software ship कर देते हैं, तो उसके बाद सिर्फ़ कभी-कभार features जोड़ते हैं और सामान्य bug-fixing का काम लगभग ग़ायब हो जाता है। हाँ, logical bugs कहीं भी हो सकते हैं, लेकिन दूसरी भाषाओं की तरह बेवकूफ़ी भरी type/structure mismatch से पैदा होने वाली समस्याएँ Rust जड़ से रोक देता है, इसलिए productivity और maintainability का अनुभव पूरी तरह अलग होता है

    • निजी तौर पर मुझे लगता है कि JS/TS में thenable/Promise और async-await को सच में ठीक से समझने वाले developers बहुत ज़्यादा नहीं हैं। ऐसा भी देखा है:

      var fn = async (param) => new Promise((res, rej) => {
  fooLibraryCall(param).then(res).catch(rej);
});

      callback-style wrapper को वैसे का वैसा Promise में लपेटकर फिर async function के अंदर दोबारा इस्तेमाल किया जाता है। हर बार यह देखकर दिल टूट जाता है। सच में ऐसी code patterns बहुत जगह देखी हैं। और अगर modules के import, async import(), transpilation, code splitting वगैरह तक सोचें, तो चीज़ें सच में बहुत जटिल हो जाती हैं

  • मुझे लगता है कि Bjarne का quote असल में C++ के लगातार बिगड़ते जाने को बार-बार justify करने वाली sales pitch है। शुरू में शायद यह ईमानदार रहा हो, लेकिन अब यह एक recurring pattern बन गया है। मेरी नज़र में इसकी संरचना कुछ ऐसी है:
    1. "C++ के अंदर एक छोटा और साफ़-सुथरा language है"
    2. लेकिन language का subset निकालना संभव नहीं, इसलिए पहले superset (ज़्यादा features वाला) बनाते हैं और फिर बाद में subset करेंगे
    3. वह superset नए C++N+1 में चला जाता है। फिर असली subset discussion को अगली बार के लिए टाल दिया जाता है, और यही चक्र दोहरता है
    4. C++N+1 और जटिल हो जाता है, और यह सिलसिला हमेशा चलता रहता है जिन्होंने यह pattern बार-बार देखा है, उन्हें समझ नहीं आता कि लोग अब भी क्यों टिके हुए हैं। आख़िरकार वह "छोटी और साफ़ भाषा" कभी आती ही नहीं। हमेशा step one ही दोहराया जाता है
    • यह मुझे xkcd 927 की याद दिलाता है। C++ standard हर बार और जटिल होता जा रहा है; अच्छे बदलाव होते हैं, लेकिन वे पुराने versions से हमेशा अच्छी तरह मेल भी नहीं खाते, और source code लगातार ज़्यादा बिखरा हुआ लगता है। मैं दो OSS libraries maintain करता हूँ, लेकिन अब लगभग उनका इस्तेमाल नहीं करता। आजकल सोचता हूँ कि और कितने समय तक इससे चिपका रहूँ। Rust, c++11/14/17/20 से आने के बाद सच में ताज़गी देता है। हालाँकि Rust भी, अगर पूरा जानना चाहो, तो काफ़ी विशाल है। इस पोस्ट में उठाए गए points बहुत सटीक लगे
  • क्या किसी और का भी shebang (self-executing rust scripts) देखते ही ध्यान भटक गया था? जब मैंने पहले Go में यही चीज़ देखी थी, तब की तरह हैरानी हुई। काफ़ी उपयोगी लगती है और basic उपयोगों के लिए पर्याप्त हो सकती है। मैंने Rust से build/test pipelines manage करने वाले project में कुछ ऐसा देखा भी है। ऐसे काम के लिए यह अच्छा विकल्प हो सकता है। लेकिन आम तौर पर अगर मुझे bash से थोड़ा आगे का scripting चाहिए होता है, तो मैं Deno+TS इस्तेमाल करता हूँ। JS के साथ मेरा सबसे लंबा अनुभव है (28 साल), उसके बाद C# (24 साल)। Node को शुरुआती दिनों से इस्तेमाल कर रहा हूँ। package sharing/centralization के लिहाज़ से Deno, Node या Python से आसान manage होता है। cargo frontmatter भी कुछ ऐसा ही करता है
    • cargo में script integration को design/implement करने वाला मैं ही था (हालाँकि third-party implementations पहले भी काफ़ी थे)। इसे real-world use में देखकर बहुत खुशी हो रही है, और इसका ज़िक्र देखना अच्छा लगा। docs भी देखें। किस shape में यह ठीक रहेगा, भाषा के साथ इसका integration कैसा हो, और first release का scope क्या हो—इन सब पर लंबी चर्चा हुई थी। अभी style guide और Rust reference के updates जैसे finishing touches चल रहे हैं, और बचे हुए बड़े काम हैं rustfmt, rust-analyzer से जुड़े details, rustc के bug fixes, और Cargo की error reporting को बेहतर बनाना। मैं खुद रोज़ issue reproduction scripts लिखने के लिए cargo script इस्तेमाल करता हूँ
    • मैं सच में -Zscript feature keyword search करके research शुरू करते-करते भटक गया था। यह 2023 से चल रहा है, और कुछ open issues देखकर लगता है कि यह लगभग पूरा होने के करीब है। ZomboDB repository में भी Rust से build pipeline संभालते देखा, लेकिन पूरा context नहीं समझ पाया। मैं यह भी कहना चाहता हूँ कि cargo frontmatter script portability के लिए बेहद उपयोगी है। सिर्फ़ एक file share करनी होती है, और Python या Node.js की तरह अलग से install/init किए बिना dependencies लेकर तुरंत इस्तेमाल किया जा सकता है
    • किसी ने कहा कि Go में भी यही किया जा सकता है; क्या कोई विस्तार से समझा सकता है? अगर यह लिंक वही है, तो मुझे भी दिलचस्पी है
    • JS और C# को लंबे समय तक इस्तेमाल करने वाले व्यक्ति के तौर पर कहूँ, तो 2025 में उस वजह से कोई system चुनना मुझे ठीक नहीं लगता। पिछले 20 सालों में बहुत-सी चीज़ें काफ़ी बेहतर हो चुकी हैं
    • यह बस Unix की बुनियादी सुविधा है। #!/some/path से शुरू होने वाली file को shell बस दिए गए command के साथ पूरे file content को stdin के रूप में पास करके चलाता है
  • Rust के बारे में जब कहा जाता है कि "उसके भीतर से एक छोटा और साफ़ language उभर रहा है", तो मैं जानना चाहता हूँ कि वह language है क्या। पोस्ट पढ़ने पर लगता है कि references, lifetimes, traits, enums वगैरह सब बने रहने चाहिए, और फिर यह लगभग Rust से अलग नहीं बचता। आख़िरी हिस्से में "वह Rust जिसे मैं लिखना चाहता हूँ" और "पुराना Rust" जैसी दो hints मिलती हैं, लेकिन वे बहुत स्पष्ट नहीं लगतीं। मैंने withoutboats का "Notes on a smaller Rust" भी पढ़ा, लेकिन उसका design goal Rust से अलग है; वह Rust बनने की कोशिश नहीं करता, बल्कि यह दिखाता है कि नई language design करते समय Rust से क्या lessons लिए जा सकते हैं। वह Rust बनना चाहने वाली language नहीं, बल्कि "mainstream" ज़रूरतों के हिसाब से बनाई गई language का उदाहरण है (जैसे GC, compile/syntax simplification आदि)। दूसरी बात, पोस्ट में यह भी कहा गया है कि "2018 में जब मैंने पहली बार सीखा था, वही भाषा वह 'छोटा Rust' थी जिससे मुझे प्यार हुआ"—लेकिन सच यह है कि 2018 के बाद Rust बुनियादी तौर पर बहुत नहीं बदला। edition changes जैसी ज़्यादातर चीज़ें syntax flexibility की improvements हैं, और सच में बड़े अपवाद सिर्फ़ async और const हैं। अगर बात यह है कि async और const आने से पहले Rust छोटा और साफ़ था, तो उसे सीधे कहना चाहिए था; अफ़सोस कि लेख में यह इतनी स्पष्टता से नहीं कहा गया
    • अगर "छोटा और साफ़ Rust" की बात करें, तो Austral एक उदाहरण के तौर पर याद आता है
    • कुछ लोग यह भी कहते हैं कि Rust के core concepts को बनाए रखते हुए उससे सरल (छोटी) language संभव है। उदाहरण के लिए Copy trait, reborrowing, deref coercion, loops में automatic into_iter, scope ख़त्म होने पर automatic drop calls (इसे सीधे call भी कराया जा सकता है या compiler error दे सकता है), trait bounds में default :Sized, lifetime elision, match ergonomics जैसी कई automation/convenience चीज़ें हटा दी जाएँ तो एक यांत्रिक रूप से बहुत सरल Rust बन सकता है। लेकिन ऐसी language रोज़मर्रा के काम में बेहद असुविधाजनक होगी। विडंबना यह है कि ऊपर की कई चीज़ें असल में beginners की मदद के लिए बनाई गई थीं
    • मैंने इसे बहुत ध्यान से पढ़ा। असल में मेरा मतलब भी यही था कि async और const से पहले वाला Rust छोटा और साफ़ था। मैंने इसे सीधे इसलिए नहीं कहा क्योंकि उन features पर काम करने वाले कई लोग मेरे दोस्त हैं। Matklad ने lobste.rs पर इसे बहुत अच्छी तरह कहा है। 2015 का Rust ज़्यादा complete और consistent था, लेकिन Rust का vision पूरी coherence नहीं, बल्कि industry में उपयोगी language बनना है
  • मैं पक्षपाती हो सकता हूँ, लेकिन मुझे Rust सबसे perfect के करीब language लगती है। borrow checker झुंझलाहट पैदा कर सकता है, लेकिन यह ज़रूरी है। यही buggy code अगर C में होता, तो runtime crash हो जाता—आख़िरकार bug तब भी ठीक करना पड़ता। फ़र्क सिर्फ़ इतना है कि Rust आपको compile से पहले ही bug ठीक करने पर मजबूर करता है, जबकि C में आप आधी रात को outage संभाल रहे होते हैं। Rust मुश्किल नहीं, बल्कि अलग तरह की thinking shift माँगता है। सुरक्षित और security-focused code लिखने के paradigm shift की ज़रूरत है। बदलाव अक्सर असुविधाजनक होता है, और शायद Rust के प्रति resistance की जड़ यही है
    • Rust perfect से काफ़ी दूर है
      • मुझे लगता है compiler को यह तय करने की बहुत ज़्यादा आज़ादी है कि Deref कब और किस क्रम में apply होगा। .into() और From trait type conversions को बहुत छिपे हुए ढंग से संभालते हैं। standard library में भी ऐसी कई "convenience" functions हैं। नतीजा यह होता है कि object का type धुंधला हो जाता है, और function calls को implementations से जोड़कर समझना मुश्किल होता है (हालाँकि IDE मदद करे तो कुछ आसानी होती है)
      • implicit return program flow को छिपाता है और गलतियाँ बुलाता है। question-mark operator भी मुझे बहुत पसंद नहीं
      • Rust modules को बहुत छोटे-छोटे हिस्सों में बाँट देता है, इसलिए कुछ उपयोगी करने के लिए सैकड़ों dependencies चाहिए होती हैं। stable build के लिए सबको अलग से manage और vendor करना पड़ता है, जो काफ़ी असुविधाजनक है
      • Async Rust इस समय पूरी तरह chaos है
    • असली शिकायत borrow checker से नहीं, बल्कि इस बात से ज़्यादा है कि Rust का पूरा "ढाँचा" बहुत बड़ा हो गया है। 2018 के उस rough, somewhat incomplete Rust को पसंद करने वालों (मैं भी उनमें हूँ) के लिए आज का Rust पहले जैसा आकर्षक नहीं रहा। हाँ, जब आप इसे अच्छे से इस्तेमाल करना सीख लेते हैं तो यह बेहद ताकतवर है, लेकिन तब सवाल उठता है कि क्या यह मेहनत वाकई worth it है। 2025 में अगर C/C++ का विकल्प चुनना हो, तो मैं शायद Zig चुनूँगा (एकमात्र अपवाद Postgres का काम है; pgrx ecosystem सच में अलग दर्जे का है)। फिर भी, C में काम करने से तो कुछ भी बेहतर है
  • मुझे नहीं लगता कि Rust को पहली programming language के रूप में recommend करना चाहिए। पहली language सीखना वैसे ही मुश्किल होता है, और Rust में compiler errors की वजह से code को लगभग पूरी तरह सही बनाए बिना उसे चलाकर देखना भी कठिन हो सकता है। यह बहुत frustrating है और लोग आसानी से हार मान सकते हैं। मेरी सलाह होगी कि Python, JavaScript या Lua से शुरू करें, जल्दी से game जैसी चीज़ बनाकर iteration करें
    • मेरा अनुभव अलग है। हमारी कंपनी में एक ML engineer था जिसे सिर्फ़ Python आती थी, लेकिन वह Rust codebase में contribute करना चाहता था। मैंने उसे लगभग एक घंटे basics समझाए और वह बहुत जल्दी adapt कर गया; उसकी productivity भी तुरंत बढ़ गई। सच कहें तो game बनाते समय अगर आप किसी string को number function में पास करके crash करा दें, तो कारण ढूँढने में बहुत समय चला जाता है। Rust में compiler सीधे बता देता है कि "यहाँ string है, int होना चाहिए", इसलिए debugging जल्दी पूरी हो जाती है। पूरा दिन compiler errors से जूझने के बजाय, runtime errors में एक हफ़्ता बर्बाद नहीं होता
    • ब्लॉग के सबसे ऊपर quote में जो व्यक्ति है, वह मैं ही हूँ। मैंने 400 से ज़्यादा लोगों को Rust उनकी पहली language के रूप में सिखाई है, इसलिए इस thread की बातें मुझे काफ़ी दिलचस्प लगती हैं। लंबे समय के direct experience से मुझे सिर्फ़ संभावना नहीं, बल्कि यह भी काफ़ी सबूत मिला है कि यह approach अच्छी तरह काम कर सकती है
    • मैं अब भी पूरी तरह आश्वस्त नहीं हूँ। मैं देखना चाहूँगा कि कोई अच्छा educator Rust को पहली language के रूप में सिखाने की कोशिश करे। पीढ़ी बदल रही है और universities में Python ज़्यादा चल रही है, लेकिन सिद्धांततः Rust पहली language के रूप में पूरे cohort का स्तर ऊपर उठा सकती है (हालाँकि fail rate बहुत बढ़ जाए तो administrative problem बन सकती है; दूसरी तरफ़ advanced students ज़्यादा सीख सकते हैं)। जैसे move assignment या const keyword के अर्थ जैसी चीज़ें Rust में सीखना बाद में दूसरी भाषाओं से आई गलत आदतों को छोड़ने की मेहनत भी कम कर सकता है
    • आम तौर पर मैं पहली language के रूप में static typing से बचने की सलाह दूँगा। मुझे static typing पसंद है, लेकिन beginners के लिए यह अक्सर बेवजह confusion बढ़ाती है। compiler errors अक्सर counterfactual होते हैं, और "compiler यह साबित नहीं कर पाया कि यह none नहीं है" जैसे messages, test case में runtime crash की exact location मिलने की तुलना में कहीं ज़्यादा कठिन लगते हैं। ज़्यादातर समस्याएँ बस line-by-line values print करके जल्दी समझी जा सकती हैं, लेकिन compiler की जटिल errors में फँस जाएँ तो बहुत देर तक रास्ता नहीं मिलता
    • Rust अपने-आप में बुरी language नहीं है, बशर्ते आप एक साथ बहुत कुछ absorb कर सकें। समस्या यह है कि कोई language ऐसे नहीं सीखता, और जब तक main concepts की अच्छी समझ न हो, Rust में बार-बार trial-and-error करना पड़ता है। और अंत में इसमें ऐसे concepts भी बहुत हैं जो दूसरी भाषाओं में कभी नहीं सीखे, इसलिए नई भाषा में जाते समय फिर से frustration हो सकती है
  • मैंने जो "simple Rust" जैसा सबसे क़रीबी उदाहरण देखा है, वह Gleam है। लगता है यह Rust से काफ़ी inspired है
    • यह कहना कि Gleam, Rust से inspired है, एक ग़लतफ़हमी है। इसके creator ने आधिकारिक रूप से ऐसा नहीं कहा। compiler भले Rust में लिखा गया हो, लेकिन Gleam का paradigm और target runtime पूरी तरह अलग हैं, इसलिए यह Rust का विकल्प नहीं है
    • अगर कोई और 'simple rust' style देखना चाहता है, तो मैं fsharp देखने की भी सलाह दूँगा
    • Gleam की main page पर Black rights, trans rights और anti-Nazi messages हैं, इसलिए मुझे इस language में कोई दिलचस्पी नहीं है
    • क्या Gleam में 3D बनाया जा सकता है?
  • मुझे यह बात खटकी कि "Rust program क्या करता है, यह समझाया ही नहीं गया"। बहुत भारी technical explanation है, लेकिन program असल में क्या करता है, इसका कोई summary नहीं। वास्तव में वह सिर्फ़ file changes detect करके print करता है। Rust में इतना simple काम भी implementation को जटिल बना देता है, क्योंकि आपको असली समस्या से सीधे जुड़े बिना भी कई internal details का ध्यान रखना पड़ता है। मेरी नज़र में यही उस language की कठिनाई को अच्छी तरह दिखाता है—यह सामने आने वाली चुनौती भी है और ख़ुद बनाई गई बाधा भी
    • दूसरी भाषाओं में भी यही समस्या है, लेकिन Rust आपको इसे पहले ही handle करने में मदद करता है। हर filename print करने लायक नहीं होता, और ज़्यादातर भाषाएँ यह हिस्सा user पर छोड़ देती हैं। Rust return type के ज़रिए errors/failures को साफ़ दिखाता है, जबकि दूसरी भाषाओं में exception handling जैसी दूसरी mechanisms चाहिए होती हैं। ऊपर से simple दिखने पर भी, वास्तव में Rust वाला तरीका ज़्यादा सहज हो सकता है
    • implementation भी, सच कहें तो, high-performance language के हिसाब से बहुत simple है। यह एक पेज में समा जाता है। क्या इस स्तर का example काफ़ी simple नहीं है?
    • सरल explanation = सरल implementation, यह हमेशा सही नहीं होता। इसका अच्छा उदाहरण xkcd 1425 है। (जैसे: यह जाँचना आसान है कि फोटो किसी national park के अंदर ली गई थी या नहीं, लेकिन यह पहचानना कि वह पक्षी की फोटो है या नहीं, उसके लिए research team चाहिए)
  • मुझे Rust semantic रूप से काफ़ी consistent और cohesive लगता है। दूसरी भाषाओं की तुलना में इसमें syntactic sugar जैसी चीज़ें कम हैं, इसलिए यह ज़्यादा intuitive लगता है। लगभग सभी interfaces आम तौर पर mem module pattern का पालन करते हैं, इसलिए interface structure को अच्छे से समझना हो तो std::mem से शुरू करना बेहतर होगा