Go 1.24 रिलीज़

 (go.dev)
1 पॉइंट द्वारा GN⁺ 2025-02-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Go 1.24, Go 1.23 के बाद का आधिकारिक अपडेट है, और इसमें language features से लेकर runtime, standard library और WebAssembly तक ऐसे व्यापक बदलाव शामिल हैं जिन्हें डेवलपर तुरंत महसूस कर सकते हैं
  • भाषा स्तर पर यह generic type aliases को पूरी तरह सपोर्ट करता है, जिससे type aliases को भी defined types की तरह parameterize किया जा सकता है
  • runtime में Swiss Tables आधारित map, छोटे objects के allocation में सुधार, और internal mutex बदलावों के कारण प्रतिनिधि benchmarks में औसतन CPU overhead 2–3% कम दिखता है
  • go command अब module की tool dependencies को track और run करने का flow जोड़ता है, और go vet test-संबंधित declaration गलतियों को बेहतर तरीके से पकड़ता है
  • standard library और platform support भी बढ़ाया गया है, इसलिए FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport, और WASI reactor/library builds को देखना ज़रूरी है

Go 1.24 में बदलावों का दायरा

  • Go 1.24, Go 1.23 की तुलना में कई सुधारों वाला रिलीज़ है, और पूरी बदलाव सूची Go 1.24 release notes में देखी जा सकती है
  • नया वर्ज़न Go download page से प्राप्त किया जा सकता है

भाषा में बदलाव: generic type aliases

  • Go 1.24 generic type aliases को पूरी तरह सपोर्ट करता है
  • type aliases को भी defined types की तरह parameterize किया जा सकता है, जिससे generic code में अभिव्यक्ति का दायरा बढ़ता है
  • विस्तृत syntax language spec में शामिल है

runtime performance में सुधार

  • runtime सुधारों से प्रतिनिधि benchmark सेट में औसतन CPU overhead 2–3% कम हुआ है
  • performance बदलाव के तीन मुख्य आधार हैं
    • Swiss Tables आधारित नया built-in map implementation
    • छोटे objects के लिए अधिक efficient memory allocation
    • नया runtime internal mutex implementation

Go tools में सुधार

  • go command module की tool dependencies को track करने का mechanism देता है
    • go get -tool से current module में tool directive जोड़ा जाता है
    • go tool [tool name] से tool directive में घोषित tool चलाया जाता है
    • अधिक जानकारी release notes के go command सेक्शन में है
  • go vet subcommand में नया test analyzer जोड़ा गया है
    • यह test packages की tests, fuzzers, benchmarks, और example declarations में आम गलतियों की रिपोर्ट करता है
    • अधिक जानकारी release notes के vet सेक्शन में है

standard library और runtime API additions

  • standard library में FIPS 140-3 compliance में मदद करने वाले नए mechanisms का सेट शामिल है
    • approved algorithms के लिए इन नए mechanisms का उपयोग करने हेतु application source code में बदलाव की ज़रूरत नहीं है
    • अधिक जानकारी release notes के FIPS 140-3 compliance सेक्शन में है
  • FIPS 140 के अलावा, पहले x/crypto module में मौजूद कई packages अब standard library में उपलब्ध हैं
  • benchmark code अब testing.B.Loop method का उपयोग कर सकता है
    • benchmark iterations को for b.Loop() { ... } रूप में चलाया जाता है
    • यह for range b.N जैसे b.N आधारित सामान्य loop structure की जगह ले सकता है
    • यह तरीका अधिक तेज़ है और इसमें गलती की संभावना कम है
  • नया os.Root type किसी खास directory के नीचे सीमित filesystem operations को संभव बनाता है
  • runtime में नया cleanup mechanism runtime.AddCleanup जोड़ा गया है
    • यह runtime.SetFinalizer की तुलना में अधिक flexible, efficient, और कम error-prone है

WebAssembly support में सुधार

  • Go 1.24 एक नया go:wasmexport directive जोड़ता है, जिससे Go programs WebAssembly host के लिए functions export कर सकते हैं
  • Go programs को WASI reactor/library के रूप में build किया जा सकता है
  • अधिक जानकारी release notes के WebAssembly सेक्शन में है

आगे की जानकारी और feedback

  • पूरी विस्तृत जानकारी Go 1.24 release notes में है
  • कुछ विषयों को आगे आने वाले blog posts में और गहराई से कवर किया जाएगा
  • यदि कोई समस्या मिले, तो issue दर्ज की जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2025-02-15
Hacker News की राय

  • तेज़ map implementation खास तौर पर स्वागतयोग्य है, और यह भी अच्छा है कि text/template अब range-over-func को सपोर्ट करता है
    Go 1.23 में function type पर range जोड़ा गया था, लेकिन अब तक Go templates में यह काम नहीं करता था

  • यह इतना सादा और बिना ड्रामे का है कि अच्छा लगता है

  • सोच रहा हूँ os.Root का use case क्या होगा
    मेरी समझ से इसका संबंध https://github.com/golang/go/issues/67002 की तरह security से है, लेकिन क्योंकि यह अंदरूनी तौर on Chroot इस्तेमाल नहीं करता, तो लगता है कि आखिरकार कोई न कोई Root के बाहर निकलने का तरीका ढूँढ सकता है

    • chroot का मतलब तभी है जब application यह तय कर सके कि वह आगे भी सिर्फ एक ही directory के अंदर काम करेगी
      इसके अलावा process के पास superuser privileges होने चाहिए, इसलिए इसे सामान्य user permissions पर चलने वाली applications में इस्तेमाल नहीं किया जा सकता
      os.Root() ज़्यादा safety belt जैसा है जो file system operations पर लगाया जाता है. जैसे application cache से जुड़े कामों को cache directory तक सीमित करना, या file server को सिर्फ सही shared directory के अंदर की files serve करने देना. यह chroot जैसी लोहे की गारंटी नहीं देता, लेकिन साधारण directory traversal attacks को रोक देता है
    • समझ नहीं आता कि chroot क्यों इस्तेमाल करना चाहिए
      अगर Capsicum जैसी sandbox features के साथ हो, तो capability mode में जाने से पहले directory खोली जा सकती है, और बाद में os.Root के साथ उस खुली हुई directory के नीचे file system tree की files खोली जा सकती हैं

  • जानना चाहता हूँ कि tools directive से बताए गए tools install करते समय इस्तेमाल होने वाले tags को specify किया जा सकता है या नहीं
    मैंने नीचे की तरह कोशिश की, लेकिन लगता है यह tags के बिना install हो रहा है
    go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

  • लिखा है कि GODEBUG=fips140=only इस्तेमाल करने पर FIPS 140-3 के अनुरूप न होने वाले cryptographic algorithms error लौटाएँगे या panic करेंगे, लेकिन standard library का जानबूझकर panic करना मुझे खास पसंद नहीं है
    मैंने अभी code नहीं देखा, लेकिन सोच रहा हूँ कि backward compatibility की वजह से क्या यह सिर्फ उन्हीं functions में ऐसा करता है जो अभी error return नहीं करते

    • यह government environments में ज़रूरी feature है
      अगर runtime पर यह verify न किया जाए कि FIPS enabled है, तो compliance टूटने का जोखिम रहता है, और फिर audit और अंतहीन meetings शुरू हो जाती हैं. नए controls और validation procedures बनाने में कई दिन लगाने से बेहतर है कि panic की वजह से 30 मिनट का outage हो जाए
    • तो फिर वह flag set मत कीजिए
      इस तरह का behavior उन स्थितियों में काम आता है जिन्हें सिर्फ runtime पर detect किया जा सकता है. ज़रा-सा basic test coverage भी हो तो यह तुरंत सामने आ जाएगा
    • व्यावहारिक विकल्प सिर्फ error return करना है, लेकिन errors को पकड़कर ignore भी किया जा सकता है
      cryptography वाले context में यह कितना ठीक है, इस पर संदेह है. मुझे नहीं लगता कि warning log level सही होगा. अगर चीज़ महत्वपूर्ण है और उस पर action लिया जा सकता है, तो वह error या fatal log होनी चाहिए; नहीं तो info log काफ़ी है
    • मैंने पढ़ा था कि यह हिस्सा Go 1.25 में साफ़ किया जाएगा
      https://devblogs.microsoft.com/go/go-1-24-fips-update/
    • जैसे sibling comments में कहा गया है, कुछ मामलों में enforcement ज़रूरी होती है
      इसे hidden bugs से बचने के तरीके के रूप में भी देखा जा सकता है. यह कुछ-कुछ "The server chose violence" [1] [2] जैसा है, और यह भी सोचने लायक है कि Postel's law ने interoperability को कितना नुकसान पहुँचाया है. FIPS certification के कई पहलुओं में यह बात अक्सर भुला दी जाती है
      [1] https://cliffle.com/blog/hubris-reply-fault/
      [2] https://news.ycombinator.com/item?id=40178652

  • आखिरकार generic type aliases आ गए, और यह feature काफ़ी पहले से चाहिए था

  • नया tool flag सबसे ज़्यादा रोमांचक लग रहा है. अब बदसूरत tools.go से छुटकारा मिल सकता है

  • बढ़िया. मैं इस release का इंतज़ार GOAUTH की वजह से कर रहा था
    उम्मीद है private git repositories के साथ काम करना कम झंझट वाला होगा, लेकिन go help goauth देखकर बहुत ज़्यादा उम्मीद नहीं बंधती