Elixir 1.19

 (elixir-lang.org)
1 पॉइंट द्वारा GN⁺ 2025-10-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Elixir 1.19 वर्ज़न type system को मज़बूत करने और compile performance में सुधार के ज़रिए अधिक bugs को तेज़ी से पहचानने में सक्षम बनाता है
  • type inference अब anonymous functions और protocols तक विस्तृत हो गया है, जिससे user type annotations के बिना भी अधिक व्यापक automatic verification संभव हो जाता है
  • बड़े projects में compile speed में अधिकतम 4 गुना तक सुधार मिलता है, जिसमें parallel compilation और code loading optimization शामिल हैं
  • Erlang/OTP 28 support, OpenChain certification की शुरुआत आदि के साथ ecosystem और supply chain transparency भी मज़बूत हुई है
  • इसके अलावा option parsing में सुधार, ExUnit की debug क्षमता में वृद्धि, shell-आधारित documentation accessibility सुधार सहित कई features शामिल हैं

Elixir 1.19 के प्रमुख सुधार

type system में सुधार

सभी components के लिए type inference

  • Type inference एक ऐसी सुविधा है जो compile time पर expressions के types का अपने-आप निर्धारण करती है
  • पहले type inference मुख्य रूप से patterns, guards और return values पर केंद्रित था, लेकिन इस release में सभी components (guards को छोड़कर) के लिए type inference जोड़ा गया है
  • module के भीतर और Elixir standard library function calls को संदर्भ में लेकर types infer किए जाते हैं, इसलिए पहले जो functions dynamic() -> boolean() के रूप में infer होते थे, अब वे integer() -> boolean() की तरह अधिक स्पष्ट रूप से infer किए जा सकते हैं
  • type inference में compile speed, expressiveness, incremental compilation, और error clarity जैसे कई trade-offs शामिल हैं, इसलिए आगे चलकर guard type inference और dependency type information भी जोड़ी जाएगी
  • यदि किसी function के लिए type signature स्पष्ट रूप से दी गई है, तो type inference की जगह explicit type checking लागू होती है, और केवल वही types स्वीकार किए जाते हैं जो user annotation से मेल खाते हों

protocol dispatch और implementation के समय type checking

  • Elixir अब protocol calls और implementations के समय type checking लागू करता है
  • उदाहरण के लिए, यदि String.Chars protocol को implement न करने वाले type को string interpolation में दिया जाता है, तो warning message दिखाया जाता है
  • for comprehension में Enumerable protocol को satisfy न करने वाले type को generator के रूप में देने पर भी warning आती है
  • इस तरह की type checking compile time पर अधिक bugs को रोकने में मदद करती है

anonymous functions की type inference और checking

  • Elixir 1.19 anonymous functions के लिए type inference और type checking को support करता है
  • उदाहरण के तौर पर, यदि %{} type अपेक्षित करने वाले anonymous function को "hello" जैसा गलत type दिया जाए, तो उसे compile time warning के रूप में तुरंत पकड़ा जा सकता है
  • function captures (&String.to_integer/1 आदि) पर भी type inference लागू होती है, जिससे automated type verification का दायरा बढ़ता है

संदर्भ और पार्टनर

  • यह type system CNRS और Remote की partnership में विकसित किया गया है
  • Fresha, *Starfish* *, Dashbit आदि ने इसका समर्थन किया है

बड़े projects में तेज़ compile speed

code loading bottleneck में सुधार

  • पहले module definition के तुरंत बाद loading की जाती थी, लेकिन इस release में इसे lazy loading strategy में बदला गया है
  • इससे code server पर दबाव कम होता है और parallel compilation performance बेहतर होती है, जिसके कारण बड़े projects की compile speed 2 गुना से अधिक बढ़ती है
  • दो मुख्य सावधानियाँ
    • यदि compilation के दौरान अलग process बनाकर उसी project के modules को access किया जाए, तो loading छूट सकती है; इससे बचने के लिए Kernel.ParallelCompiler.pmap/2 या Code.ensure_compiled!/1 जैसे तरीकों का उपयोग करें
    • @on_load callback के भीतर उसी project के modules को call करने पर error आ सकती है; आवश्यकता होने पर @compile {:autoload, true} option का उपयोग करें
  • दोनों ही मामलों में पहले non-deterministic compile errors आ सकते थे, लेकिन इस सुधार के साथ deterministic (reproducible) compile environment सुनिश्चित होता है

dependency parallel compilation

  • environment variable MIX_OS_DEPS_COMPILE_PARTITION_COUNT का उपयोग करके dependency parallel compilation को support किया गया है
  • कई OS processes को एक साथ उपयोग कर dependencies को parallel में compile किया जाता है, इसलिए project के आकार और CPU core count के अनुसार compile performance अधिकतम 4 गुना तक बेहतर हो सकती है
  • प्रयोग के तौर पर कुल cores के लगभग आधे के बराबर value सेट करना resource utilization के लिए प्रभावी माना गया है
  • parallelization के कारण memory usage बढ़ सकती है, इसलिए CI या build server पर लागू करते समय सावधानी ज़रूरी है

Erlang/OTP 28 support

  • Elixir 1.19 आधिकारिक रूप से Erlang/OTP 28.1+ वर्ज़न को support करता है
  • Erlang/OTP 28 में regular expression representation में बदलाव के कारण struct के default value के रूप में regular expressions का उपयोग अब संभव नहीं है
  • struct initialization के समय regular expressions का उपयोग अभी भी संभव है

OpenChain certification की शुरुआत

  • यह release OpenChain specification compliance शुरू करने वाला पहला वर्ज़न है
  • हर release में CycloneDX 1.6/SPDX 2.3 format का SBoM(Source Bill of Materials) शामिल है
  • इससे release components और licenses की supply chain transparency बढ़ती है और अधिक सख्त प्रबंधन में मदद मिलती है
  • यह काम Jonatan Männchen ने किया है और इसे Erlang Ecosystem Foundation का समर्थन मिला है

अन्य सुधार

  • option parsing, ExUnit के debug और performance, shell-आधारित documentation accessibility सहित विभिन्न tools और libraries में सुधार जोड़े गए हैं
  • अधिक विस्तृत release notes के लिए CHANGELOG देखें

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

1 टिप्पणियां

 
GN⁺ 2025-10-17
Hacker News टिप्पणियाँ

  • यह बात रेखांकित की गई कि Elixir में automatic type checking को धीरे-धीरे लाने का तरीका दूसरे programming languages के लिए भी language improvement का एक शानदार उदाहरण है। पहले ऐसे कई language examples रहे हैं जहाँ बड़े बदलावों ने ecosystem को दो हिस्सों में बाँट दिया, जबकि Elixir के मामले में José ने 2018 से ही साफ़ कहा था कि language खुद अब complete है, इसलिए भरोसा बना रहता है। यह भी समझाया गया कि language और core अब टूटने वाले नहीं हैं, इसलिए स्थिरता का एहसास बहुत मजबूत है। संबंधित प्रस्तुति वीडियो की भी सिफारिश की गई, और इस लगातार व शानदार संचालन से प्रभावित होने की बात कही गई

    • बड़े languages में ecosystem split के उदाहरण के तौर पर सिर्फ Python 3 और Perl 6 याद आते हैं। इन दोनों बदलावों का असर इतना बड़ा था कि शायद दूसरे language changes भी उसी वजह से बहुत भारी लगते हैं
    • Elixir में कभी ऐसा नहीं लगता कि version upgrade के पीछे लगातार भागना पड़ रहा है; बल्कि आने वाले बदलावों को देखते हुए उपयोगी नए features की वजह से upgrade करने का मन होता है। जबरन version बदलने जैसा दबाव नहीं लगता, इसलिए वैसी बेचैनी या stress भी नहीं होता
    • 2017 से production environment में Elixir इस्तेमाल कर रहा हूँ, और हर upgrade उम्मीद से कहीं ज्यादा सहज रहा। उल्टा Erlang/OTP upgrade कई बार compatibility issues के कारण ज्यादा जटिल लगे। इसलिए आम तौर पर latest Elixir तो इस्तेमाल करता हूँ, लेकिन OTP version को एक-दो महीने बाद upgrade करता हूँ, जब तक संभावित conflicts का समाधान न हो जाए
    • Elixir अभी भी कुछ मामलों में अधूरा और कम सुविधाजनक लगता है, इसलिए goals तक पहुँचने के लिए स्पष्ट guide और ecosystem की स्थिरता ज़रूरी है। कई packages छोड़े हुए हैं या उनकी documentation कमजोर है, इसलिए Phoenix ecosystem के बदलावों की रफ्तार पकड़ना मुश्किल लगता है। बहुत से users LiveViews या किसी खास component system को नहीं चाहते, और दूसरे tools व technologies के साथ compatibility की entry barrier भी ऊँची है। Python 3 में 2 से 3 का transition अनिवार्य था और automated migration tools की मदद से यह काफ़ी हद तक अच्छी तरह हुआ, हालांकि trial and error भी बहुत था। दूसरी ओर Ruby 3 में external type files और tool fragmentation ने उल्टा भ्रम बढ़ाया, और boilerplate, governance issues, gem hijacking जैसी नकारात्मक चीज़ों ने Ruby से दूरी बढ़ा दी। बात पर ज़ोर दिया गया कि बेहतरीन language भी खराब संचालन से बिगड़ सकती है, इसलिए परिपक्व सहयोग, संवाद और अच्छा change management बेहद महत्वपूर्ण है। language design में बदलाव पर्याप्त पूर्व-प्रयोग, सावधानी, और users को पहले से पर्याप्त जानकारी देकर ही किए जाने चाहिए ताकि अनावश्यक भ्रम कम से कम हो। उम्मीद जताई गई कि आगे Elixir/Phoenix/OTP और आसान, अधिक शक्तिशाली, अधिक productive और बेहतर performance वाला बने ताकि अलग-अलग users उसे निश्चिंत होकर इस्तेमाल कर सकें। Livebook और Exercism Elixir track जैसे resources की भी सिफारिश की गई

  • Elixir लगातार बेहतरीन features और improvements ला रहा है और स्थिर तरीके से आगे बढ़ रहा है। इसकी language structure शानदार है और इसके creators लगातार सही दिशा बनाए रखे हुए हैं, जो वाकई प्रभावशाली है। अफसोस बस यह है कि रोज़मर्रा के काम में Elixir इस्तेमाल करने के मौके कम मिलते हैं

    • Elixir इस्तेमाल करने की इच्छा में मैंने नौकरी तक छोड़ दी और खुद startup शुरू कर दिया

  • Phoenix dependency compile speed से जुड़ा experimental data साझा किया गया। Mac M1 Max पर सिर्फ default Phoenix dependencies वाले एक छोटे app के आधार पर, MIX_OS_DEPS_COMPILE_PARTITION_COUNT environment variable के अलग-अलग values पर ये compile times मापे गए

    PARTITION_COUNT=1:  12.336초 (유저 32.30s, 시스템 7.23s, CPU 320%)
PARTITION_COUNT=5:  6.970초 (유저 0.37s, 시스템 0.49s, CPU 12%)
PARTITION_COUNT=10: 7.236초 (유저 0.38s, 시스템 0.50s, CPU 12%)

    बीच-बीच में rm -rf _build कमांड से cache हटाया गया

    • बाद के runs शायद cache लागू होने की स्थिति में मापे गए थे, और संभव है कि dep folder में सीधे native compile हुआ हो, इसलिए _build में उसका निशान न बचा हो
    • समझ नहीं आ रहा कि इस release feature के benchmark results को downvote क्यों मिल रहे हैं; क्या कोई इस पर अपनी राय दे सकता है

  • पिछले कुछ महीनों में मुझे Gleam बहुत पसंद आने लगा है। Elixir में type system का आना भी अच्छा लगा, लेकिन पहले यही एक बड़ा कारण था जिसकी वजह से Elixir अपनाना मुश्किल लगता था। कभी आगे Elixir को फिर से आज़माना चाहता हूँ, लेकिन यह चिंता है कि कहीं JavaScript के TypeScript की तरह ऊपर से typed दिखे और असल में बहुत सी libs या packages में सिर्फ dynamic/any type ही न रह जाए। जानना चाहता हूँ कि यह चिंता बेवजह है या नहीं। BEAM वाकई शानदार है

    • TypeScript जैसी स्थिति नहीं है। pattern matching की वजह से मौजूदा Elixir codebase में भी कम से कम 50% तक type inference संभव लगती है, और क्योंकि vanilla Elixir खुद type support देगा, maintained code जल्दी typed होता जाएगा। मैं type systems का बड़ा समर्थक नहीं हूँ और ज़्यादातर JS इस्तेमाल करता हूँ, फिर भी Elixir में types का जुड़ना स्वाभाविक लगता है। TypeScript ऊपर की ओर चढ़ता है, जबकि Elixir में यह स्वाभाविक रूप से नीचे की ओर फैलता है
    • Gleam, OTP/BEAM की असली ताकतों का पूरी तरह लाभ नहीं उठा पाता; वह आकर्षण सिर्फ Elixir देता है
    • Elixir में पहले से primitive types, structs, shape-based destructuring जैसी type concepts मौजूद रही हैं, और Dialyzer, TypedStruct जैसे tools से type checking भी संभव है। यह JavaScript जैसा अराजक untyped language नहीं है
    • Gleam अच्छा है, लेकिन JVM पर Kotlin एक typed language है जिसकी syntax Ruby जैसी लगती है, और उसमें compile-to-JS भी इस्तेमाल किया जा सकता है

  • Elixir वेब development environments में सबसे promising लगता है। असल कामकाजी दुनिया में जब भी Elixir इस्तेमाल करने वाली organizations या teams मिली हैं, उनका स्तर सामान्य जगहों से ऊँचा लगा है। लगता है कि लगातार development वाले माहौल में Elixir दिशा और standards देता रहता है

  • बताया गया कि Elixir release ने CycloneDX 1.6+ और SPDX 2.3+ Source SBoM formats का support शुरू किया है। language level पर SBOM management होना सचमुच काबिल-ए-तारीफ़ है। अफसोस कि मौजूदा कंपनी में Elixir इस्तेमाल नहीं होता

  • अगर कोई real-world open source Elixir project में योगदान देना चाहता है, तो पहले Mozilla Hubs का मुख्य component रहा प्रोजेक्ट अब स्वतंत्र project के रूप में अभी भी Elixir में विकसित हो रहा है। Hubs Foundation/reticulum देखें

  • Elixir standard library के आधार पर dynamic types में boolean, integer से boolean जैसे app-specific contexts के अनुसार compile time पर type inference संभव है

  • Elixir में development experience नहीं है, लेकिन मैं इसका प्रशंसक हूँ। पहले Ruby की practicality और खूबसूरती पसंद थी, लेकिन type systems का आकर्षण बढ़ने पर दूसरी languages की ओर चला गया। Elixir और Ruby दोनों ने type systems अपनाए, लेकिन अब ज़्यादातर Kotlin इस्तेमाल करता हूँ, क्योंकि syntax के लिहाज़ से वह "typed Ruby" जैसा लगता है

    • Kotlin लगभग वैसा ही है जैसा हम सच में jruby से चाहते थे

  • मैं Soketi के साथ pusher sdk जोड़कर event broadcast संभाल रहा हूँ। app की संरचना real-time endpoints और REST endpoints के मिश्रण वाली है, और real-time computation load बहुत भारी नहीं है, लेकिन ज़रूरत पड़ी तो इसे अलग से Go में संभालने का सोच रहा हूँ। जल्द ही collaboration features भी जोड़ने वाला हूँ, इसलिए सोच रहा हूँ कि क्या ऐसी स्थिति में Phoenix अपनाना सही होगा