बैकवर्ड compatibility, Go 1.21, और Go 2

• Go programming language में backward compatibility के महत्व पर लेख, जिसमें Go 1.21 की नई सुविधाओं और Go 2 के भविष्य पर फोकस है
• Go 1.21 में compatibility सुधारने के लिए नई सुविधाएँ शामिल हैं, ताकि Go स्थिर और पूर्वानुमेय बना रहे और डेवलपर्स भाषा के बदलावों की बजाय अपने काम पर ध्यान दे सकें
• Go टीम 10 साल से अधिक समय से compatibility पर केंद्रित है, और Go 1 specification के अनुसार लिखे गए प्रोग्राम उस specification की पूरी अवधि तक बिना बदलाव के सही तरह compile और run होंगे, यही स्पष्ट उद्देश्य है
• compatibility बनाए रखने के लिए दो मुख्य तरीकों की व्याख्या: API check और testing. API check यह सुनिश्चित करता है कि मौजूदा API हटाए न जाएँ या ऐसे न बदले जाएँ कि पुराना code टूट जाए. Testing में अगले Go release के development version पर मौजूदा tests चलाना शामिल है
• Google के अंदर Go को test करके पाए गए सूक्ष्म compatibility issues के उदाहरण दिए गए हैं, जैसे struct literal और नए fields, time precision आदि
• compatibility issues को तीन श्रेणियों में बाँटा गया है: output changes, input changes, और protocol changes
• Go 1.21, GODEBUG के उपयोग को विस्तारित और औपचारिक बनाकर backward compatibility को बेहतर करता है. GODEBUG settings कम से कम दो साल तक बनाए रखी जाती हैं और main package की go.mod file में सूचीबद्ध Go version के अनुरूप सेट की जाती हैं
• लेख का समापन Go 2 पर अपडेट के साथ होता है: ऐसा कोई Go 2 नहीं होगा जो Go 1 programs को तोड़े. इसके बजाय Go टीम compatibility को प्राथमिकता देती रहेगी, और उसका मानना है कि यह Go 1 के लिए लिया गया सबसे महत्वपूर्ण design decision है

[GN⁺]

Hacker News राय

• यह लेख Go 1.21 में compatibility के महत्व और संभावित भविष्य के Go 2 पर चर्चा करता है।
• Go 1.21 दो अनोखी सुविधाएँ देता है: हर बदलाव के लिए GODEBUG settings और पुराने implementation के उपयोग का पता लगाने के लिए metrics, साथ ही module-स्तर के toolchain versions जो पुराने और नए go toolchains को अपने-आप लाते हैं।
• जब Go का कोई specific version निर्धारित किया जाता है, तो नए Go versions अपने-आप संबंधित opt-out configuration लागू करते हैं, ताकि नया behavior तब तक लागू न हो जब तक उसे स्पष्ट रूप से न माँगा जाए।
• Go language team backward compatibility बनाए रखने के लिए प्रतिबद्ध है, और बड़े Go systems को maintain करने वाले developers इसके लिए उनकी सराहना करते हैं।
• कुछ users चिंता जताते हैं कि type system में महत्वपूर्ण सुधारों के लिए breaking changes की आवश्यकता पड़ सकती है।
• यह सुझाव दिया गया है कि Go को वास्तव में Go 2 नहीं होना चाहिए, क्योंकि बड़े बदलावों के लिए भाषा को fork करने और उसका नाम बदलने की जरूरत पड़ सकती है।
• Go की स्थिरता और predictability, जिसे "boring" कहा जाता है, बिखरे हुए और लगातार बदलते JavaScript ecosystem के विपरीत दिखती है।
• यह लेख "Go 1.21 में forward compatibility और Toolchain प्रबंधन" पर एक संबंधित पोस्ट का भी उल्लेख करता है।
• Go में backward compatibility के प्रति प्रतिबद्धता की प्रशंसा की जाती है, और एक user साझा करता है कि Python से Go में code बदलने से उनके विस्तार में कैसे मदद मिली।
• compatibility सुनिश्चित करने के लिए Go में उपयोग की जाने वाली techniques का सम्मान किया जाता है, और अन्य languages के design में उनके उपयोग पर विचार किया जा रहा है।