Go: हमने क्या सही किया, क्या गलत किया

Go का उद्देश्यित क्षेत्र और यह क्या बन गया

• Google में C++ के लिए एक सरल, तेज़ विकल्प के रूप में डिज़ाइन किया गया था, सर्वरों और “systems software” के लिए (व्यापक अर्थ में: servers, networking, infrastructure), kernels या drivers के लिए नहीं।
• कई टिप्पणीकार कहते हैं कि Go अंततः एक “server / internet backend” और CLI भाषा अधिक बन गया, बजाय एक low-level systems भाषा के।
• कुछ लोग तर्क देते हैं कि इसने server/infrastructure काम में C++ और कुछ Python को सफलतापूर्वक काफी हद तक विस्थापित किया; अन्य कहते हैं कि यह C/C++/Rust की तुलना में Java/C# से अधिक प्रतिस्पर्धा करता है।

Scientific computing, FFI, और HPC

• शुरुआती Go टीम ने कथित रूप से scientific/HPC use cases, REPLs, और scripting-language integration को खारिज कर दिया था; इसे एक खोया हुआ अवसर माना जाता है।
• cgo और gc compiler के C call overhead की व्यापक रूप से आलोचना होती है; Go को कमजोर FFI कहानी वाला माना जाता है, खासकर scientific computing के लिए जहाँ C/Fortran interop महत्वपूर्ण है।
• विपरीत तर्क: अधिकांश scientific काम Python/R/Julia में scripting होता है; एक systems भाषा के रूप में Go वैसे भी प्राकृतिक फिट नहीं है।

Concurrency और goroutines

• Goroutines को user-space “green threads” या OS threads के ऊपर stackful fibers के साथ M:N scheduling के रूप में वर्णित किया जाता है; high-concurrency servers के लिए अच्छा।
• कुछ लोग मानते हैं कि Go ने goroutines को नया बताकर जरूरत से ज्यादा बेचा; अन्य इसे पुराने green-thread systems से मिलता-जुलता होने के बावजूद एक व्यावहारिक, सफल model मानते हैं।
• यह concurrency model C FFI को जटिल बनाता है और runtime design को प्रभावित करता है (जैसे, runtime पर code generation नहीं)।

Error handling, panics, और nil

• error-as-values plus panics सबसे विवादित क्षेत्रों में से एक है:
  • आलोचक: verbose, दोहरावदार if err != nil patterns, errors को गलती से swallow कर देने की आसानी, दो समानांतर mechanisms (errors vs panics) जो साफ़ तौर पर मेल नहीं खाते, और painful nil handling (interface vs concrete nil gotchas सहित)।
  • समर्थक: explicit errors सरल और अनुमानित हैं, handling को प्रोत्साहित करते हैं, और hidden control flow से बचाते हैं।
• Nil pointers और null-safety की कमी को बड़े design mistakes के रूप में उद्धृत किया जाता है; कुछ tools (जैसे linters, nil analyzers) इसे कम करने की कोशिश करते हैं।

Generics और type system

• Generics जोड़ने में लंबी देरी पर बहुत बहस होती है:
  • पक्ष में: इंतज़ार ने ऐसे flawed designs से बचाया जिन्हें बाद में ठीक करना कठिन होता।
  • विपक्ष में: generics के बिना launch करना पुरानी गलतियों को दोहराना था (जैसे Java pre-generics), APIs को विकृत किया, और interface{} हर जगह जैसे workaround मजबूर किए।
• मौजूदा generics को उपयोगी लेकिन अधूरे के रूप में देखा जाता है (जैसे method-level generics की कमी), और existing interface semantics से सीमित।

Modules, packaging, और tooling

• शुरुआती GOPATH/go get व्यवहार और import-by-URL की आलोचना naïve और Google के monorepo के लिए overfitted के रूप में की जाती है; इस अंतराल में community package managers बढ़े।
• Official modules और MVS को आम तौर पर एक बड़ा सुधार माना जाता है, हालांकि SIV (v2+) , private repos, और SSH/git config अभी भी परेशानी के बिंदु हैं।
• gofmt, unified tooling (go build/test/fmt), static binaries, और अपेक्षाकृत तेज़ compilation को व्यापक रूप से बड़ी strengths माना जाता है।

Community process और evolution

• कुछ लोग Go leadership को generics, monotonic time, crypto updates, REPLs, और context usage जैसी समस्याओं पर बहुत dismissive/slow मानते हैं।
• अन्य लोग “no” कहने, भाषा को छोटा रखने, और stability तथा tooling को rapid feature accretion से ऊपर रखने की तत्परता की प्रशंसा करते हैं।