कभी-कभी Go को No-Go होना चाहिए

• लेखक ने Go भाषा को कई वर्षों तक इस्तेमाल करने के बाद Java पर स्विच करते समय महसूस की गई Go की सीमाओं और समस्याओं को समझाया है
• यह दृष्टिकोण पेश किया गया है कि Go का सरल और उबाऊ (boring) भाषा होना हमेशा फ़ायदा नहीं, बल्कि कमी भी हो सकता है
• Go का दर्शन: Google की Go design team ने simplicity और limitations पर ज़ोर दिया, लेकिन इससे बार-बार ऐसे काम पैदा होते हैं जिन्हें users को खुद हल करना पड़ता है

1. Go का "मज़ेदार न होना" एक कमी हो सकता है

• Russ Cox का दावा:
  • Go का "उबाऊ (boring)" होना उसकी ताकत बताया जाता है
  • loop के लिए सिर्फ for है, और filter, map, reduce जैसी सुविधाएँ built-in नहीं हैं
  • दूसरी भाषाओं में मिलने वाले कई advanced features का न होना ही simplicity का हिस्सा माना जाता है
• Reddit user की राय:
  • "उबाऊ" और "शक्तिशाली" के बीच की सीमा धुंधली है
  • उनका तर्क है कि Go की कई missing basics किसी समय भाषा में जुड़ सकती हैं
• Third-party package पर निर्भरता:
  • कमियों को भरने के लिए अक्सर इस्तेमाल किया जाने वाला samber/lo package:
    • इसमें filter, map, search जैसी ज़रूरी सुविधाएँ शामिल हैं
    • GitHub पर 18.1k stars, और 12.6k से अधिक projects में उपयोग
  • कुछ सुविधाएँ slices package में जोड़ी गईं, लेकिन अब भी functional रूप से अधूरी हैं
• लेखक की शिकायतें:
  • बार-बार loop लिखने की मजबूरी
  • filter और map जैसे कामों को संक्षिप्त रूप में करना मुश्किल
  • इन्हें अलग receiver methods में निकाला जा सकता है, लेकिन इससे code की सफ़ाई प्रभावित होती है
• Go की simplicity कई मामलों में फ़ायदा है, लेकिन बुनियादी convenience features की कमी productivity और code readability दोनों को घटा सकती है

2. Clean Code सिद्धांतों में बाधा

• Error handling की समस्या:
  • ज़्यादातर functions में return value के रूप में error शामिल होता है:
    • if err != nil pattern बार-बार लिखना पड़ता है
    • code को साफ़ करने की कोशिश में वही और जटिल हो जाता है
  • साधारण project में भी HTTP handler code 20 lines से ऊपर चला जाता है
    • जबकि मूल लक्ष्य लगभग 4 lines में रखने का था
  • panic() और recovery middleware तक पर विचार करना पड़ा, इतनी निराशा error handling से हुई
• छोटे नामों की सिफारिश:
  • variables, methods और functions के लिए छोटे नाम सुझाए जाते हैं:
    • c, a जैसे नामों का अर्थ स्पष्ट नहीं होता
    • उदाहरण: c से Command, Controller, Argument, Amendment — क्या मतलब है?
    • लंबे नाम अधिक स्पष्ट हो सकते हैं, लेकिन Go का दर्शन छोटे नामों को प्राथमिकता देता है
  • इससे team code review में test method names जैसी चीज़ों पर अंतहीन बहस होती है
• Go का दर्शन संक्षिप्त और सरल code पर ज़ोर देता है, लेकिन नतीजे में यह clean code सिद्धांतों के विपरीत जटिलता और inefficiency पैदा कर सकता है

3. जानबूझकर छोटी भाषा का दर्शन और DIY संस्कृति

• Built-in सुविधाओं की कमी:
  • साधारण HTTP handler बनाना आसान है, लेकिन basic middleware (जैसे exponential backoff, cross-site settings आदि) चाहिए हों तो कई packages ढूँढने पड़ते हैं
  • यह भरोसा करना मुश्किल होता है कि ये packages (1) maintain हो रहे हैं या नहीं, और (2) उम्मीद के मुताबिक काम करेंगे या नहीं
• दोहराए जाने वाले कामों में वृद्धि:
  • simplicity बनाए रखने की Go की design philosophy उल्टा developers से "पहिया फिर से बनाने" जैसा काम करवा देती है
  • उदाहरण: साधारण filter feature तक खुद implement करना पड़ सकता है
• अपरिपक्व package ecosystem:
  • GitHub पर कई projects छोड़े हुए हैं या उनके बहुत कम versions रिलीज़ हुए हैं
  • यह सच है कि अपेक्षाकृत नई भाषा होने के कारण .NET/Java से तुलना पूरी तरह निष्पक्ष नहीं, लेकिन व्यवहार में Go के packages की stability और maturity कम महसूस होती है
• ORM की सीमाएँ:
  • Go का प्रमुख ORM package Gorm, Hibernate या Entity Framework की तुलना में features में पीछे है
  • इसमें अजीब behavior और documentation की कमी जैसी समस्याएँ हैं
  • Go community की प्रतिक्रिया: "Go में ORM की ज़रूरत नहीं, Do It Yourself!"
• Go की simplicity project और team के हिसाब से फ़ायदा हो सकती है, लेकिन built-in न होने वाली सुविधाओं की कमी productivity और developer experience दोनों को नुकसान पहुँचा सकती है

4. Go में एक ही तरीका मौजूद नहीं है

• Consistency और uniformity को लेकर भ्रम:
  • Table Test
    • stretchr/testify जैसे test suite का उपयोग (557k projects में उपयोग)
    • table test के भीतर custom subtests लिखना
  • इससे Go के "एकसमान तरीके" के दर्शन और वास्तविकता के बीच अंतर दिखाई देता है
• Team के भीतर टकराव:
  • teams के बीच testing styles और implementation approaches पर चर्चा और बढ़ जाती है
  • Go का दर्शन और design team खुद भी हमेशा consistent नहीं दिखती:
    • उदाहरण: Getter method naming को लेकर असहमति
• Features को ठुकराना और package dependency:
  • Go team assertion feature जोड़ने से इनकार करती है, और इस रवैये की आलोचना होती है कि समस्या programmer की कमी में ढूँढी जाती है
  • नतीजतन ज़रूरी feature इस्तेमाल करने के लिए फिर एक और package install करना पड़ता है (go get)
• Go simplicity और uniformity का लक्ष्य रखता है, लेकिन व्यवहार में कई implementation styles और उन पर बहस मौजूद हैं, और language design philosophy की अस्पष्टता समस्या को और बढ़ा देती है

5. Go में debugging मज़ेदार नहीं है

• Debugging के दौरान expression evaluation संभव नहीं:
  • debugging session में expressions evaluate करना या object की custom string representation देखना संभव नहीं
  • runtime पर object state को साफ़-साफ़ समझना कठिन हो जाता है
• Stacktrace और logs का कम intuitive होना:
  • बड़े test runs (जैसे CI में हज़ारों tests) fail होने पर उलझाऊ stacktraces और logs मिलते हैं
  • इससे debugging कठिन होती है और productivity गिरती है
• C-style debugging experience:
  • Go की debugging toolchain, C-आधारित शैली में काम करती है:
    • C जैसी काफ़ी primitive debugging experience देती है
    • developer-friendly नहीं लगती
• Rust से तुलना:
  • Rust, Go की कई सीमाओं को बेहतर तरीके से संबोधित करता है:
    • स्पष्ट और उपयोगी error जानकारी देता है
    • error messages में सटीक fix suggestions शामिल होते हैं
• Go का debugging experience optimized binaries देने पर केंद्रित design philosophy से निकला है, लेकिन इसकी कीमत developer experience को चुकानी पड़ती है। जहाँ debugging efficiency ज़्यादा महत्वपूर्ण हो, वहाँ वैकल्पिक languages पर विचार करना बेहतर हो सकता है

सारांश: Go की उपयुक्तता और सीमाएँ

• Go के built-in tools के फ़ायदे:
  • package management, testing, और performance monitoring के लिए basic toolchain उपलब्ध
  • बिना अलग configuration के इस्तेमाल संभव, इसलिए शुरुआती development environment setup सरल
• सीमाएँ:
  • "उबाऊ code" और दोहराए जाने वाले काम:
    • Go की toolchain काम की है, लेकिन code लिखते समय दोहराए जाने वाले काम (Plumbing Code) थोपती है
    • उदाहरण: एकरस syntax और सीमित features काम में रुचि कम कर देते हैं
  • "import cycle not allowed":
    • tests में circular dependency (import cycle) की अनुमति नहीं
    • domain-driven design (DDD) पर काम करते समय यह structural constraint complexity बढ़ा सकता है
  • struct embedding तकनीक पर निर्भरता:
    • अजीब और सीमित struct embedding mechanism उपयोग में परेशानी पैदा करता है
• उपयुक्त उपयोग क्षेत्र:
  • infrastructure development के लिए उपयुक्त:
    • Docker, Drone, Hugo जैसे system-level tools Go में लिखे गए हैं
  • lightweight servers और CLI applications के विकास में उपयोगी
• अनुपयुक्त उपयोग क्षेत्र:
  • जटिल enterprise applications (जैसे ERP systems) का विकास:
    • सीमित language philosophy और tools के कारण बड़े business logic को संभालना inefficient हो सकता है
• Go कुछ खास तरह के कामों, खासकर infrastructure-related क्षेत्रों में, बहुत प्रभावी हो सकता है; लेकिन जटिल business domain applications के लिए यह हमेशा सही tool नहीं है। अगर CTO का झुकाव Google tech stack की ओर हो, तब भी technology choice सोच-समझकर करनी चाहिए

[secret3056]

काश Rust का ? ही होता, तो भी अभी से कहीं बेहतर होता...

[bbulbum]

Go का उपयोग करते हुए मुझे यह एहसास हुआ कि अब तक मैं कितनी implicit error handling करता रहा था।
बेशक, error handling को एक ही point पर संभालना संरचनात्मक रूप से साफ़-सुथरा लग सकता है, लेकिन मुझे लगता है कि किसी operation के error response दे सकने वाले behavior को explicitly दिखाते हुए कोड को अधिक सुरक्षित तरीके से लिखना संभव होता है।

[tsboard]

if err != nil {} यह सच कहूँ तो थोड़ा झंझट वाला है। बताई गई कमियों से भी मैं सहमत हूँ। फिर भी, अगर हम साफ़ तौर पर समझें कि यह भाषा किस दिशा में जाती है और सोचें कि किन पहलुओं का ज़्यादा उपयोग किया जा सकता है, तो बताई गई कमियों के बावजूद इसे और बेहतर तरीके से इस्तेमाल किया जा सकता है। यह C जैसा है, लेकिन इसमें GC है, सीमित ही सही पर generics का support भी है, और cross-compilation भी होती है! इस नज़रिए से देखें तो क्या यह काफ़ी बढ़िया भाषा नहीं है?

[riki3]

Java से Go पर आते समय मुझे शुरुआत में कुछ हद तक वैसा ही एहसास हुआ था।
अब मैं Go का इतना आनंद ले रहा हूँ कि लगता है Java पर बिताया समय अफसोस की बात है। यह कहा जाता है कि यह जटिल business applications के लिए उपयुक्त नहीं है, तो इससे मुझे उल्टा यही लगता है कि उस application ने system को सरल बनाने पर पर्याप्त गंभीरता से विचार नहीं किया।

[GN⁺]

Hacker News की राय

• जब Java डेवलपर Go पर Java स्टाइल थोपने की कोशिश करते हैं, तो समस्याएँ पैदा होती हैं

  • Go का दर्शन अल्पकाल में कम उपयोगी लग सकता है, लेकिन दीर्घकाल में बड़ा फर्क लाता है
  • जो लोग JVM ecosystem में बहुत गहराई तक डूबे हैं, उनके लिए Go का आनंद लेना मुश्किल होता है

• कई डेवलपर बहुत जल्दी abstraction करने की कोशिश करते हैं

  • जब एक साधारण loop काफी होता है, तब भी वे अनावश्यक abstraction बना देते हैं

• Go की standard library बड़ी है, लेकिन इतनी बड़ी नहीं कि सब कुछ कर सके

  • हर project में पहिया फिर से बनाने की प्रवृत्ति होती है
  • Go server/CLI applications के लिए आदर्श है

• programming language चुनने से भी बड़े challenge मौजूद हैं

  • Go के mechanism और दर्शन के अनुसार खुद को ढालना महत्वपूर्ण है

• यह समझना मुश्किल है कि लोग Go को क्यों पसंद करते हैं

  • भाषा से ज़्यादा उसकी toolchain और deployment की आसानी को पसंद किया जाता है

• Go की core team का गलत फैसलों को वापस लेना निराशाजनक लगता है

  • एक अच्छा package system और tools मौजूद हैं
  • जटिल ERP systems के लिए Java बेहतर विकल्प हो सकता है

• Go में UNIX जैसी समस्याएँ हैं

  • यह complexity को user पर थोपने की प्रवृत्ति रखता है
  • Java runtime, Go की तुलना में, तेज़ी से विकसित हो रहा है