Scripts should be written using the project main language

“मुख्य भाषा में स्क्रिप्ट्स” पर समग्र रुख

• चर्चा “जहाँ फिट बैठे, वहाँ अच्छा” और “खतरनाक सामान्यीकरण” के बीच बँटी हुई है।
• कई लोगों का कहना है कि यह भाषा, प्रोजेक्ट के प्रकार, डिप्लॉयमेंट संदर्भ, और टीम की क्षमताओं पर बहुत निर्भर करता है।
• कुछ लोग लेख को शीर्षक से अधिक संतुलित मानते हैं; फिर भी कुछ इसे hammer-nail सोच ही समझते हैं।

मुख्य भाषा इस्तेमाल करने के पक्ष में तर्क

• साझा भाषा context switching कम करती है और domain logic तथा APIs को पुन: उपयोग करने देती है।
• बाद में ad-hoc scripts को scheduled jobs या production tools में बदलना आसान होता है।
• कुछ भाषाओं (Go, Kotlin, C#, सामान्य रूप से JVM) में scripting support या तेज़ run tools इसे व्यावहारिक बनाते हैं।
• 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 को हटाने के लिए पर्याप्त नहीं हैं।