खुद बनाइए: Build It Yourself प्रोग्राम

 (lucumr.pocoo.org)
2 पॉइंट द्वारा GN⁺ 2025-01-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • निर्भरताओं पर एक और विचार

    • निर्भरताओं पर एक नया दृष्टिकोण पेश किया गया है। निर्भरताओं के अत्यधिक उपयोग को कम करने और खुद कोड लिखने की दिशा में जाने की ज़रूरत है.

  • निर्भरता की समस्या

    • "dependency treadmill" वह अंतहीन चक्र है जिसमें डेवलपर उत्पादकता के लिए इंस्टॉल किए गए अपडेट, पैच, ऑडिट और transitive dependencies से लगातार जूझते रहते हैं.
    • JavaScript और Rust खास तौर पर dependency समस्या के प्रति संवेदनशील हैं। उदाहरण के लिए, एक नया Tokio प्रोजेक्ट 28 crates शामिल करता है, और Rocket प्रोजेक्ट में यह 172 तक बढ़ जाता है.

  • टर्मिनल साइज़ की समस्या

    • terminal_size crate टर्मिनल का साइज़ मापने के लिए एक सरल फ़ंक्शन देता है, लेकिन इसके लिए कई अतिरिक्त crates की ज़रूरत पड़ती है.
    • इसके कारण हज़ारों दूसरी functionalities को compile करना पड़ सकता है.

  • निर्भरताओं की आवश्यकता

    • ये platform abstraction libraries के ऊपर बने होते हैं, इसलिए code duplication से बचने और compile time घटाने के लिए अपडेट की आवश्यकता पड़ती है.
    • कई बार ये security समस्याओं का प्रमुख कारण भी बनते हैं.

  • कोड का लक्ष्य

    • कोड इस तरह लिखा जाना चाहिए कि उसे अपडेट की ज़रूरत न पड़े। Rust ecosystem में stable code को नुकसान झेलना पड़ता है.

  • खुद कोड लिखने के फायदे

    • खुद कोड लिखने से नए crates की ज़रूरत नहीं पड़ती और maintenance की आवश्यकता कम हो जाती है.
    • ChatGPT जैसे tools का उपयोग करके dependency-free implementation जल्दी लिखी जा सकती है.

  • open source और कॉर्पोरेट संस्कृति

    • कंपनियों की code review संस्कृति open source software को प्रभावित करती है.
    • नई libraries का उपयोग करना सकारात्मक माना जाता है.

  • नए दृष्टिकोण की ज़रूरत

    • छोटे फीचर खुद लिखने वाले इंजीनियरों की सराहना की जानी चाहिए.
    • बड़े crate graph को संदेह की नज़र से देखना चाहिए.

  • महत्वपूर्ण लाइब्रेरी

    • कुछ महत्वपूर्ण libraries जटिल समस्याएँ हल करती हैं। उदाहरण के लिए, graphics libraries या protocol implementations.

  • खुद बनाकर तैयार करने का महत्व

    • जहाँ उचित हो, वहाँ खुद बनाना उत्सव की तरह मानना चाहिए.
    • कम या बिना निर्भरताओं वाली open source libraries बनाने वाले library authors को श्रेय दिया जाना चाहिए.

  • निष्कर्ष

    • निर्भरताएँ कम करने और खुद कोड लिखने की दिशा में बढ़ना चाहिए.
    • minijinja कम से कम निर्भरताओं का एक उदाहरण है, जो केवल serde पर निर्भर करता है.

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

1 टिप्पणियां

 
GN⁺ 2025-01-26
Hacker News राय

  • मुझे Rust भाषा पसंद है, लेकिन Rust की dependency समस्याएँ पसंद नहीं हैं. C++ का dependency management बेहतर है. C++ में dependencies को खुद नियंत्रित किया जा सकता है, लेकिन Rust में बहुत ज़्यादा dependencies बन जाती हैं, इसलिए हार माननी पड़ती है. सुरक्षा के लिहाज़ से भी यह पता नहीं चलता कि मैं वास्तव में क्या deploy कर रहा हूँ. Rust में ABI compatibility नहीं है और shared library culture भी कमज़ोर है. इससे OS package distribution model टूट जाता है.

  • terminal API स्थिर नहीं है. TIOCGWINSZ ioctl standardize नहीं है, और POSIX में tcgetwinsize() फ़ंक्शन 2024 में जोड़ा गया. Windows की तरफ़ मामला और भी जटिल है.

  • 2006 में बनाया गया web app फिर से चालू किया. नई CI/CD तकनीकें सीखने के लिए app के deployment process को ज़रूरत से ज़्यादा design किया. PHP और MySQL का इस्तेमाल किया था, और ज़्यादातर code खुद लिखा था. 19 साल पुराने app को फिर से चालू करने में सिर्फ़ एक घंटा लगा. इसके उलट, मौजूदा नौकरी में इस्तेमाल होने वाला Spring Boot app dependency समस्याओं की वजह से update करना मुश्किल है.

  • NodeJS ने करियर पर बड़ा असर डाला, लेकिन NPM ने बहुत समस्याएँ पैदा कीं. नई dependency जोड़ने की कोशिश करो तो दूसरी dependencies से टकराव हो जाता है. Expo के मामले में basic React Native project Android पर build ही नहीं होता. इससे यह देखकर कुछ आत्मविश्वास मिलता है कि बड़े project भी काम न करने वाले template ship कर सकते हैं.

  • Rust ecosystem में Go की तुलना में dependencies ज़्यादा हैं. Go में interfaces implicitly satisfy हो जाते हैं, इसलिए अतिरिक्त dependencies की ज़रूरत नहीं पड़ती.

  • library abstraction की एक छिपी हुई लागत होती है. package अगर design बदल दे तो instability पैदा होती है. सरल चीज़ें सबसे लंबे समय तक टिकती हैं. सिर्फ़ Rust ही नहीं, दूसरी भाषाओं में भी ऐसा ही देखा है.

  • ChatGPT या Cursor से dependency-free implementation जल्दी बनवा लेना ज़्यादा तेज़ है. बहुत सी SaaS/3rd party service dependencies ऐसी समस्याएँ हैं जो पहले से हल हो चुकी हैं.

  • Flask और Bottle की functionality मिलती-जुलती थी, लेकिन Flask ज़्यादा लोकप्रिय हुआ. Bottle single-file था और उसमें कोई dependency नहीं थी, इसलिए उसे project में आसानी से copy किया जा सकता था. लेकिन modern Python practices के साथ न चल पाने के कारण वह पुराना लगने लगा.

  • ऐसे सक्षम engineers की ज़रूरत है जो खुद solution बना सकें. मौजूदा libraries से बेहतर solution आसानी से बनाया जा सकता है. एक project में markdown variants के लिए parser लिखा था, लेकिन टीम के लोगों ने maintainability का कारण देकर उसका इस्तेमाल नहीं किया.

  • सिर्फ़ एक function इस्तेमाल करते हुए सैकड़ों functions compile करना भी एक समस्या है. 3rd party dependencies update करने वाले एक project में math library का सिर्फ़ एक method इस्तेमाल हो रहा था. engineer को सलाह दी गई कि Wikipedia पेज देखकर वह method खुद लिख ले. समस्या 3rd party dependency इस्तेमाल करने में नहीं है, बल्कि library के सिर्फ़ छोटे हिस्से को लाने की अवधारणा की ज़रूरत है. "microframework" इसका समाधान हो सकता है.