21 पॉइंट द्वारा tsboard 2024-07-24 | 5 टिप्पणियां | WhatsApp पर शेयर करें

मैं लगभग 10 साल से Rust का इस्तेमाल कर रहा हूँ, और मुझे यह भाषा सच में बहुत पसंद है। लेकिन इसके कुछ निराशाजनक पहलू भी हैं। नीचे उनकी सूची है।

1. Result<T, E> की समस्या

Rust में error handling का स्पष्ट और अनिवार्य होना शानदार है। लेकिन असल इस्तेमाल में यह कई बार असुविधाजनक लगता है।

  • लाइब्रेरी लेखकों की मुश्किलें: नया error type बनाना और उसे convert करना झंझटभरा है। हर बार dependency जोड़ने पर हर function के error type को wrapper error type में जोड़ना खास तौर पर परेशान करता है।
  • एप्लिकेशन कोड की झंझट: function क्यों fail हुआ, इससे ज़्यादा महत्वपूर्ण यह होता है कि error को ऊपर propagate किया जाए और user को नतीजा दिखाया जाए। Java के विपरीत, Rust propagation के दौरान backtrace नहीं देता, इसलिए समस्या की जड़ समझना कठिन हो जाता है।

2. मॉड्यूल सिस्टम की लचीलापन

Rust का मॉड्यूल सिस्टम इतना ज़्यादा flexible है कि कई बार यह उल्टा असुविधाजनक हो जाता है।

  • अत्यधिक लचीलापन: type को re-export करना या access level को बारीकी से समायोजित करना संभव है, लेकिन इससे गलती से ऐसे type expose हो सकते हैं जिन्हें बाहर नहीं आना चाहिए।
  • orphan rule की समस्या: project को कई crate में बाँटना recommended है, लेकिन orphan rule कभी-कभी रास्ते में बाधा बनता है।

3. compile time और IDE tools

Rust का compile time और IDE tools की error checking बहुत धीमी है।

  • लंबा compile time: बड़े project में एक function बदलने पर पूरा crate फिर से compile हो जाता है, जो बहुत inefficient है।
  • धीमी IDE response speed: Rust analyzer ऐसा महसूस कराता है मानो हर keypress पर पूरे project को फिर से index कर रहा हो, और बड़े project में यह खास तौर पर समस्या बन जाता है।

निष्कर्ष

Rust मेरी सबसे पसंदीदा भाषा है, लेकिन इसके ये निराशाजनक पहलू भी मौजूद हैं। मैं जानना चाहता हूँ कि क्या दूसरे users भी यही समस्याएँ झेल रहे हैं।

5 टिप्पणियां

 
ranolp 2024-07-28

Error handling के मामले में, लाइब्रेरी के लिए snafu/thiserror और application के लिए eyre/anyhow इंस्टॉल करके इस्तेमाल करना सुविधाजनक हो जाता है।

 
y15un 2024-07-26

लाइब्रेरी लेखक की कठिनाइयाँ: [..snip..] हर बार जब आप कोई dependency जोड़ते हैं, तो हर function के error type को wrapper error type में जोड़ना खास तौर पर बहुत झंझटभरा होता है.

यह बात सच में बहुत गहराई से महसूस होती है। crate-विशेष error enum बनाना और dependency से आने वाले error types के लिए हर बार impl From<ExtError> for Error लिखते हुए 'कितनी झुंझलाहट है' ऐसा मैंने एक-दो बार नहीं, बल्कि कई बार सोचा है...

 
eususu 2024-07-26

शायद मैं अभी तक ठीक से शुरुआत नहीं कर पाया हूँ, इसलिए ऐसी निराशा महसूस करके देखना चाहूँगा।
अच्छा लेख, धन्यवाद~

 
undercat 2024-07-25

अच्छे लेख के लिए धन्यवाद!

 
tsboard 2024-07-24

लंबे compile time के बारे में नीचे दिया गया कमेंट मददगार हो सकता है, इसलिए इसे जोड़ रहा/रही हूँ: (by pr4wl)

अगर Rust analyzer हर बदलाव पर लंबा recompilation कर रहा है, तो संभवतः इसका कारण यह है कि application build करते समय इस्तेमाल होने वाले features या environment variables अलग हैं। डिफ़ॉल्ट रूप से RA build artifacts को स्टोर करने के लिए cargo build जैसी ही target directory का उपयोग करता है, और अगर आप एक-दूसरे के साथ compatible न होने वाले build चला रहे हैं, तो यह बार-बार पूरा build करता रहेगा।

यह समस्या खास तौर पर Bevy में अक्सर हो सकती है, जब build में bevy/dynamic_linking feature इस्तेमाल किया जाता है लेकिन Rust analyzer में नहीं।

सबसे आसान समाधान है कि RA को अलग target directory इस्तेमाल करने के लिए कहा जाए। इससे जुड़ी अधिक जानकारी rust-analyzer.cargo.targetDir में देखी जा सकती है।

एक और समाधान यह है कि सभी features और environment variables एक जैसे सेट किए जाएँ, ताकि वे एक-दूसरे के build artifacts को फिर से इस्तेमाल कर सकें। हालांकि, यह थोड़ा पेचीदा हो सकता है.