Golang में Hyrum's Law के लागू होने के उदाहरण

 (abenezer.org)
2 पॉइंट द्वारा GN⁺ 2024-11-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • Hyrum का नियम और Golang

    • हाल ही में Gocodebase को देखते समय एक दिलचस्प टिप्पणी मिली
    • एक कोड उदाहरण जिसमें यह टिप्पणी थी: "Hyrum's Law की वजह से इस टेक्स्ट को बदला नहीं जा सकता"
    • MaxBytesError struct की Error() मेथड "http: request body too large" एरर मैसेज लौटाती है

  • Hyrum का नियम

    • यह सिद्धांत Google के software engineer Hyrum Wright के नाम पर रखा गया है
    • जब बहुत से उपयोगकर्ता किसी API का इस्तेमाल करते हैं, तो सिस्टम का हर observable behavior किसी न किसी द्वारा depend किया जाएगा
    • कोड में चाहे जानबूझकर हो या संयोग से, हर observable behavior पर आखिरकार कोई न कोई निर्भर हो जाता है
    • यह समझाता है कि एरर मैसेज बदलने से मौजूदा कोड क्यों टूट सकता है

  • Golang में उदाहरण

    • crypto/rsa और internal/weak package में भी Hyrum's Law का ज़िक्र करने वाली टिप्पणियाँ मिलीं
    • crypto/rsa/rsa.go और crypto/rsa/pss.go में टिप्पणियों के उदाहरण
    • internal/weak package में टिप्पणी का उदाहरण

  • अवलोकन

    • यह केवल Golang तक सीमित नहीं है
    • JavaScript के evolution process में भी ऐसा ही phenomenon देखा जा सकता है
    • इस तरह की घटना को Hyrum's Law कहा जाता है

  • अंतिम विचार

    • यह याद दिलाता है कि ऐसा कोड बदलते समय सावधान रहना चाहिए जिस पर दूसरे लोग निर्भर हो सकते हैं
    • सिस्टम को इस तरह design करना महत्वपूर्ण है कि अनचाहे behavior पर निर्भरता न बने
    • यह याद रखना चाहिए कि छोटा बदलाव भी बड़ा असर डाल सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-11-23
Hacker News की राय

  • Hyrum's Law एक उपयोगी observation है, लेकिन गलत निष्कर्ष निकालने से बचना चाहिए। किसी function का कुल execution time भी एक observable property है, इसलिए function को optimize करके तेज़ बनाना 99.99999999% users के लिए अच्छा हो सकता है, लेकिन यह breaking change भी बन सकता है। इसलिए यह समझना चाहिए कि "breaking change" कोई technical contract नहीं, बल्कि social contract है। library authors को API के कौन-से हिस्से नहीं बदलेंगे, यह document करना चाहिए, और users के प्रति सहानुभूति रखनी चाहिए। library consumers को यह समझना चाहिए कि undocumented interfaces का उपयोग जोखिमभरा हो सकता है, और authors के प्रति सहानुभूति रखनी चाहिए

  • Go language में Hyrum's Law और backward compatibility को बहुत महत्व दिया जाता है। उदाहरण के लिए, GenerateKey function में MaybeReadByte का उपयोग किया जाता है ताकि algorithm fix न हो जाए। ECDSA key की समस्या को हल करने की कोशिश चल रही है। map iteration order को random बनाया जाता है ताकि internals expose न हों। rand.Rand का output compatibility promise का हिस्सा माना जाता है, इसलिए उसे बेहतर बनाने के लिए बहुत प्रयास किए जाते हैं। docs में कौन-से promise करने हैं और किन behaviors को deny करना है, इस पर हमेशा चर्चा होती है

  • किसी खास समस्या के समाधान के रूप में string-based errors की जगह sentinel errors इस्तेमाल करने की सिफारिश की जाती है। API consumers non-technical strings पर depend न करें, इसके लिए predefined error values, types, या constants का उपयोग करना चाहिए। Hyrum's Law मौजूद है, लेकिन उसके प्रभाव को कम किया जा सकता है

  • Hyrum's Law का मुकाबला करने का एक तरीका randomness जोड़ना है। QUIC protocol unused fields को random values पर set करता है ताकि routers packet पहचानने के लिए उन पर depend न करें। इसे "greasing" कहा जाता है, और यह "ossification" को रोकता है

  • Golang designers exceptions नहीं चाहते थे, लेकिन informal errors समस्याजनक हैं। pattern matching के बिना structured errors को handle करने के तरीकों पर चर्चा की ज़रूरत है

  • एक नौकरी में error message में typo मिला और उसे ठीक किया गया, लेकिन उस typo पर निर्भर dependencies इतनी गहरी थीं कि उसे बदलना संभव नहीं था, इसलिए उसे वापस original state में revert करना पड़ा

  • Go में errors को enum type बनाया जा सकता था, लेकिन string को type की तरह इस्तेमाल किया गया, इसलिए यह पता नहीं चलता कि consumers उस पर कैसे depend करेंगे। बेहतर alternatives होने के बावजूद यह एक पुराना design decision है

  • Hyrum's Law, Robustness Principle/Postel's Law के बिल्कुल उलट है। अगर आप accepted input के मामले में उदार हैं, तो आपको यह समझना और document करना चाहिए कि वह कैसे स्वीकार किया जाता है। API को accepted input के मामले में ज़्यादा उदार न होने देने की दिशा में design करने की कोशिश की जाती है

  • Hyrum's Law testing में अक्सर दिखाई देता है। guaranteed न किए गए behavior के बारे में assumptions की वजह से कई तरह के tests टूट जाते हैं। उदाहरण के लिए, Hashmap के element order में बदलाव, error messages में बदलाव, leap year handling के तरीके में बदलाव आदि

  • कुछ package authors Hyrum's Law को अधिक स्वीकार कर सकते हैं। json package की comments में यह पाया गया कि यह internal detail है, लेकिन widely used packages linkname के जरिए इसे access कर रहे हैं