वास्तविक CLI टूल डेवलपमेंट में Zig, Rust से ज़्यादा व्यावहारिक क्यों लगता है

 (dayvster.com)
6 पॉइंट द्वारा GN⁺ 2025-09-27 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • मेमोरी मैनेजमेंट में Zig, Rust की तुलना में अधिक सरल और सहज तरीका प्रदान करता है
  • Rust का borrow checker शक्तिशाली है, लेकिन छोटे CLI टूल डेवलपमेंट में यह अनावश्यक जटिलता और डेवलपर पर अतिरिक्त बोझ पैदा कर सकता है
  • Zig का मैनुअल मेमोरी मैनेजमेंट सही टूल्स और थोड़े से डेवलपर अनुशासन के साथ प्रभावी मेमोरी सुरक्षा सुनिश्चित कर सकता है
  • प्रोग्राम की सुरक्षा में सिर्फ मेमोरी सुरक्षा ही नहीं, बल्कि पूर्वानुमेय व्यवहार, प्रबंधनीय प्रदर्शन, और डेटा सुरक्षा जैसे कई तत्व महत्वपूर्ण हैं
  • Rust बड़े सिस्टम के लिए उपयुक्त है, लेकिन छोटे व्यावहारिक CLI टूल्स के लिए डेवलपमेंट प्रोडक्टिविटी और मेंटेनेंस के लिहाज़ से Zig अधिक फायदेमंद है

अवलोकन

हाल के समय में CLI टूल बनाते समय मैं Rust की बजाय Zig को प्राथमिकता दे रहा हूँ

मेमोरी मैनेजमेंट की बुनियाद: स्टैक और हीप

  • स्टैक फ़ंक्शन पैरामीटर, लोकल वेरिएबल, रिटर्न एड्रेस जैसी बहुत अस्थायी डेटा को स्टोर करने वाला तेज़ और फिक्स्ड-साइज़ मेमोरी क्षेत्र है
  • हीप डायनेमिक मेमोरी अलोकेशन के लिए क्षेत्र है, और इसका उपयोग तब होता है जब डेटा की लाइफ़टाइम लंबी हो या उसका आकार रनटाइम पर तय हो
  • स्टैक संरचनात्मक रूप से सरल है, लेकिन इसमें स्पेस सीमित होता है; वहीं हीप में स्पीड और फ्रैगमेंटेशन के संदर्भ में अधिक ध्यान देना पड़ता है

Rust का Borrow Checker

  • Rust का borrow checker compile time पर मेमोरी सुरक्षा सुनिश्चित करता है
  • यह references, ownership, और lifetime जैसे नियम लागू करके null pointer dereference, dangling pointer जैसी त्रुटियों को पहले से रोकता है
  • लेकिन मेमोरी सुरक्षा की जाँच केवल compile time के आधार पर होती है, और यह उपयोगकर्ता की गलती या जटिल ownership डिज़ाइन की समस्याओं को पूरी तरह खत्म नहीं कर पाता

उदाहरण: मेरा अपना Notes CLI

  • जब मैंने पर्सनल नोट मैनेजमेंट के लिए CLI को Rust में लिखने की कोशिश की, तो borrow checker की वजह से मुझे संरचना को काफ़ी मेहनत से फिर से डिज़ाइन करना पड़ा
  • दूसरी ओर, Zig में सिर्फ allocator का उपयोग करके pointer-आधारित index बनाना और स्वतंत्र रूप से बदलाव/डिलीट करना कहीं अधिक सरल था
  • Rust का borrow checker अपने उद्देश्य में स्पष्ट है, लेकिन Zig में बुनियादी मेमोरी मैनेजमेंट ज्ञान और अनुशासन के सहारे भी उच्च स्तर की दक्षता और सुरक्षा हासिल की जा सकती है

जब मेमोरी सुरक्षा ही CLI टूल की पूरी सुरक्षा नहीं होती

  • किसी प्रोडक्ट की वास्तविक सुरक्षा में पूर्वानुमेय व्यवहार, त्रुटि होने पर अर्थपूर्ण फ़ीडबैक, संवेदनशील डेटा की सुरक्षा, और हमले सहने की क्षमता जैसे कई तत्व शामिल होते हैं
  • Rust हो या Zig, अगर वे मेमोरी सुरक्षा के अलावा इन शर्तों को पूरा नहीं करते, तो उन्हें वास्तव में "सुरक्षित" नहीं कहा जा सकता
  • उदाहरण के लिए, अगर कोई CLI त्रुटि की स्थिति में चुपचाप डेटा ओवरराइट कर दे या फ़ाइल परमिशन गलत सेट कर दे, तो उपयोगकर्ता को गंभीर समस्या हो सकती है

  • CLI टूल की सुरक्षा

    • पूर्वानुमेय व्यवहार: गलत इनपुट या अप्रत्याशित परिस्थिति में भी एकसमान और स्पष्ट व्यवहार की गारंटी होनी चाहिए
    • क्रैश और डेटा करप्शन की रोकथाम: errors को सहजता से handle करना चाहिए, और डेटा करप्शन या अघोषित क्रैश से बचना चाहिए
    • परफॉर्मेंस मैनेजमेंट: बड़े पैमाने पर डेटा प्रोसेस करते समय भी संसाधन खपत या responsiveness में गिरावट नहीं आनी चाहिए
    • संवेदनशील जानकारी की सुरक्षा: temporary files और permission settings पर ध्यान देना ज़रूरी है
    • हमलों के प्रति मजबूती: input validation, memory overflow, injection attacks आदि के खिलाफ़ मज़बूती होनी चाहिए

Rust Borrow Checker की ताकत और सीमाएँ

  • ताकत

    • data race और duplicate reference को रोकना: compiler single mutable reference और multiple immutable references के नियम को सुनिश्चित करता है
    • मज़बूत compile-time गारंटी: अधिकांश मेमोरी-संबंधी बग्स को execution से पहले ही रोक दिया जाता है
    • शुरुआती चरण में bug detection: commercial services या concurrency systems में यह बड़ा फायदा देता है

  • सीमाएँ और असुविधाएँ

    • cognitive overhead: छोटे CLI कामों में भी ownership/lifetime/reference मैनेजमेंट पर सोचना अनिवार्य हो जाता है
    • boilerplate/संरचनात्मक विकृति: Rc, RefCell जैसे wrappers, clone का ज़रूरत से ज़्यादा उपयोग, और संरचना का पुनः डिज़ाइन—इन सबके कारण ध्यान "समस्या समाधान" से हटकर "compiler को संतुष्ट करने" पर चला जाता है
    • logical/state bugs के सामने सीमित: यह केवल मेमोरी नियम सुनिश्चित करता है, लेकिन पूर्वानुमेयता, लॉजिक त्रुटियाँ, या data integrity की गारंटी नहीं देता
    • edge case complexity: cache, global state, mutable index जैसी स्थितियों में lifetime conflict आसानी से उत्पन्न हो सकता है
  • नतीजतन, छोटे CLI प्रोजेक्ट्स में Rust का borrow checker डेवलपर के लिए एक "मानसिक टैक्स" बन जाता है, और चीज़ों को वास्तविक ज़रूरत से ज़्यादा जटिल बना सकता है

Zig का सुरक्षा और सरलता वाला दृष्टिकोण

  • Zig वैकल्पिक safety checks और मैनुअल मेमोरी मैनेजमेंट पर आधारित है
  • इसमें allocator की अवधारणा बिल्ट-इन है, जिससे संरचित और पूर्वानुमेय मेमोरी उपयोग को लागू किया जा सकता है
  • आप custom allocator भी बना सकते हैं और अपने प्रोजेक्ट की विशेषताओं के अनुसार मेमोरी मैनेजमेंट का तरीका तय कर सकते हैं
  • Zig का defer syntax scope खत्म होने पर automatic release और resource cleanup को कहीं अधिक सहज बनाता है
  • Rust के विपरीत, इसमें डेवलपर की ज़िम्मेदारी पर ज़ोर है, इसलिए अनुशासन चाहिए; लेकिन अगर संरचना सही तरह डिज़ाइन की जाए, तो मेमोरी सुरक्षा हासिल करना और बनाए रखना आसान होता है
  • Zig में कोड अधिक संक्षिप्त होता है, और pointer, list, index जैसी संरचनाओं में बदलाव Rust की तुलना में कहीं सरल होते हैं
  • Rust जैसी कड़ी पाबंदियों के बिना भी उसी स्तर का सुरक्षित और कुशल कोड लिखा जा सकता है
  • अतिरिक्त रूप से, Zig की comptime सुविधा compile-time code execution, testing, और optimization में बहुत मदद करती है

डेवलपर अनुभव (Developer Ergonomics) का महत्व

  • डेवलपर अनुभव (ergonomics) में भाषा की syntax, tooling, documentation, और community तक सब शामिल हैं
  • Rust अपने बेहद सख्त नियमों के कारण अंततः मेमोरी सुरक्षा सुनिश्चित करता है, लेकिन अत्यधिक नियम और ceremony प्रोडक्टिविटी घटा देते हैं
  • Zig डेवलपर-नेतृत्व वाले डिज़ाइन पर ज़ोर देता है, जिससे कोड को अधिक आसानी और तेज़ी से लिखा, बदला, और समझा जा सकता है
  • Zig अपनी सहज कोडिंग, तेज़ iteration, और कम मानसिक बोझ की वजह से डेवलपर को टूल से लड़ने के बजाय समस्या समाधान पर ध्यान केंद्रित करने देता है
  • Zig डेवलपर पर भरोसा करता है और उसे उपयुक्त टूल्स और विकल्प देता है, जबकि Rust कभी-कभी ज़रूरत से ज़्यादा निगरानी करने वाला और सीमित करने वाला महसूस हो सकता है
  • डेवलपर को "गलतियों से बचाने" के बजाय, उसे अपनी गलतियों से सीखने और आगे बढ़ने का अवसर देना ही वास्तव में डेवलपर-फ्रेंडली वातावरण है

निष्कर्ष

  • बड़े, multi-threaded, लंबे समय तक चलने वाले systems जैसे क्षेत्रों में, जहाँ Rust की ताकत पूरी तरह उभरती है, Rust अब भी बेहतरीन विकल्प है
  • लेकिन छोटे और व्यावहारिक CLI टूल्स के लिए Zig की हल्कापन, सरलता, और तेज़ इम्प्लीमेंटेशन/मेंटेनेंस अधिक उपयुक्त है
  • मेमोरी सुरक्षा, सुरक्षा की पूरी पहेली का सिर्फ एक हिस्सा है; और पूर्वानुमेय व्यवहार, maintainability, तथा robustness जैसे CLI टूल के ज़रूरी तत्व Zig में अधिक आसानी से हासिल किए जा सकते हैं
  • आखिरकार महत्वपूर्ण बात "बेहतर भाषा" नहीं, बल्कि मेरे workflow और प्रोजेक्ट की प्रकृति के अनुरूप सही "टूल का चयन" है
  • Zig एक ऐसी भाषा है जो "मेमोरी सुरक्षा + कम मानसिक लागत + डेवलपर-फ्रेंडली प्रोडक्टिविटी" के संयोजन के साथ छोटे टूल डेवलपमेंट में बिल्कुल फिट बैठती है

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

3 टिप्पणियां

 
shakespeares 2025-10-05

मुझे अभी भी लगता है कि इसका ecosystem अभी Rust जितना स्थिर नहीं हुआ है।
 
bus710 2025-09-27

क्यों Zig वास्तविक CLI टूल डेवलपमेंट में Rust की तुलना में ज़्यादा व्यावहारिक लगता है

Zig में नए versions पर breaking changes काफ़ी बार आती रहती हैं... इसलिए लगा कि छोटे project के लिए भी जहाँ तक हो सके CI जोड़कर लगातार maintenance करते रहना पड़ेगा।
 
GN⁺ 2025-09-27
Hacker News राय

  • Zig का फ़ायदा यह है कि यह आपको C डेवलपर की तरह सोचते रहने देता है, लेकिन कुछ हद तक यह सिर्फ़ परिचय और आदत का मामला भी लगता है

    • जो डेवलपर Rust के काफ़ी अभ्यस्त हो जाते हैं, वे borrow checker से लड़ना बंद कर देते हैं; वे पहले से ही उसी तरह की code structure में सोचना शुरू कर देते हैं

    • Rust में "object soup" जैसी approach अच्छी तरह काम नहीं करती, लेकिन मुझे नहीं लगता कि वह मूल रूप से आसान तरीका है; बस हम उसके आदी हैं इसलिए वह आसान लगती है

    • अगर हम यह मान लें कि ergonomics (उपयोग अनुभव) को मापना या संख्याओं में बाँधना मुश्किल है, तो ऐसी बहसें धुंधली बनी रहती हैं

      • यह कुछ वैसा है जैसे कहना, "यह कुर्सी नहीं टूटेगी, निश्चिंत होकर बैठो; हाँ, शायद थोड़ी कम आरामदायक और भारी हो, लेकिन ज़्यादातर लोग जल्द ही इसके आदी हो जाएँगे और असुविधा महसूस नहीं करेंगे"
      • मूल पोस्ट की पंक्ति की तरह, "Rust डेवलपर अनुभव को थोड़ा असुविधाजनक बनाता है लेकिन memory safety देता है, जबकि Zig बेहतर डेवलपर अनुभव और थोड़ी सावधानी के साथ memory safety दे सकता है" — यह आख़िरकार safety और usability के बीच का trade-off है
      • मुझे लगता है Rust community को इस trade-off को ईमानदारी से स्वीकार करना चाहिए; safety हासिल करना हमेशा कुछ कम convenience के साथ आता है
      • security, जीवन, रोज़मर्रा और पूरे software जगत में यही बुनियादी सिद्धांत चलता है, और ज़्यादातर दावे धुंधले या व्यक्तिपरक होते हैं
      • कुछ लोग "जो लोग इसके आदी हैं उन्हें कोई समस्या नहीं होती" कहकर ergonomic मुद्दे को आसानी से ख़ारिज कर देते हैं; यह कभी-कभी ऐसा भी लग सकता है जैसे "अगर यह भी मुश्किल लग रहा है तो शायद तुम उतने स्मार्ट नहीं हो"

    • "borrow checker से लड़ाई" वाली बात उस दौर से आई है जब Rust में सिर्फ़ lexical lifetime को समझा जाता था

      • जब मैंने 2021 में Rust सीखा, तब तक यह पुरानी बात हो चुकी थी
      • सच है कि जिन लोगों ने सिर्फ़ Python, C, JavaScript आदि ही इस्तेमाल किए हैं, उनके लिए Rust के साथ ढलना आसान नहीं हो सकता
      • मेरे लिए यह काफ़ी सहज था, लेकिन लगता है ज़्यादातर लोगों को ऐसा महसूस नहीं होता
      • लेकिन "Rust में diagnostics पढ़कर code ठीक करना पड़ता है" यह बात "बहादुरी से borrow checker से लड़ना" जितनी आकर्षक नहीं लगती; मुझे लगता है असली स्थिति को कुछ ज़्यादा ईमानदारी से बयान करना चाहिए

    • मेरे अनुभव में अनुभवी Rust डेवलपर हर जगह Arc छिड़ककर उसे लगभग automatic garbage collection जैसा इस्तेमाल करते हैं

      • static memory management काफ़ी सख़्त है, इसलिए complex data structures में यह व्यावहारिक रूप से कठिन हो जाता है
      • lifetimes की वजह से जिन रास्तों को ट्रैक करना पड़ता है, वे अक्सर इंसानी cognitive क्षमता से आगे चले जाते हैं

    • मैंने बहुत से open source Rust projects देखे हैं जहाँ अनुभवी Rust डेवलपर भी हर जगह Arc, Clone, Copy आदि का इस्तेमाल करते हैं

    • Zig का फ़ायदा यह है कि आप C की तरह परिचित ढंग से development कर सकते हैं, और साथ ही language व tooling से safety की कुछ सुविधाएँ भी मिलती हैं

      • उदाहरण के लिए Zig का optional nil dereference जैसी समस्या से बचने में मदद करता है
      • debugging या testing के समय debug/custom allocator सीधे पास करके runtime checks, memory access, resource leak checks भी आसानी से किए जा सकते हैं
      • explicit interface/trait न होने की शिकायत है, लेकिन adoption सरल है इसलिए यह व्यावहारिक लगता है

  • मैं मूल पोस्ट की ज़्यादातर बातों से सहमत नहीं हूँ

    • Rust में भी C या Zig की तरह lifetime, ownership, borrow scope के बारे में सोचना पड़ता है; फ़र्क बस इतना है कि compiler मदद करता है

    • इंसान कितना भी स्मार्ट क्यों न हो, थका हुआ या distracted होने पर गलती करता ही है; गलती को मान लेना ही समझदारी है

    • जिन programs को Rust compiler safe मानता है, उनका दायरा काफ़ी बड़ा नहीं है, इसलिए यह अक्सर पूरी तरह वैध programs को भी reject कर देता है

    • उदाहरण: अगर Foo struct में bar और baz दोनों string हों, और bar को mutable reference लेने के बाद baz को immutable reference से लेना चाहें, तो compile नहीं होगा; ऐसी स्थिति में code structure को ज़बरदस्ती घुमाना पड़ता है

    • जवाब में कहूँ तो, "असल में सब ठीक होने पर भी compile reject होने से बचने के लिए" code को दूसरे या तीसरे सबसे अच्छे design में बदलना अपने आप में बड़ा बोझ है

      • इससे पूरे codebase का design बदल सकता है
      • इसी से समझ आता है कि game developers जैसे कठिन समस्याओं पर काम करने वाले लोग Rust अपनाने में हिचकते क्यों हैं
      • अगर Rust compiler बिना false alarm के बिल्कुल सटीक तरीके से काम करे, तो ergonomics के हिसाब से भी वह बेहतरीन होगा; लेकिन हक़ीक़त इतनी आसान नहीं है

    • ऊपर वाला उदाहरण मुझे सचमुच बहुत अच्छा case लगता है; पूछना चाहता हूँ कि क्या मैं इसे अपने blog या article में इस्तेमाल कर सकता हूँ

    • ऊपर का code देखकर तो मैं अपने दावे को लेकर और कम आश्वस्त हो गया

  • हमें याद रखना चाहिए कि हर program का इतना "safe" होना ज़रूरी नहीं है

    • हममें से बहुत लोग Unsafe software का आनंद लेते हुए बड़े हुए हैं — Star Fox 64, MS Paint, FruityLoops वगैरह

    • मैंने पढ़ा था कि Zig के creator Andrew Kelley ने Zig इसलिए बनाया क्योंकि music production software (DAW) development के लिए उपयुक्त माहौल नहीं था; मुझे लगता है Zig ऐसे creative software के लिए अच्छी तरह फ़िट बैठता है

    • जिसे memory bugs की ज़्यादा चिंता हो, वह Rust इस्तेमाल कर सकता है

    • मुझे तो लगता है Super Mario World memory bugs की वजह से और मज़ेदार था

    • "safety" दरअसल "मेरा program मेरी मंशा के अनुसार काम करता है" का संक्षेप है

      • अनचाहा, अतार्किक code (semantic gibberish) अपने लक्ष्य को पाने में रुकावट है
      • हाँ, कभी-कभी जानबूझकर कलात्मक या उलझा हुआ code लिखा जाता है (IOCCC, hacking, code poetry), लेकिन वहाँ भी उसे बहुत सावधानी से craft करना पड़ता है
      • Rust में भी escape hatch (unsafe) के ज़रिए जानबूझकर ऐसा implement किया जा सकता है
      • इस लेख का दावा यह लगता है कि अनजाने में अर्थहीन (gibberish) coding कर पाना एक फ़ायदा है, और इससे सहमत होना आसान नहीं है
      • अगर बिना किसी नुकसान के हर code को safe बनाया जा सके, तो क्या हर कोई उसे नहीं चाहेगा?
      • Super Mario World speedrun जैसी चीज़ें binary patch से भी बनाई जा सकती हैं; मैं यह नहीं मानता कि input के ज़रिए memory manipulation ही उसका इकलौता मज़ा है

    • मैं थोड़ा उलझन में हूँ; क्या मेरे विचार को बुरा इसलिए माना जा रहा है क्योंकि उसका मतलब यह निकाला जा रहा है कि memory safety महत्वपूर्ण नहीं है?

  • borrow checker की क़ीमत को कम आँका गया है, यह मुझे खटका

    • Rust का borrow checker compile time पर invalid memory access को रोकने की गारंटी देता है

    • हाँ, इसके बदले code structure को compiler के नियमों के मुताबिक बदलना पड़ता है, जो असुविधाजनक हो सकता है

    • जब मैंने Rust अलग से इस्तेमाल किया, तो lifetime annotation कभी ग़लत नहीं लगे; वे थोड़ा झंझट जैसे ज़रूर लगे, लेकिन जल्दी आदत पड़ गई

    • unsafe के बिना Rust में दो threads एक ही memory पर एक साथ write नहीं कर सकते

    • "CLI tools में Zig ज़्यादा practical क्यों लगता है" — इस बात से मैं सहमत नहीं हूँ; CVE (vulnerability) रोकने के मामले में Rust की बढ़त अब भी है

    • असल में मैं ज़्यादातर काम GC languages में भी कर लेता हूँ, और दूसरी languages में contribute करते समय Rust, Zig, C/C++ — जो भी हो, इस्तेमाल कर लेता हूँ

    • क्या CLI tools कोई बहुत अलग चीज़ हैं?

      • आम तौर पर CLI tools का आकार बहुत बड़ा नहीं होता या वे अकेले डेवलपर द्वारा बनाए जाते हैं, इसलिए manage करना आसान होता है
      • Zig या C बड़े codebase में बहुत उपयुक्त न हों; ज़्यादा complex projects में एक babysitter की ज़रूरत पड़ती है
      • ऐसी ही पुरानी बहस में Java को भी "babysitter language" कहा गया था, लेकिन सच यह है कि कई codebase में वही चाहिए होता है

    • unsafe के बिना दो threads का एक ही memory पर साथ लिख न पाना उतना सीधा मामला नहीं है

      • मुझे compiler से जो मदद सबसे ज़्यादा चाहिए, वह memory ordering समस्याओं को हल करने में चाहिए
      • Rust ऐसे हिस्सों में race हो जाने पर भी उसे unsafe नहीं बल्कि safe की श्रेणी में रखता है

  • मैं इस बात से सहमत हूँ कि Rust में backlinks implement करना बहुत complex है

    • Rc, Weak, RefCell, .borrow() आदि इस्तेमाल करके यह संभव है, लेकिन आसान नहीं

    • अगर program कम समय चलने वाला हो, तो arena allocation भी एक तरीका है — शायद CLI tool से यही मतलब है

    • Rust सच में बड़े, multi-threaded, लंबे समय तक चलने वाले applications में अपनी ताकत दिखाता है

    • मैंने वास्तव में Rust में एक बड़ा metaverse client लिखा था; दर्जनों threads को 24 घंटे चलाने पर भी memory leak या crash नहीं हुआ

    • यही काम C++ में करना हो तो QA team और Valgrind जैसे tools ज़रूरी हो जाते, और scripting languages performance के लिहाज़ से बहुत धीमी पड़तीं

    • मैंने भी Rust में ऐसा physics simulation aircraft बनाया था जो पृथ्वी की curvature और gravity deviation तक को ध्यान में रखता था

      • 5 घंटे और 22 घंटे वाले route tests को मैंने सालों तक बिना किसी समस्या के चलाया
      • 7 साल Rust इस्तेमाल करने में crash के मामले बहुत कम रहे; C/C++ अब सिर्फ़ legacy code ठीक करते समय ही इस्तेमाल करता हूँ

  • Zig आकर्षक है, लेकिन D अब भी मौजूद है, और व्यक्तिगत रूप से D मुझे वह C/C++ replacement लगता है जो मैं चाहता हूँ

    • Zig का syntax मुझे थोड़ा अजीब लगता है, और Rust ecosystem में पहले से केंद्र में आ चुका है

    • Go भी कई language tooling क्षेत्रों में अच्छी हिस्सेदारी रखता है, और AI में Python के बाद काफ़ी इस्तेमाल होता है

    • Rust से पहले Go vs. D की बहस हुआ करती थी; मैंने D की किताब भी खरीदी थी, लेकिन बाद में Go की तरफ़ चला गया

      • मेरे लिए उसका standard library कहीं ज़्यादा practical था, और int64 जैसे type names भी ज़्यादा intuitive लगे

    • D अच्छा है, लेकिन उसके लिए कोई killer app सामने नहीं आया

  • मुझे ठीक से समझ नहीं आता कि CLI tools के लिए खास तौर पर Rust या Zig की ज़रूरत क्यों हो

    • bottleneck तो I/O है, GC का धीमा होना नहीं

    • जब तक काम game, DB जैसी memory-intensive चीज़ों का न हो, GC मुद्दा नहीं है

    • memory safety की बहस से ज़्यादा मैं इस बात पर ज़ोर दूँगा कि बिना-GC language चुनने की ज़रूरत क्यों है

    • अगर वजह सिर्फ़ "no-GC मज़ेदार है" है, तो वह अपने आप में काफ़ी है; बहस की ज़रूरत नहीं

    • instant startup time (बिना execution delay) बहुत उपयोगी है

      • wrapper tools बनाते समय उसे हज़ारों बार चलाना पड़े तो भी बोझ नहीं लगता
      • Python जैसी environment की deployment complexity नहीं होती, इसलिए distribute करना भी आसान हो जाता है

    • Go से CLI बनाना काफ़ी अच्छा अनुभव था (हालाँकि Go language ख़ुद मुझे बहुत पसंद नहीं)

      • Python CLI में dependencies ज़्यादा हों तो deployment झंझटी हो जाता है, और Rust/Zig भी Go की तरह static binary distribution आसान होने की वजह से लोकप्रिय हैं

    • मैं sum type, pattern matching, और async support वाली language को प्राथमिकता देता हूँ

      • Rust न भी हो, compile time पर errors पकड़ने वाली सुविधाएँ मुझे अच्छी लगती हैं

    • इस टिप्पणी के जवाब में कि बिना-GC development सिर्फ़ game industry की चीज़ नहीं है

      • वास्तव में कई mobile games भी Unity + il2cpp जैसे environment में GC इस्तेमाल करते हैं, और GC performance भी हमेशा अच्छी नहीं होती

    • GC बहस में थोड़ा bandwagon जैसा एहसास होता है

      • 50 साल पहले भी GC-based languages के साथ Interlisp, Cedar जैसे बड़े workstations सफलतापूर्वक बनाए गए थे
      • आज का hardware 1970s के CLI या आज के Electron apps से कहीं बेहतर है, लेकिन उसका कुशल उपयोग कम होता है

  • मैंने Rust के built-in borrow/referencing के साथ एक simple note tool बनाया था, और यह उतना complex नहीं निकला जितना सोचा था

    • अगर आप notes list के index store करके उन्हें map से जोड़ने वाली structure की कल्पना करें, तो speed का फ़र्क भी लगभग नहीं होगा और safety के नुक़सान भी नहीं होंगे

    • index में गलती होने पर भी वह out-of-range error के रूप में पकड़ में आ जाती है, जो kernel memory overwrite करने से बहुत बेहतर है

    • printf debugging के समय भी यह कहीं ज़्यादा आसान और intuitive लगता है

    • raw pointer या reference आम तौर पर allocator, async runtime जैसी जगहों पर ही चाहिए होते हैं; सामान्य logic में index-based approach ज़्यादा उपयुक्त है

    • मशहूर तौर पर Rust async में self-referential struct न चल पाने और Pin से जुड़े issues का एक कारण यही है

    • vec में stored values के pointers realloc वगैरह होने पर invalid हो जाते हैं, और ऐसी स्थिति में Miri तुरंत error दे देता है

  • अगर मैं C++ developer होकर किसी safe language की तलाश करूँ, तो Swift मुझे सबसे उपयुक्त लगेगी

    • जो language परिचित हो या मिलती-जुलती हो, उसमें ढलना तेज़ होता है

    • Swift ने हाल के वर्षों में cross-platform support भी मज़बूत किया है, और मौजूदा C++ standards committee के कई लोग उसमें शामिल हैं

    • लेकिन Apple से जुड़ाव, native UI framework की कमी जैसी वजहों से non-Apple दुनिया में उसका विस्तार अपेक्षाकृत कम है

    • मैं चाहता हूँ कि Swift को और लोकप्रियता मिले

    • अगर Swift और Zig/C की तुलना करने वाले अच्छे resources हों तो कोई सुझाए, अच्छा रहेगा

  • यह कहा जाता है कि Zig में थोड़ी सावधानी रखकर memory-safe software बनाया जा सकता है, लेकिन सच कहें तो C में भी काफ़ी disciplined होकर वही नतीजा पाया जा सकता है

    • आख़िरकार यही "थोड़ा सा अनुशासन (training)" असल दुनिया में अक्सर कम पड़ जाता है, और वहीं से समस्याएँ पैदा होती हैं

    • Zig इसके अलावा नीचे की समस्याएँ भी address करता है

      • out-of-bounds access (जो कुल CVE का 70% होता है)
      • null pointer dereference
      • type safety
      • यह C से काफ़ी बेहतर है, और use-after-free जैसी गड़बड़ियों से भी, जब तक boundaries पार न हों, कहीं आसानी से बचा जा सकता है
      • Zig का शानदार cross-platform build system, comptime optimization, और C++/Rust की तुलना में कई गुना तेज़ build time भी इसकी ताकत हैं
      • standard library अभी कमज़ोर है और कुछ छोटे-मोटे issues बाकी हैं, लेकिन perf-oriented programs में इसका भविष्य उज्ज्वल लगता है

    • अगर C 50 साल से ज़्यादा समय तक इस discipline समस्या में विफल रहा है, तो यह Shaolin के मार्ग से भी कठिन साधना है