Scripts should be written using the project main language
चाहे automation scripts को प्रोजेक्ट की primary language में लिखा जाए या Bash, Python, या dedicated build systems जैसे पारंपरिक tools में, यह एक बहुत विवादित विषय है। टिप्पणीकार consistency, type safety, और internal APIs के पुन: उपयोग को shell ergonomics, cross-platform portability, CI/CD ज़रूरतों, टीम कौशल, और साधारण tasks को जटिल, कठिन-रखरखाव mini-projects में बदलने के जोखिम जैसे कारकों के विरुद्ध तौलते हैं; और कई लोग निष्कर्ष निकालते हैं कि भाषा चयन किसी blanket rule के बजाय task और environment के आधार पर व्यावहारिक रूप से होना चाहिए।
“मुख्य भाषा में स्क्रिप्ट्स” पर समग्र रुख
- चर्चा “जहाँ फिट बैठे, वहाँ अच्छा” और “खतरनाक सामान्यीकरण” के बीच बँटी हुई है।
- कई लोगों का कहना है कि यह भाषा, प्रोजेक्ट के प्रकार, डिप्लॉयमेंट संदर्भ, और टीम की क्षमताओं पर बहुत निर्भर करता है।
- कुछ लोग लेख को शीर्षक से अधिक संतुलित मानते हैं; फिर भी कुछ इसे hammer-nail सोच ही समझते हैं।
मुख्य भाषा इस्तेमाल करने के पक्ष में तर्क
- साझा भाषा context switching कम करती है और domain logic तथा APIs को पुन: उपयोग करने देती है।
- बाद में ad-hoc scripts को scheduled jobs या production tools में बदलना आसान होता है।
- कुछ भाषाओं (Go, Kotlin, C#, सामान्य रूप से JVM) में scripting support या तेज़
runtools इसे व्यावहारिक बनाते हैं। - single-language binaries (विशेषकर Go) cross-platform distribution को सरल बनाते हैं और Python-शैली की dependency समस्याओं से बचाते हैं।
विरोध में तर्क / “सही tool इस्तेमाल करें”
- कई भाषाएँ (C, C++, Rust, Java with full toolchains) quick filesystem/OS automation के लिए उपयुक्त नहीं हैं।
- infra और deployment के लिए, specialized tools (Ansible, Fabric, Terraform, Nix, Docker/Compose, Helm, आदि) अक्सर app language में लिखे bespoke “deployment code” से बेहतर होते हैं।
- deployment logic को मुख्य binary में embed करने से concerns धुंधले हो सकते हैं, यह एक नाज़ुक custom DevOps system बन सकता है, और non-language experts के लिए दरवाज़े बंद कर सकता है।
- scripts अक्सर one-off investigations होते हैं; heavy language/toolchain इस्तेमाल करना जरूरत से ज़्यादा है।
Shell बनाम उच्च-स्तरीय scripting
- bash/sh के मज़बूत समर्थक इसकी ubiquity, OS tools के साथ tight integration, और छोटे scripts के लिए सरलता पर ज़ोर देते हैं।
- दूसरे लोग bash के footguns, quoting rules, portability समस्याएँ (macOS बनाम Linux, non-GNU utils), और “works on my machine” failures को रेखांकित करते हैं।
- shellcheck जैसे tools कुछ shell risks कम करते हैं; style guides लंबी/जटिल shell scripts को structured language में rewrite करने की सलाह देते हैं।
Ecosystem-विशिष्ट अनुभव
- Go को छोटे CLIs या
go runके जरिए एक उत्कृष्ट “scripting” भाषा माना जाता है, खासकर heterogeneous dev environments में। - Kotlin scripting और custom shells दिखाते हैं कि एक typed मुख्य भाषा सुखद scripting अनुभव दे सकती है।
- C++ और Rust के उदाहरण दर्द दिखाते हैं: भारी rebuilds, platform-specific binaries, और external scripting languages (अक्सर Python) पर लगभग सार्वभौमिक निर्भरता।
टीम, maintainability, और learning
- अतिरिक्त भाषाएँ onboarding, testing, और tooling overhead बढ़ाती हैं, लेकिन कई लोग कहते हैं कि engineers को कुछ सामान्य scripting languages संभालनी चाहिए।
- अति-जटिल, untested scripts भाषा चयन से बड़ी समस्या हैं; टिप्पणियाँ testing, documentation, स्पष्ट assumptions, और separation of concerns पर ज़ोर देती हैं।
- LLMs अपरिचित भाषाओं में काम करने की बाधा कुछ कम करते हैं, लेकिन semantic और safety pitfalls को हटाने के लिए पर्याप्त नहीं हैं।