Elixir 1.17 रिलीज़: पैटर्न के लिए set-theoretic types, Duration, OTP 27

 (elixir-lang.org)
1 पॉइंट द्वारा GN⁺ 2024-06-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • क्रमिक set-theoretic types पैटर्न से type infer करके compile time पर warning देते हैं, और मौजूदा software बदले बिना codebase में defects और bugs खोजने की क्षमता जोड़ते हैं
  • नई type warnings फिलहाल atom और map/struct पर केंद्रित हैं, और non-existent key pattern matching·field access, non-module function call, गलत anonymous function call, structs के बीच structural comparison, non-overlapping types comparison, गलत binary pattern, undefined exception rescue आदि का पता लगाती हैं
  • type checker फिलहाल केवल उसी function के भीतर के patterns से type infer करता है, और guard व function boundaries के बीच analysis भविष्य की releases में जोड़ा जाएगा
  • Erlang/OTP 27 support जोड़ा गया है और Erlang/OTP 24 support बंद कर दिया गया है; Windows सहित Erlang/OTP 26 या उससे ऊपर पर migration की सिफारिश की गई है
  • Windows के लिए Erlang terminal graphical interface WERL का support Elixir v1.18 में हटाया जाएगा
  • नया Duration data type और Date.shift/2 जोड़ा गया है, जिससे dates, times और date times को duration के आधार पर shift किया जा सकता है; DateTime में यह timezone changes और Daylight Saving Time को handle करता है
  • Kernel.to_timeout/1 जोड़ा गया है, जो duration और integer को Process, GenServer आदि कई APIs में उपयोग होने वाले timeout value में normalize करता है
  • Erlang/OTP 27 के process label feature को Elixir में Process.set_label/1 के रूप में इस्तेमाल किया जा सकता है, और Logger अब gen_statem reports को format करता है तथा logger events में Erlang/OTP 27 process labels शामिल करता है
  • Keyword.intersect/2,3, नया Mix profiler mix profile.tprof, और %{} के struct से भी match होने वाली समस्या को कम करने के लिए guard Kernel.is_non_struct_map/1 जोड़ा गया है
  • mix profile.tprof के जुड़ने के साथ mix profile.cprof, mix profile.eprof को soft-deprecation के तहत रखा गया है

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

1 टिप्पणियां

 
GN⁺ 2024-06-13
Hacker News की रायें

  • हाल के वर्षों में Elixir ecosystem सच में कई तरह के कामों के लिए सबसे सरल समाधान बनता जा रहा है
    Phoenix और LiveView से web development तेज़ और मज़ेदार है, NX/Axon/Bumblebee से artificial intelligence, Membrane से audio-video streaming और processing, Commanded से CQRS और event sourcing, Nerves से embedded devices बनाना, और development में चल रहे LiveView Native से mobile apps तक संभव हैं
    queues, pipelines और batch processing को भी built-in features या GenStage, Broadway, Oban के ज़रिए उपयोग के हिसाब से संभाला जा सकता है
    फिर भी निजी तौर पर core feature Elixir का REPL, IEx, है। development या production में चल रहे code से सीधे interact करना, उसके अंदर झाँकना और debug कर पाना जिंदगी बदल देने जैसा है
    इसमें types का जुड़ना उस आखिरी puzzle piece जैसा है जो हमारे deploy किए जाने वाले code पर और ज़्यादा भरोसा देता है

    • इसके अलावा ExUnit testing को बेहद आसान बना देता है, Hex package manager बस ठीक से काम करता है, और FLAME लगभग एक line code से processes को दूसरे computer पर scale करने देता है
      Ecto SQL databases को functional तरीके से handle करने देता है; ORM को कैसे देखना चाहिए यह अब भी नहीं जानता, लेकिन composable queries की कुछ चीज़ों से SQL का 90% हटाया जा सका, तो इसे सफलता मानता हूँ
      deployment, uptime, segmentation faults, package time वगैरह से कई महीने जूझने के बाद web server और data layer को Elixir + Phoenix पर ले गया, और अब यह कहीं बेहतर tested है, reason करना आसान है, scalability पर भरोसा किया जा सकता है और deployment भी आसान रहा
      configuration से ज़्यादा convention की वजह से Phoenix के साथ शुरुआत अविश्वसनीय रूप से जल्दी हो गई, FastAPI से भी कहीं तेज़। लगता है यह कुछ महीने पहले ही कर लेना चाहिए था
      अब Nx से models train कर रहा हूँ, Bumblebee/Livebook के साथ प्रयोग कर रहा हूँ, और app में presence और live features लगभग मुफ्त में जोड़ रहा हूँ
    • LiveView Native का थोड़ा प्रचार करूँ तो, इससे सिर्फ mobile apps ही नहीं बल्कि desktop, watch, TV, Apple Vision Pro के लिए भी बनाया जा सकता है
      सभी में LiveView के concepts, performance और development convenience वैसे ही इस्तेमाल होते हैं
    • एक ऐसी language से आने के नाते जिसमें शक्तिशाली और उपयोगी static type system है, यही सबसे ज़्यादा खलने वाली कमी लगती है, इसलिए Gleam को उत्सुकता से देख रहा हूँ
      लगता है Erlang या Elixir जैसी जगहों पर वापस जाना मुश्किल होगा
    • मैं सहमत हूँ कि Elixir का REPL top-class है और इस language का असली killer feature है
      जब भी दूसरी languages में code लिखता हूँ, खासकर जब पैसे लेकर coding करता हूँ, इसकी बहुत याद आती है
      अच्छा REPL होने पर programming में अक्सर आने वाला friction काफी कम हो जाता है। पूरे app को चलाकर problem वाले code fragment को टटोलने के बजाय, ideas को थोड़ा-थोड़ा बनाकर तुरंत test किया जा सकता है
      Elixir standard library भी शानदार है, और REPL में documentation तक पहुँचना बहुत आसान है, जिससे flow बनाए रखने में बड़ी मदद मिलती है। Elixir में coding करते समय छोटे सवालों के लिए browser खोलना कम ही पड़ता है, क्योंकि आमतौर पर REPL छोड़े बिना जवाब मिल जाता है
      इसलिए यह मुझे अपने code में भी अच्छी documentation strings लिखने के लिए प्रेरित करता है
      और भी बेहतर बात यह है कि चल रहे code के साथ REPL चलाया जा सकता है। app चलाना हो तब भी उसे वैसे ही चलाते हुए, development environment में live data manipulate कर सकते हैं और internal state देख सकते हैं। दूसरे stacks में यह या तो संभव नहीं होता या debugger चाहिए होता है
      अब type-related features भी आ जाएँ तो tooling और बेहतर होने की उम्मीद है
      इसमें functional paradigm का मज़ा और ताकत है, mutability और state संभालने के मजबूत तरीके भी हैं, और LISP syntax झेलना भी नहीं पड़ता। निजी तौर पर यह ऐसी language है जो मेरे लिए हर सुर सही बैठाती है, इसलिए मुझे यह बहुत पसंद है
    • क्या दूसरी languages में भी ऐसी चीज़ें बहुत नहीं हैं? Ruby में IRB है
      IEx ऐसा क्या करता है जो IRB में नहीं है?

  • पिछले कुछ वर्षों में Elixir और Erlang teams ने वाकई बहुत अच्छा काम किया है, और libraries व books के authors के काम को भी नज़रअंदाज़ नहीं किया जा सकता
    किसी release का इतना इंतज़ार पहले कभी नहीं हुआ। कुछ समय से Elixir और OTP commits देख रहा था, और Elixir/Erlang में साफ़ तौर पर momentum आता महसूस हो रहा है

  • मैं अपने side project के backend में Elixir इस्तेमाल कर रहा हूँ और frontend Remix है; backend पर काम करना बहुत आरामदायक और productive है
    LiveView की productivity मानता हूँ, लेकिन मेरे मामले में unstable network connection संभालना पड़ता है, इसलिए उम्मीद के मुताबिक LiveView experience अच्छा नहीं रहा
    अच्छा होगा अगर developers के दिमाग में Elixir को LiveView से कुछ हद तक अलग देखा जाए। LiveView या real-time channels के बिना सिर्फ simple API backend के तौर पर भी Elixir सच में मज़ेदार है

    • मुझे Elixir बहुत पसंद है, इसलिए लगभग हर चीज़ में इस्तेमाल करता हूँ, और LiveBook toy software बनाना शुरू करने की default जगह बन गया है
      लेकिन LiveView मुझसे ठीक से नहीं हो पाता। इसे समझना काफ़ी मुश्किल है और इसमें कई hidden traps हैं। उदाहरण के लिए auth checks को router के pipe_through और LiveView के on_mount callback, दोनों जगह याद रखकर संभालना पड़ सकता है। [0] देखें
      Phoenix और LiveView से पहली बार परिचित हो रहे developer के लिए ऊपर का वाक्य अपने-आप में कोई मतलब नहीं रखता—सिर्फ़ यही बात साबित करने के लिए काफ़ी है कि LiveView default तरीका नहीं होना चाहिए
      जहाँ ज़रूरत नहीं है, वहाँ यह बहुत steep learning curve बना देता है। Elixir/Phoenix खुद आसान है
      अगर कोई developer नया-नया Elixir/Phoenix सीख रहा है, तो मेरे हिसाब से पहले MVC style के Phoenix dead views इस्तेमाल करना, फिर OTP basics सीखने के लिए “Elixir in Action” पढ़ना सही क्रम है। यह किताब आसान थी, आँखें खोल देने वाली थी, और इसने मेरे coding करने के लगभग सभी तरीके बदल दिए
      और उसके बाद ही LiveView पर जाना बेहतर है
      [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
    • mix phx.new को —no-live flag के साथ चलाने पर LiveView के बिना Phoenix इस्तेमाल किया जा सकता है। मौजूदा projects से भी इसे manually निकाला जा सकता है
    • अब तक आए replies असली बात miss कर रहे हैं
      समस्या technical knowledge या installation defaults की नहीं, developers की perception की है। बहुत से लोग Elixir और बाकी ecosystem को सोचते ही LiveView से शुरू करते हैं, और बाकी ecosystem को नज़रअंदाज़ करके आगे बढ़ जाते हैं
      Elixir इससे कहीं ज़्यादा बड़ा है, और Phoenix भी LiveView से बड़ा है
      LiveView तो छोड़िए, Phoenix के बिना भी productive और cost-effective Elixir applications पूरी तरह बनाए जा सकते हैं। backend में Elixir चुनना आज की तुलना में ज़्यादा common होना चाहिए, लेकिन जो धारणाएँ और डर लोगों को दूसरा विकल्प चुनने पर मजबूर करते हैं, उन्हें भी मैं समझता हूँ

  • मैं अपना startup Elixir 100% fullstack पर बना रहा हूँ, और अब तक इस्तेमाल की गई technologies में यह सबसे शानदार है
    अपने serious tech दोस्तों को लगातार बताता रहता हूँ कि यह कितना अच्छा है
    अब बस RabbitMQ और उसका client OTP 27 पर चल जाएँ तो सच में अच्छा होगा। upgrade करना चाहता हूँ

    • उत्सुक हूँ कि आप क्या बना रहे हैं, जहाँ आपको लगता है कि दूसरी technologies के मुकाबले Elixir बिल्कुल सही fit है
    • RabbitMQ तो काफ़ी solid है; क्या आपको performance leaks जैसी समस्याएँ आ रही हैं?
      हम कई सालों से SSL certificate client login method इस्तेमाल कर रहे हैं, और stability से बहुत संतुष्ट हैं

  • Elixir और Phoenix के बारे में जितनी तारीफ़ की जाए कम है। अब types भी आ जाएँगे तो और बेहतर होगा
    BEAM और उसकी power के बारे में बहुत सुनेंगे, लेकिन मेरे experience में stack के उस हिस्से के बारे में सोचने की नौबत आने तक आप सच में बहुत लंबा जा सकते हैं। Phoenix उस हिस्से को शानदार तरीके से abstract कर देता है, इसलिए बिना मेहनत के फायदे मिलते हैं
    उदाहरण के लिए Oban है। Postgres के अंदर Elixir code से powerful, flexible और easy-to-use background jobs लगभग मुफ्त में मिल जाते हैं। सच में कमाल है
    एक बार आज़माने की सलाह दूँगा

    • अगर LiveView न होता तो मैं पूरी तरह सहमत होता
      LiveView और उसके आसपास की marketing obsession की वजह से, जिन लोगों को वरना OTP को और लंबे समय तक जाने बिना काम चल सकता था, वे journey के बहुत शुरुआती चरण में—शायद अपने पहले controller route से ही—OTP से टकरा जाते हैं
      robust LiveView flows लिखना और उन्हें अच्छी तरह test करना, कई non-linear flows और अलग-अलग call/cast entry points वाले stateful GenServer लिखने जितना intellectually complex है
      LiveView अलग terminology इस्तेमाल करता है और async assigns जैसी छोटी convenience layers हैं, लेकिन mechanically यह सचमुच GenServer ही है। इसे effectively इस्तेमाल करने के लिए यह बात अच्छी तरह समझना ज़रूरी है, ऐसा मुझे लगता है
      Oban मुझे सच में बहुत पसंद है, और दूसरे ecosystems में इसकी बहुत कमी महसूस होती है

  • वैसे, क्या किसी ने elixir-desktop [1] इस्तेमाल किया है? यह wxWidgets + LiveView bundle है, इसलिए Electron apps से काफ़ी मिलता-जुलता है
    [2] में Wojtek Mach बताते हैं कि Elixir team ने Livebook Desktop कैसे बनाया। इसमें project कैसे शुरू हुआ, macOS के लिए app बनाते समय मिले subtle bugs, Windows पर wxWidgets की limitations, और कई implementation details शामिल हैं
    अच्छा होगा अगर Elixir team Livebook के आधार पर elixir-desktop जैसा कुछ officially release करे। यानी Livebook repository को fork करके LiveView-based desktop applications generate करने के लिए official template project दे
    अभी Livebook Windows और Mac के लिए executable files के रूप में distribute होता है। Electron की तरह developers को standalone executable distribute करने देने के लिए वही approach अपनाएँ तो कैसा रहेगा?
    LiveView Native [3] के बारे में भी जानता हूँ, लेकिन मुझे लगता है दिशा अलग है
    [1] https://github.com/elixir-desktop/desktop-example-app
    [2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
    [3] https://native.live/

  • Elixir के popular होने में बाधा बन रहा types नहीं हैं वाला बहाना जिस दिन खत्म होगा, उसका इंतज़ार है

  • 10 साल से यहां शानदार Elixir कहानियां पढ़ता आ रहा हूं, और भाषा भी पसंद है
    लेकिन कुछ साल पहले Elixir jobs ढूंढना छोड़ दिया था, क्योंकि pay लगातार mainstream languages से कम दिखती थी
    यह शायद वह language हो सकती है जिसे मैं सबसे ज्यादा इस्तेमाल करना चाहूं, लेकिन मेरे लिए pay और अच्छा product tech stack से ज्यादा महत्वपूर्ण हैं, इसलिए शायद असल में इसे कर न पाऊं। फिर भी दूर से देखते रहना अब भी मजेदार है

    • Elixir developer के तौर पर यह सुनना थोड़ा हैरान करता है कि pay mainstream languages से कम है
      क्या आप US में ढूंढ रहे हैं, या किसी और region में?
    • pay आमतौर पर mainstream stacks से लगातार ज्यादा ही रहता है। आंशिक वजह यह है कि ज्यादातर Elixir hiring senior engineers की तलाश में होती है

  • इस release का अच्छा feature structs के साथ काम करने वाला get_in/1 जोड़ना है। उदाहरण के लिए get_in(struct.foo.bar) की तरह लिख सकते हैं
    अगर foo nil लौटाता है, तो bar access करने पर exception नहीं आएगा

    • पुराने Elixir versions में भी यह संभव था, लेकिन syntax बहुत noisy था
      साधारण map नहीं होने वाली hierarchy के लिए इस तरह Access.key चाहिए होता था
      get_in(struct, [Access.key(:foo), :bar])

  • यही वह आखिरी टुकड़ा था जो मैं चाहता था। आगे के steps का भी इंतजार है
    बाकी, मेरे हिसाब से यह language functionally 100% complete हो चुकी है

    • पिछली बार जब मैंने Elixir देखा था, तो ऐसा लगा था कि consensus यह है कि “आखिरकार Erlang भी करना ही पड़ेगा”
      क्या अब भी ऐसा है, या अब Erlang तक नीचे जाने की जरूरत नहीं रहती?