टूल्स को standalone static binary के रूप में वितरित क्यों करना चाहिए

• स्वतंत्र रूप से चलने वाली static binary के रूप में टूल वितरित करने पर उपयोगकर्ता उसे अलग development environment या toolchain install किए बिना तुरंत इस्तेमाल कर सकते हैं
• compile प्रक्रिया खराब या असामान्य तरीके से काम करने वाला code deploy होने की संभावना को कम करने वाला एक अतिरिक्त safety check का काम करती है
• interpreter language आधारित टूल्स में dependencies install करने की झंझट, disk space की बर्बादी, और upgrade के समय बार-बार reinstall जैसी maintenance समस्याएँ अधिक होती हैं
• dependencies जितनी अधिक होंगी, security vulnerabilities और attack surface उतना बढ़ेगा, जिससे hacking risk और maintenance issues पैदा होने की संभावना बढ़ती है
• compiled language आधारित static binary बाहरी environment में बदलाव से प्रभावित नहीं होती, इसलिए deployment के बाद भी स्थिर usability सुनिश्चित करती है

---

स्वतंत्र standalone static binary वितरण के फायदे

बिना installation के तुरंत इस्तेमाल

• जैसे OpenAI ने Codex को Rust में दोबारा बनाया और TypeScript को छोड़ा, वैसे ही compiled language में लिखी गई single binary वितरित करने पर उपयोगकर्ता बिना अतिरिक्त toolchain install किए उसे तुरंत चला सकते हैं
• सबसे बड़ा फायदा speed या efficiency नहीं, बल्कि बिना install किए तुरंत टूल इस्तेमाल कर पाना है

compiler एक अतिरिक्त safety guard के रूप में

• compile चरण में होने वाली जाँच से गलत या असामान्य code के deploy होने की संभावना कम हो जाती है
• उदाहरण के तौर पर Google Cloud CLI, जो Python आधारित है, कई बार ऐसी स्थिति में वितरित हुआ कि वह चल ही नहीं सका
• बड़े टीमें भी ऐसे issues से नहीं बच पातीं, इसलिए छोटे टीमों के लिए interpreter language आधारित टूल्स को स्थिर रूप से वितरित करना और भी मुश्किल है

toolchain dependency की आवश्यकता नहीं

• compiled language आधारित टूल में केवल single binary वितरित करनी होती है, जबकि Python, Ruby, TypeScript जैसी interpreter language टूल्स के लिए संबंधित development environment अनिवार्य होता है
• Ruby में लिखे गए mdl (markdown linter) की तरह, development environment (Ruby) upgrade होते ही फिर से reinstall करना पड़ता है
• JavaScript आधारित markdownlint इस्तेमाल करने पर npm और 44 से अधिक dependencies install करनी पड़ती हैं

disk space की बर्बादी

• लोकप्रिय FOSS coding assistant aider, जो Python में लिखा गया है, Homebrew से install करने पर अतिरिक्त 51 packages install करता है
• वास्तविक disk usage 3GiB से अधिक बढ़ जाती है, जो अधिकांश Linux distributions के आकार से भी ज्यादा है
• इसके विपरीत Rust में लिखा गया uv package manager 35MiB की single binary से install हो जाता है; Rust या rustup की भी जरूरत नहीं पड़ती

security vulnerabilities में वृद्धि

• टूल की dependencies बढ़ने पर attack surface भी बढ़ता है और security vulnerabilities के सामने आने की संभावना भी बढ़ती है
• OpenAI के Codex package में 24 direct और 184 indirect dependencies हैं
• भले ही OpenAI सभी dependencies का audit करे, फिर भी dependency versions fix न होने पर भविष्य के updates से vulnerabilities, malicious packages, या breakage जैसी समस्याएँ आ सकती हैं

maintenance की आसानी

• JavaScript, TypeScript, Python जैसी interpreter language आधारित टूल्स में dependency हटते ही टूल काम करना बंद कर सकता है
• left-pad घटना की तरह, एक single package हटने से बड़े पैमाने पर services और tools ठप हो सकते हैं
• compiled language को केवल build समय पर dependencies चाहिए होती हैं, इसलिए बाद में बाहरी repository गायब हो जाए तब भी टूल सामान्य रूप से चलता रहता है

लेखक का अनुभव

• लेखक ने adb-enhanced जैसे पुराने टूल Python में बनाए, लेकिन बाद में Go में gabo, wp2hugo जैसे कई टूल open source किए
• Python, TypeScript जैसी भाषाओं में standalone tools बनाना अब वे विचार भी नहीं करते
• वे सलाह देते हैं कि टूल्स को हमेशा ऐसी भाषा में लिखा जाए जो static linked binary distribution को support करती हो, जैसे Rust, Go, C++

निष्कर्ष

• standalone tools को Rust, Go, C++ जैसी compiled languages में विकसित करना चाहिए
• इन्हें न्यूनतम external dependencies वाली static binary के रूप में वितरित करना चाहिए

[rikko]

डिस्क स्पेस की बर्बादी की समस्या से तो काफ़ी हद तक सहमत होना ही पड़ता है...
AKS चलाता हूँ, और हर बार 1GB से ऊपर जाने वाली Python ऐप की container image देखता हूँ तो सिर दर्द होने लगता है.
अभी तो बस Dockerfile उठाकर मैं खुद ही फिर से size कम करके अपलोड करता हूँ, और 500MB से नीचे नहीं ला पाऊँ तो बस हार मान लेता हूँ, हाहा

[eususu]

ऐसे packages हैं जिनकी dependency सिर्फ pytorch+cuda version अलग होने की वजह से अलग-अलग बंधी हुई है... सच में हाल बेहाल है।
कोई खास feature भी नहीं है, फिर भी हर छोटे daemon के लिए लगभग 2GB dependencies install करनी पड़ती हैं..

[rikko]

अगर यह सिर्फ़ simple inference के लिए इस्तेमाल होने वाला CPU runtime हो तो हालात थोड़े बेहतर हैं, लेकिन आजकल जिन LLM services की ज़रूरत पड़ती है, उनमें traffic भी अपने हिसाब से बढ़ता है और capacity भी उसी तरह बढ़ती है, इसलिए cost calculate करते समय मुँह से गाली निकल जाती है lol