1 पॉइंट द्वारा GN⁺ 2023-09-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • आने वाले Go 1.22 रिलीज़ में for loop range से जुड़ी एक आम गलती को ठीक करने की योजना है, जिसने कई कंपनियों में production समस्याएँ पैदा की हैं.
  • यह समस्या तब होती है जब loop variable का reference iteration खत्म होने के बाद भी बना रहता है और वह अनजाने में नया value ले लेता है.
  • यह समस्या concurrent और non-concurrent, दोनों तरह के Go code में आम है, और variable का reference iteration से आगे निकलता है या नहीं, इसकी analysis जटिल होने के कारण इसे पहचानना और ठीक करना कठिन रहा है.
  • इस तरह की गलतियों की पहचान करने वाले मौजूदा tools अक्सर false negative या false positive देते हैं, जिससे बेवजह code changes या छूट गई समस्याएँ पैदा होती हैं.
  • Go 1.22 में प्रस्तावित सुधार for loops को per-loop scope की बजाय per-iteration scope देने के लिए semantics बदलता है, जिससे इस तरह की गलतियाँ और inaccurate tools की ज़रूरत खत्म हो जाएगी.
  • backward compatibility बनाए रखने के लिए, नई semantics केवल उन modules के packages पर लागू होगी जो go.mod file में Go 1.22 या उससे ऊपर declare करते हैं.
  • developers यह नियंत्रित कर सकेंगे कि किस package में semantics कब बदले, और मौजूदा code अभी की तरह काम करता रहेगा.
  • Go 1.21 में इस scope change का एक preview शामिल है, जिसे environment में GOEXPERIMENT=loopvar सेट करके enable किया जा सकता है.
  • इस बदलाव का Google में व्यापक रूप से परीक्षण किया गया है, और production code में कोई reported problem नहीं मिली.
  • हालांकि, loop variable समस्या के कारण कुछ tests, जो मूल रूप से जिस चीज़ को test करना चाहते थे उसे test नहीं कर रहे थे, उन्हें ठीक करना पड़ा.
  • Go 1.21 का loopclosure analyzer इस तरह की समस्याओं की पहचान और reporting में बेहतर बनाया गया है, ताकि developers Go 1.22 के बदलाव के लिए तैयार हो सकें.
  • इस बदलाव के बारे में अधिक जानकारी design document और FAQ में मिल सकती है.

1 टिप्पणियां

 
GN⁺ 2023-09-20
Hacker News राय
  • 'Go 1.22' में 'for loops' समस्या पर चर्चा, खास तौर पर closures में loop variable के गलत इस्तेमाल पर फोकस
  • closures में loop variable के गलत इस्तेमाल की समस्या नई नहीं है, और इसका इतिहास 1992 की Lisp भाषा तक जाता है
  • C# language team भी इस समस्या से गुज़री थी और इसे हल करने के लिए C# 5.0 में एक बड़ा बदलाव लागू किया गया था
  • Go 1.21, Go 1.22 के बाद घोषित किए गए code को compile नहीं करता, जिससे यह सुनिश्चित होता है कि नए semantics पर निर्भर code पुराने semantics के साथ compile न हो
  • इस बात को लेकर चिंता है कि क्या यह बदलाव उन programs को तोड़ देगा जो मौजूदा behavior पर निर्भर हैं
  • कुछ users ने सवाल उठाया कि अगर package को 1.22 पर pin किया गया हो और user उसे 1.18 से compile करे, तो यह व्यवहार में वास्तव में कैसे काम करेगा
  • इस बदलाव का memory allocation और loop performance पर क्या असर पड़ेगा, इस पर भी सवाल हैं
  • कुछ users ने Python जैसी दूसरी languages में इसी तरह की समस्या का सामना करने के अपने अनुभव साझा किए
  • Go 1.22 का यह बदलाव language syntax की समस्या को सुलझाने का एक तरीका लगता है, लेकिन कुछ users को यह सहज नहीं लगता क्योंकि किसी एक file के behavior को समझने के लिए दूसरी file में घोषित version जानना पड़ता है