Go अभी भी अच्छा नहीं है

• Go भाषा के कई डिज़ाइन फ़ैसले अनावश्यक थे या पहले से मौजूद अनुभवों को नज़रअंदाज़ करते हुए किए गए
• error variable की scope management की समस्या कोड की readability और bugs ढूँढना कठिन बना देती है
• nil की द्वैधता, memory usage, code portability आदि कई हिस्सों में non-intuitive और वास्तविकता से मेल न खाने वाला डिज़ाइन दिखाई देता है
• defer statement की सीमाएँ और standard library का exception handling तरीका exception safety सुनिश्चित करना कठिन बना देता है
• memory management और UTF-8 handling की कमियाँ जैसी जमा होती समस्याएँ लंबे समय में Go codebase की quality पर नकारात्मक असर डाल रही हैं

---

Go भाषा पर दीर्घकालिक आलोचना

• जैसा कि पिछली पोस्टों में बताया गया है(Why Go is not my favourite language, Go programs are not portable), मैं 10 साल से अधिक समय से Go भाषा की कई समस्याओं की ओर इशारा करता रहा हूँ
• खास तौर पर, पहले से ज्ञात अच्छे उदाहरणों को नज़रअंदाज़ करने वाले अनावश्यक डिज़ाइन फ़ैसले समय के साथ और अधिक खटकते हैं

error variable scope की non-intuitive प्रकृति

• Go का syntax error variable (err) की scope को अनावश्यक रूप से बढ़ा देता है, जिससे गलती की संभावना बढ़ती है
  • उदाहरण कोड में err variable पूरे function में मौजूद रहता है और reuse होता है, जिससे code readability और maintainability घटती है
  • अनुभवी developers इस scope समस्या के कारण bug hunting में भ्रम और समय की बर्बादी का सामना करते हैं
  • variables को उचित रूप से local scope तक सीमित करने का तरीका syntax में उपलब्ध नहीं है

nil के दो रूप

• Go में interface type और pointer type में nil अलग-अलग तरह से behave करता है, जिससे भ्रम पैदा होता है
  • नीचे दिए गए उदाहरण की तरह, s (pointer) और i (interface) दोनों में nil assign होने पर भी s==i का परिणाम अलग आ सकता है, यानी असंगत व्यवहार दिखता है
  • यह null handling में उन समस्याओं जैसा है जिनसे आमतौर पर बचना चाहा जाता है, और यह बिना पर्याप्त डिज़ाइन-विचार के बने होने का संकेत देता है

कोड portability की सीमाएँ

• conditional compilation के लिए comments का उपयोग maintainability और portability के लिहाज़ से काफ़ी अप्रभावी है
  • अगर आपने सच में portable software बनाया है, तो समझेंगे कि यह तरीका झंझटभरा और error-prone है
  • ऐतिहासिक अनुभवों (code portability, व्यावहारिक उदाहरणों) को नज़रअंदाज़ किया गया है
  • अधिक जानकारी के लिए Go programs are not portable देखें

append की ownership की अस्पष्टता

• append function और slice की ownership का संबंध स्पष्ट नहीं है, जिससे code behavior का अनुमान लगाना कठिन हो जाता है
  • उदाहरण से पता चलता है कि foo function में slice पर append करने से मूल डेटा पर वास्तव में क्या असर पड़ेगा, यह पहले से जानना आसान नहीं है
  • भाषा में ऐसे याद रखने वाले ‘quirk’ बढ़ते जाते हैं, जो गलतियों को जन्म देते हैं

defer statement का अपर्याप्त डिज़ाइन

• यह RAII(Resource Acquisition Is Initialization) सिद्धांत की तरह resource release को स्पष्ट रूप से support नहीं करता
  • Java और Python के structured resource management syntax की तुलना में, Go में यह स्पष्ट नहीं होता कि कौन-सा resource defer से release होना चाहिए
  • उदाहरण की तरह, file operations में double-close समस्या तक को developer को ख़ुद संभालना पड़ता है, और सही release order व तरीका स्पष्ट नहीं होता

standard library में exception handling

• Go explicit exception को support नहीं करता, फिर भी panic जैसी exceptional स्थितियाँ बनी रहती हैं
  • कुछ स्थितियों में panic पूरे program को पूरी तरह बंद नहीं करता और अंदर ही दबा रह जाता है
  • standard library (fmt.Print, HTTP server आदि) में exceptions को ignore करने वाले patterns मौजूद हैं, इसलिए वास्तविक exception safety की गारंटी संभव नहीं
  • नतीजतन exception-safe code लिखना ज़रूरी है, लेकिन exceptions को सीधे इस्तेमाल नहीं किया जा सकता

UTF-8 handling और strings

• string type में मनचाहा binary data डालने पर भी Go बिना किसी विशेष validation के काम करता रहता है
  • UTF-8 encoding से पहले बने filenames जैसी चीज़ें चुपचाप छूट जाने के मामले सामने आ सकते हैं
  • backup जैसे कामों में महत्वपूर्ण data खो सकता है, और यह वास्तविक कामकाजी स्थितियों को न दर्शाने वाला अत्यधिक सरल तरीका है

memory management की सीमाएँ

• RAM usage पर सीधा नियंत्रण कठिन है, और GC(garbage collection) की विश्वसनीयता की भी सीमाएँ हैं
  • Go की memory usage बढ़ती जाती है, जो लंबे समय में cost और performance issues से जुड़ती है
  • कई instances और container environments में cost और scalability की समस्याएँ वास्तव में सामने आती हैं

निष्कर्ष: बेहतर रास्ता मौजूद था

• पहले से प्रभावी रूप से सिद्ध language designs मौजूद होने के बावजूद, Go ने कई मामलों में उन्हें नज़रअंदाज़ किया
  • Java के शुरुआती संस्करणों की समस्याओं से अलग, Go के रिलीज़ होने तक बेहतर approaches पहले से उपलब्ध थे

संदर्भ सामग्री

• Uber: Data race patterns in Go
• FasterThanLime: Lies we tell ourselves to keep using Golang
• FasterThanLime: I want off Mr Golang’s wild ride