Go मानक लाइब्रेरी में UUID पैकेज जोड़ने का प्रस्ताव

 (github.com/golang)
1 पॉइंट द्वारा GN⁺ 2026-03-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Go भाषा में UUID बनाने और parse करने की functionality को standard library में शामिल करने का प्रस्ताव GitHub पर चर्चा में है
  • प्रस्तावक ने इसके समर्थन में यह तर्क दिया कि अभी अधिकांश Go server·DB projects github.com/google/uuid जैसे बाहरी package पर निर्भर हैं
  • C#, Java, Python जैसी प्रमुख भाषाएँ पहले से ही standard library स्तर पर UUID support देती हैं
  • चर्चा के दौरान UUIDv7 जैसे नए specs, RFC 9562 अनुपालन, parsing functionality को शामिल करने की सीमा, और API consistency जैसे मुद्दे मुख्य विवाद बिंदु रहे
  • यह प्रस्ताव बाद में crypto/rand package के UUIDv4·UUIDv7 support proposal (#76319) में समाहित होकर आगे बढ़ रहा है

प्रस्ताव का अवलोकन

  • Go standard library में UUID generation और parsing API जोड़ने का प्रस्ताव रखा गया
    • लक्षित versions हैं UUID v3, v4, v5
    • मुख्य आधार हैं बाहरी package पर निर्भरता और अन्य भाषाओं में standard support के उदाहरण
  • UUID एक अंतरराष्ट्रीय standard है जिसे RFC 4122 (बाद में RFC 9562) में परिभाषित किया गया है
  • प्रस्तावक का कहना है कि प्रमुख भाषाओं में Go एक अपवाद है, जहाँ UUID के लिए standard support नहीं है

शुरुआती प्रतिक्रिया और चर्चा

  • कुछ प्रतिभागियों ने बताया कि अतीत में भी ऐसे प्रस्ताव आए थे, लेकिन उन्हें अस्वीकार किया गया था (#23789, #28324)
    • कारण यह था कि बाहरी package का उपयोग पर्याप्त रूप से आसान है, और उनकी release cycle standard library से अधिक लचीली होती है
  • प्रस्तावक का तर्क था, “यदि अधिकांश projects को हर बार बाहरी package import करना ही पड़ता है, तो उसे standard में शामिल करना बेहतर है”
  • इस बात को भी समर्थन के आधार के रूप में रखा गया कि कई भाषाएँ UUID को crypto-संबंधित standard library में शामिल करती हैं

नए UUID versions और RFC का परिप्रेक्ष्य

  • कुछ मतों में कहा गया कि UUID v1~v5 पुराने हो चुके हैं, और v7 नया तथा अधिक आशाजनक version है
    • v7 के कई implementation विकल्प मौजूद हैं, इसलिए इसके व्यावहारिक परिणामों को देखना ज़रूरी है
  • RFC draft में यह सिफारिश की गई थी कि UUID को अनावश्यक रूप से parse न किया जाए और उसे opaque identifier की तरह माना जाए
  • बाद में RFC 9562 के औपचारिक रूप से जारी होने पर, संबंधित चर्चा UUIDv7 support पर केंद्रित हो गई

प्रस्ताव में संशोधन और विलय

  • 2025 में RFC 9562 के आधिकारिक होने के बाद यह उल्लेख आया कि PostgreSQL 18 ने UUIDv7 support जोड़ दिया है
  • इसके बाद Go पक्ष में crypto/rand package में केवल UUIDv4·UUIDv7 generation functionality जोड़ने का अलग प्रस्ताव (#76319) शुरू किया गया
    • parsing functionality को RFC की सिफारिश के अनुसार बाहर रखा गया
  • मूल प्रस्ताव (#62026) को duplicate मानकर बंद कर दिया गया

API design पर चर्चा

  • uuid.New() का default behavior v4 होना चाहिए या भविष्य में बदला जा सके, इस पर चर्चा हुई
    • कुछ लोगों ने कहा कि “अगर version बदलता है तो compatibility problems आ सकती हैं”, इसलिए इसे हमेशा v4 पर fixed रखना चाहिए
  • Compare, MustParse, Parse जैसे methods देने या न देने पर भी चर्चा हुई
    • Compare के बारे में मत था कि RFC परिभाषा के अनुसार sortable UUID support के लिए यह ज़रूरी हो सकता है
    • MustParse को standard library की अन्य Must* functions के साथ consistency बनाए रखने के लिए शामिल करने की बात हुई
  • निष्कर्ष यह निकला कि IsZero() method UUID type के लिए आवश्यक नहीं है
  • Generator struct लाने, version-specific types (UUIDv4, UUIDv7 आदि) अलग करने जैसे कई design proposals सामने आए
  • कुछ लोगों ने New() function की अस्पष्टता की ओर इशारा करते हुए कहा कि सिर्फ explicit version functions (NewV4, NewV7) ही दी जानी चाहिए

मुख्य तकनीकी मुद्दे

  • यह चर्चा हुई कि UUID sorting की परिभाषा केवल v6·v7 में ही स्पष्ट रूप से मौजूद है या नहीं
  • UUIDv7 generation के समय time-based sorting guarantee और concurrency collisions से बचाव (counter-based approach) की implementation पर विचार हुआ
  • version के अनुसार अर्थ का अंतर (जैसे v1 में MAC address शामिल होता है, v7 time-based है) के कारण single type design की सीमाएँ बताई गईं
  • कुछ मतों में version-specific types को अलग करने और explicit conversion methods (AsV4(), AsV7() आदि) जोड़ने का सुझाव दिया गया

निष्कर्ष और वर्तमान स्थिति

  • Go community कुल मिलाकर UUID के लिए standard support की आवश्यकता से सहमत दिखती है
  • लेकिन, standard library की सादगी बनाए रखने और RFC की सिफारिशों का पालन करने के लिए
    • parsing functionality को हटाया गया
    • और केवल UUIDv4·UUIDv7 generation functionality को crypto/rand में जोड़ने की दिशा तय हुई
  • मूल प्रस्ताव (#62026) अब #76319 प्रस्ताव में समाहित होकर आगे बढ़ रहा है,
    और Go भाषा में UUID standard support के औपचारिक रूप लेने की स्थिति काफ़ी नज़दीक आ गई है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-08
Hacker News की राय

  • यह बात दिलचस्प लगी कि UUID वर्शन 1~5 को पहले से ही पुराना कहा जा रहा है
    लेकिन v4 में अब भी सबसे ज़्यादा randomness है, और distributed DB में hotspot समस्या और privacy issues से बचने के लिए इसे primary key के रूप में सुझाया जाता है
    संदर्भ लिंक: CockroachDB UUID दस्तावेज़, Google Cloud Spanner UUID गाइड

    • मुझे भी वह बात अजीब लगी। v7 तब अच्छा है जब monotonicity चाहिए, लेकिन timestamp system information को expose कर सकता है। इसलिए v4 अब भी वैध है
    • मुझे लगता है “outdated” शब्द ठीक नहीं है। असली समस्या requirements mismatch है, उम्र नहीं
      हर UUID वर्शन (v4 सहित) कुछ खास स्थितियों में कमज़ोर पड़ता है। वास्तव में कई संगठन standard UUID की जगह pure 128-bit values खुद define करके इस्तेमाल करते हैं
      आखिरकार UUID की design limitations से आगे निकल जाने वाली complex requirements बहुत बढ़ गई हैं
    • v4 default choice है, और सिर्फ़ तब दूसरे वर्शन इस्तेमाल किए जाते हैं जब खास तौर पर order preservation चाहिए
    • अगर सच में 128-bit randomness चाहिए, तो सीधे 128-bit random number इस्तेमाल कर लो। उसे UUID format में फिट करने की ज़रूरत नहीं है
    • लेकिन v4 B-Tree inserts को बिगाड़ सकता है। मैंने सीखा है कि kernel की page caching efficiency की वजह से v7 काफ़ी तेज़ होता है

  • आज HN पर ऐसी छोटी-सी Go-related खबर आना अच्छा लगा
    आजकल तो बस programming के future या AI की बातें होती हैं, इसलिए ऐसा technical topic ताज़गी भरा लगा

    • काफ़ी समय बाद गहराई वाली technical discussion देखकर अच्छा लगा
    • AI से जुड़ी डर फैलाने वाली बातों (FUD) से थोड़ी देर के लिए बाहर निकलकर सुकून मिला। पहले HN खोलने पर बेचैनी नहीं होती थी, लेकिन आजकल सब बस “सब बर्बाद हो जाएगा” जैसी बातें करते हैं
    • ऊपर से यह छोटा technical issue लगता है, लेकिन असल में यह Go language की architecture और leadership direction को प्रभावित करने वाला बड़ा फ़ैसला है
      perfectionists, practical developers, और crypto community — तीनों की अलग-अलग राय है
      संबंधित दस्तावेज़: RFC 9562
      मैं चाहता हूँ कि Go सही फ़ैसला ले। ख़ासकर TinyGo microcontrollers के लिए वाकई शानदार है
    • Go को नापसंद करने वालों का नज़रिया मज़ेदार है। अब AI code पढ़ने के दौर में language criticism का मज़ा भी जैसे ख़त्म हो गया है

  • मुझे Go के UUID generation support से ज़्यादा फ़र्क नहीं पड़ता, लेकिन standard UUID type का आना वाकई बहुत अहम है
    इससे JSON, Text, database/sql आदि में consistent marshaling संभव होगा
    हाल की Go dependency analysis में google/uuid दूसरा सबसे ज़्यादा इस्तेमाल होने वाला package था
    संबंधित विश्लेषण: The most popular Go dependency

    • मैं भी चाहता हूँ कि dec128 type standard में आए। अगर उसे ऐसे struct के रूप में दिया जाए जिसे uint128 में आसानी से बदला जा सके, तो आदर्श होगा

  • Go की असली खूबी चमकदार features में नहीं बल्कि practicality में है
    भाषा इतनी complex नहीं बनती कि टूटने लगे, और सिर्फ़ ज़रूरी features ही जोड़े जाते हैं

    • मैंने भी हाल ही में कई versions छोड़कर upgrade किया, और कोई समस्या नहीं हुई
      compatibility guarantee की वजह से इसे निश्चिंत होकर इस्तेमाल किया जा सकता है। बदलाव धीमे हैं, लेकिन भाषा लगातार बेहतर होती रहती है

  • Google का uuid package inactive होना जितना मायने नहीं रखता, उससे ज़्यादा अहम यह है कि gofrs/uuid नया standard follow करता है और actively maintained है
    gofrs/uuid repository

    • external dependency के बिना library बनाना मज़ेदार होता है। इस बदलाव से ऐसा काम और आसान हो जाएगा
    • लेकिन google/uuid में 2024 के बाद कोई release नहीं आया, और 2025 के जून में भी उससे जुड़ा issue खुला है
      Issue #194
    • इस proposal पर पहले से ही 3 साल से चर्चा चल रही थी

  • मुझे UUID सच में नापसंद हैं। ये human-friendly नहीं होने वाले identifiers हैं
    debugging या query results में ये बहुत लंबे और असुविधाजनक लगते हैं।
    हाँ, पूरी तरह अलग systems के बीच unique ID चाहिए हो तो ये काम के हैं, लेकिन ज़्यादातर जगह इनका ज़रूरत से ज़्यादा इस्तेमाल होता है
    सामान्य मामलों में centralized number issuer कहीं बेहतर होता है।
    उदाहरण के लिए DB की GetNextId जैसी प्रक्रिया ज़्यादा मानवीय और efficient है

    • पहले एक कंपनी में हम 6-अंकों के code से projects manage करते थे, लेकिन किसी ने उसे UUID से बदल दिया
      नतीजा यह हुआ कि वह मानव-पठनीय न रहने वाला code बन गया, और ऊपर से custom implementation होने के कारण अजीब तरह से sequential भी था। पूरी तरह खराब फ़ैसला था
    • असल में ज़्यादातर मामलों में integer counter ही काफ़ी होता है
      Postgres में counter table इस्तेमाल करके प्रति सेकंड दसियों हज़ार ID बनाई जा सकती हैं
      इससे memory savings, compression efficiency, hash map performance भी बेहतर होती है
      UUID सुविधाजनक है, लेकिन performance खराब करता है
    • अच्छा होता अगर इसमें कोई human-readable तत्व भी होता
      उदाहरण: BASKETBALL-...-FISH जैसी form में word-based checksum जोड़ दिया जाए, तो याद रखना आसान होगा
    • “deterministic randomization” का ज़िक्र आया था, और मुझे भी लगता है कि LFSR(linear feedback shift register) जैसी विधि ठीक हो सकती है

  • मैं सोच रहा था कि क्या UUID सच में Go में जोड़ा जा रहा है

    • अभी यह ‘Likely accept’ स्थिति में है। Go project board पर देखा जा सकता है
      अगर कोई खास विरोध नहीं हुआ, तो शामिल होने की संभावना काफ़ी है
    • हाँ, इसे जोड़ा जाएगा

  • Kotlin ने भी हाल ही में version 2.3 में RFC 9562-based UUID version support standard library में जोड़ा है
    JVM, JS, WASM, Native सभी supported हैं।
    IETF RFC स्थिर हो चुका है, इसलिए Go का उसका अनुसरण करना उचित है

  • यह थोड़ा अफ़सोसजनक है कि Go में ऐसी basic functionality support की कमी है

    • सोचता हूँ किस language ने इसे standardize करने का काम बेहतर किया है। शायद Java? Python और Rust में भी स्थिति मिलती-जुलती है
    • “batteries included” का मतलब 20 साल में बहुत बदल गया है। शायद Google के अंदर इसकी ज़रूरत नहीं रही होगी
    • UUID आखिर 16-byte array ही तो है। v4 generation कुछ lines में हो जाता है। यह कोई बहुत बड़ी बात नहीं है
    • जानना चाहूँगा कि किस functionality की कमी महसूस होती है
      मेरी नज़र में Go का logging system बहुत basic है, इसलिए मुझे खुद implement करना पड़ा
      slog module धीमा और असुविधाजनक है। लगता है जैसे सिर्फ़ enterprise environment को ध्यान में रखकर बनाया गया हो
    • फिर भी Go की standard library quality बेहतरीन स्तर की है। मुझे लगता है रोज़मर्रा के development में यह सबसे ज़्यादा काम आने वाली stdlib है

  • मैं सोच रहा था कि क्या v7 की DB clustering efficiency और v4 की randomness दोनों एक साथ पाई जा सकती हैं
    अंदरूनी तौर पर v7 इस्तेमाल करके, और बाहर भेजते समय XOR या AES से scrambling करके शायद यह संभव हो सकता है

    • वास्तव में ऐसी कोशिश मौजूद है: uuidv47 project
    • अगर privacy ही उद्देश्य है, तो शायद integer keys को encrypt करना बेहतर होगा
      उदाहरण के लिए Feistel encryption का इस्तेमाल करके UUID की performance समस्याओं के बिना opaque public ID बनाए जा सकते हैं