Go के enums बेकार हैं

मूल लेख ↗ Hacker News चर्चा ↗

Go का enums के प्रति रवैया—असल में `iota` helper के साथ बस integer constants—को Rust, Ada, Java, या यहाँ तक कि 1970 के दशक के Pascal जैसी भाषाओं के richer enum या sum-type systems की तुलना में primitive और unsafe कहा गया है। टिप्पणीकार इस पर बहस करते हैं कि क्या Go को exhaustiveness checking और safer serialization वाले true, type-safe enums जोड़ने चाहिए, या फिर इसका minimalist, “ज़रूरत हो तो बस ints और codegen/protobuf इस्तेमाल करो” वाला दर्शन simplicity और सामान्य web/backend काम के लिए ease of use के बदले एक जानबूझकर स्वीकार्य trade-off है। यह चर्चा type safety, error handling, और इस व्यापक सवाल को भी छूती है कि किसी भाषा को features जोड़ने में कितना आगे जाना चाहिए बनाम core को छोटा और opinionated रखना चाहिए।

“enums” आखिर होते क्या हैं (enums बनाम sum types)

  • कई टिप्पणियाँ पारंपरिक enums (नामित constants के सीमित सेट, आम तौर पर integer backing और स्वाभाविक iteration/ordering के साथ) और algebraic/sum types (ऐसे variants जो structured data रख सकते हैं और जिनके लिए pattern matching चाहिए) के बीच अंतर करती हैं।
  • Rust का enum बार-बार एक sum type के रूप में उद्धृत किया गया है, न कि पारंपरिक अर्थ में “सच्चा enum”, हालांकि कुछ लोगों का तर्क है कि व्यवहार में यह भेद बहुत उपयोगी नहीं है।
  • कुछ लोगों को enums और sum types को एक ही अवधारणा में मिलाने की कोशिश भ्रमित करने वाली और वैचारिक रूप से हानिकारक लगती है; दूसरे लोग उनके साझा “विकल्पों में से एक चुनाव” वाले उपयोग-केस पर ध्यान देते हैं।

Go की मौजूदा “enum” कहानी

  • Go में dedicated enum keyword नहीं है; idiom है type T int और फिर const (...) के साथ iota।
  • आलोचनाएँ:
    • यह बंद सेट नहीं है; कोई भी underlying int बनाया जा सकता है, जिसमें invalid values भी शामिल हैं।
    • built-in string representation नहीं है, switch में exhaustiveness checking नहीं है, और base type से परे असंबंधित “enum” types को मिलाने से रोकने की व्यवस्था नहीं है।
    • कुछ लोगों के अनुसार serialized values के लिए iota खतरनाक है, क्योंकि constants को reorder करने से numeric encodings चुपचाप बदल जाती हैं।
  • बचाव:
    • बहुतों को iota संक्षिप्त और बेहद सुविधाजनक लगता है, खासकर bit flags के लिए।
    • कुछ का तर्क है कि Go के “enums” असली enums हैं (distinct type के named constants) और अतिरिक्त guardrails, बढ़ी हुई complexity के लायक नहीं हैं।
    • arbitrary ints पास करना कुछ लोगों को स्पष्ट रूप से caller bug माना जाता है, type-system failure नहीं।

Workarounds और tools

  • आम patterns: code generators (go generate, third-party tools, custom DSLs) ताकि stringification, JSON/Protobuf integration, और validation जोड़ी जा सके।
  • अगर पहले से gRPC/Protobuf इस्तेमाल हो रहा है, तो Protobuf enums को एक मजबूत विकल्प बताया गया है, जिसमें safe evolution और cross-language support शामिल है।

व्यापक language-design बहस

  • एक पक्ष Go के minimalism, तेज़ builds, सरल tooling, और REST/DevOps काम के लिए इसकी “blue-collar” उपयुक्तता की प्रशंसा करता है।
  • दूसरा पक्ष भाषा को primitive और “boneheaded” कहता है, क्योंकि यह स्थापित features (generics, proper enums, sum types, null safety, richer type constraints) का विरोध करती है।
  • तुलनाएँ दिखाती हैं कि कई पुराने या अन्य भाषाओं (Pascal, Ada, Rust, MLs, C#, Java) में मजबूत enums या ADTs हैं, compile-time exhaustiveness और type systems के साथ बेहतर integration सहित।

Error handling और optionality

  • कुछ लोगों का तर्क है कि Go के explicit error returns समझदार हैं और errors को सामान्य control flow की तरह treat करते हैं।
  • दूसरे Result/Either/Option-style sum types को पसंद करते हैं और Go में ऐसे constructs की कमी (साथ ही हर जगह nilability) को एक बड़ा design gap मानते हैं।