Core Types को हटाना और Go भाषा का सरल विकास

(go.dev)

3 पॉइंट द्वारा GN⁺ 2025-03-28 | 6 टिप्पणियां | WhatsApp पर शेयर करें

Go 1.18 में generics फीचर की शुरुआत के साथ एक नया कॉन्सेप्ट core type जोड़ा गया था, लेकिन 1.25 में इसे हटाने का फैसला किया गया है
core type कंपाइलर इम्प्लीमेंटेशन की सुविधा के लिए बनाया गया एक अमूर्त कॉन्सेप्ट था, जो generic type operands को संभालते समय मौजूदा underlying type की जगह लेता था
भाषा विनिर्देशन में भी पहले के "underlying type" की जगह "core type" का उपयोग किया गया था

Type parameters और type constraints

type parameters भविष्य में तय होने वाले type के लिए placeholder की तरह काम करते हैं और compile time पर निर्धारित होते हैं
type constraints यह तय करते हैं कि उस parameter type पर कौन-से operations संभव हैं
Go में methods और type requirements को मिलाकर type constraints परिभाषित किए जाते हैं, और इससे एक type set बनता है
type set का मतलब उन सभी types के समूह से है जो किसी खास interface को satisfy करते हैं
```
type Constraint interface {  
  ~[]byte | ~string  
  Hash() uint64  
}  
```
type set आधारित यह तरीका generic type operations को परिभाषित करने के लिए बहुत flexible और शक्तिशाली है
```
func at[bytestring Constraint](s bytestring, i int) byte {  
  return s[i]  
}  
```

core type की शुरुआत और उसकी सीमाएँ

core type को कुछ operations में generic types के उपयोग को सरल बनाने वाले नियम के रूप में परिभाषित किया गया था
core type को परिभाषित करने का तरीका:
- यदि वह एक सामान्य type है, तो उसका core type उसके underlying type के समान होता है
- यदि वह type parameter है, तो type set के भीतर सभी types का underlying type समान होने पर ही core type मौजूद होता है
लेकिन इस तरीके से ये समस्याएँ पैदा हुईं:
- भाषा विनिर्देशन जटिल हो गया, जिससे सरल नियम भी समझना कठिन हो गया
- non-generic code में भी अनावश्यक रूप से core type कॉन्सेप्ट का उल्लेख होने लगा
- core type का उपयोग करने वाले कुछ operations जरूरत से ज़्यादा restrictive हो गए, जिससे वास्तव में सुरक्षित operations भी अनुमति नहीं पाते थे
- core type का उपयोग न करने वाले नियमों के साथ असंगति के कारण पूरे language design में consistency कम हो गई

Go 1.25 में core type हटाया जाएगा

Go 1.25 रिलीज़ (अगस्त 2025 के लिए निर्धारित) में भाषा विनिर्देशन से core type कॉन्सेप्ट को हटाने का फैसला किया गया है
अब हर operation के लिए आवश्यक constraints को स्पष्ट वाक्यों में लिखा जाएगा
इस बदलाव के मुख्य प्रभाव:
- कॉन्सेप्ट्स की संख्या कम होगी, जिससे Go भाषा सीखना आसान होगा
- non-generic code generic कॉन्सेप्ट्स पर निर्भर हुए बिना अधिक स्पष्ट रहेगा
- अलग-अलग operations के लिए अधिक flexible rules डिज़ाइन किए जा सकेंगे
- भविष्य में फीचर विस्तार की नींव तैयार होगी (जैसे common field access, slice functionality में सुधार, type inference में सुधार आदि)

मुख्य बदलाव और अपेक्षित प्रभाव

विनिर्देशन में जहाँ-जहाँ core type का उल्लेख था, उन सभी वाक्यों को हटाया गया है या स्पष्ट वाक्यों से बदला गया है
compiler error messages से भी core type शब्द हटाया गया है और उसकी जगह अधिक ठोस व्याख्याएँ दी गई हैं
मौजूदा Go programs के व्यवहार पर इसका कोई प्रभाव नहीं पड़ेगा
भाषा विनिर्देशन अधिक सरल होगा, और उपयोगकर्ताओं के लिए Go भाषा अधिक सहज और स्पष्ट बनेगी

6 टिप्पणियां

GN⁺ 2025-03-28

Hacker News राय

यह अच्छा लगता है कि Go टीम specification में बदलावों को बहुत सावधानी से संभालती है
- Go generics एक बड़ा बदलाव है और इसका उपयोग करना कठिन हो सकता है
- मेरा मानना है कि constraints generics के अत्यधिक उपयोग को रोकते हैं
- Java और Typescript प्रोजेक्ट्स में type system का अत्यधिक उपयोग होने पर कोड को अस्पष्ट होते देखा है
- उम्मीद है कि Go टीम भाषा के प्रति रूढ़िवादी रुख बनाए रखे
Go डेवलपमेंट टीम के पिछले 10 साल features और simplicity के बीच संतुलन खोजने की प्रक्रिया रहे हैं
- generics इस गतिशीलता को अच्छी तरह दिखाते हैं
- Go के ऊपर Rust जैसी type system लागू करना बहुत अधिक जटिलता है
- simplicity को महत्व देने वाली दिशा में थोड़ा लौटना अच्छा है
- Go का लक्ष्य mid-level इंजीनियर टीमों के लिए बेहतर Java बनना है
Go 1.25 वास्तव में कोई नया language feature नहीं जोड़ता
- 1.30 में शायद sum types जोड़े जा सकते हैं
मैं Go को Windows build से पहले के समय से फॉलो कर रहा हूँ
- 2011 में सीखी हुई हर चीज़ आज भी वैध है
- Go में काम करने का मौका नहीं मिला, लेकिन छोटे प्रोजेक्ट्स से सीखता रहा
- Go डेवलपर इंटरव्यू में यह सुनकर निराशा हुई थी कि शायद generics Go में नहीं आएँगे
- अब जबकि generics आ चुके हैं, Go में side project शुरू करने की योजना है
यह सही नहीं है कि जब close का argument type parameter हो तो सभी types समान element type वाले channel होने चाहिए
- element type का close पर कोई असर नहीं पड़ता, और अलग element types वाले type set के साथ भी compilation ठीक चलता है
- documentation में सुधार की ज़रूरत है
- उम्मीद है कि shared fields जैसी flexibility का विस्तार तेज़ होगा
मैं Go धीरे-धीरे सीख रहा हूँ, और मेरा background C++ का है
- सोच रहा हूँ कि क्या यह template specialization जैसा कुछ है
- चाहता हूँ कि और भाषाएँ भी इसे support करें
[dead]
अब जब generative AI कोड लिख सकता है, तो सोचता हूँ कि क्या garbage collector अभी भी ज़रूरी है

aer0700 2025-03-28

अब जबकि जनरेटिव AI कोड लिख सकता है, यह सोचने वाली बात है कि क्या garbage collector अभी भी ज़रूरी है।
> काफ़ी मायने रखता है...

galadbran 2025-03-29

ओह.. अगर AI उस स्तर का कोड (मेमोरी मैनेजमेंट को पूरी तरह सही तरीके से संभालने वाला कोड) लिखने लगे, तो इंसानी डेवलपर्स के लिए आज जैसी भूमिका में बने रहना मुश्किल होगा।

kandk 2025-03-28

1+1=2 को गणित से हल किया जा सकता है, तो फिर उसे AI से हल करने की क्या ज़रूरत है..

jeiea 2025-03-28

क्या इंसानों के पढ़ने लायक boilerplate और ट्रैक करने वाले code context को कम करने के लिहाज़ से GC भी मायने नहीं रखता होगा?
अगर आप यह अनुमान लगा रहे हैं कि code पढ़ने की ज़रूरत ही खत्म हो जाएगी, तो वह अलग बात है।
मूल comment भी धुंधला किया हुआ है, यह देखकर लगता है कि उससे बहुत लोग सहमत नहीं थे।

savvykang 2025-03-28

अगर मेमोरी allocation और deallocation का समय compile time पर निकाला जा सकता है, तो क्या reference counting हटाया नहीं जा सकता? ऐसा लगता है कि मूल Hacker News टिप्पणी के लेखक मेमोरी reuse की समस्या को समझ नहीं रहे हैं।