Erlang/OTP 29.0

 (erlang.org)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SSH daemon अब डिफ़ॉल्ट रूप से shell और exec services को निष्क्रिय करता है, इसलिए जब तक इन्हें स्पष्ट रूप से कॉन्फ़िगर न किया जाए, authenticated users मनमाना Erlang code नहीं चला सकते
  • SSH daemon शुरू होने पर SFTP subsystem भी अब डिफ़ॉल्ट रूप से सक्षम नहीं होती, जिससे security defaults और मज़बूत हुए हैं
  • -unsafe attribute जोड़ा गया है, जिससे unsafe functions को चिह्नित किया जा सकता है, और compiler अब उन function calls पर डिफ़ॉल्ट warning देता है जिन्हें Erlang/OTP में हमेशा unsafe माना जाता है
  • xref अब unsafe function calls और बिना documentation वाले functions को खोज सकता है, और ignore_xref attribute filtering भी अब xref के भीतर ही संभाली जाती है
  • SSL default settings में x25519mlkem768 अब सबसे पसंदीदा key exchange group बन गया है, और SSH default key exchange algorithm भी ML-KEM-768 और X25519 को मिलाकर mlkem768x25519-sha256 कर दिया गया है
  • Erlang system के default code path में current working directory . की position पहले से बदलकर सबसे अंत में कर दी गई है, जिससे loading order बदल गया है
  • Windows के लिए 32-bit Erlang/OTP builds अब उपलब्ध नहीं कराए जाएंगे
  • EEP-79 के native records को implement किया गया है, और Erlang/OTP 29 में इन्हें experimental feature माना गया है
  • is_integer/3 guard BIF, EEP 78 आधारित multi-value comprehension, और compr_assign feature के ज़रिए comprehension के भीतर variable binding जोड़ी गई है
  • compiler अब catch, subexpression के बाहर variables export करना, and/or, और {a,B} = {X,Y} जैसे match alias patterns पर डिफ़ॉल्ट warnings जोड़ता है, और हर एक के लिए disable option भी देता है
  • पुराने guard tests को Erlang/OTP 30 में language से हटाया जाएगा, और मौजूदा obsolete guard usage warnings लागू रहेंगी
  • io_ansi के ज़रिए terminal पर ANSI/Virtual Terminal Sequence output किया जा सकता है, और ct_doctest से Erlang module documentation और documentation files के examples test किए जा सकते हैं

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • सुधार काफ़ी अच्छे लग रहे हैं। SSH daemon को डिफ़ॉल्ट रूप से disable करना और SFTP को भी डिफ़ॉल्ट रूप से disable करना सुरक्षा के लिहाज़ से अच्छा बदलाव है
    io_ansi मॉड्यूल भी काफ़ी बढ़िया लग रहा है। अभी Erlang के बारे में complex command-line applications बनाने के लिए बहुत ज़्यादा चर्चा नहीं होती, लेकिन अगर यह standard library में आ गया है तो आगे काफ़ी मददगार हो सकता है। fwrite का nodes के बीच स्वाभाविक रूप से काम करना भी Erlang से अपेक्षित वही फ़ायदा है
    Native Records का जुड़ना भी दिलचस्प है। अभी Elixir में स्थिति के हिसाब से records, tuples और maps मिले-जुले इस्तेमाल होते दिखते हैं, इसलिए यह आगे कैसे इस्तेमाल होगा यह जानने की उत्सुकता है। EEP में जैसा कहा गया है, मौजूदा records पूरी तरह हटेंगे ऐसा नहीं लगता, लेकिन यह काफ़ी बड़ा सुधार दिखता है
    https://www.erlang.org/doc/apps/ssh/ssh.html
    https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
    https://github.com/erlang/eep/pull/81

    • मुझे नहीं लगता कि SSH daemon कभी अपने-आप enable या start हुआ था। दोनों बिंदुओं की wording अलग है, लेकिन अर्थ यह लगता है कि SSH daemon शुरू करते समय सूचीबद्ध components अब डिफ़ॉल्ट रूप से start नहीं होते
      SSH daemon में अब shell और exec services डिफ़ॉल्ट रूप से disable हैं, जिससे यह secure by default सिद्धांत का पालन करता है। अगर इसे साफ़ तौर पर configure न किया जाए, तो authenticated users मनमाना Erlang code execute नहीं कर पाएँगे
      SFTP subsystem भी SSH daemon start होने पर अब डिफ़ॉल्ट रूप से enable नहीं होता

  • जो लोग जानना चाहते हैं कि Erlang/OTP में OTP क्या है, उनके लिए: यह मूल रूप से libraries और principles का एक सेट है, जो telecom क्षेत्र के लिए high-reliability और fault-tolerant applications को standardize करके बनाने में मदद करता है
    मूल विचार के लिए “OTP Design Principles” की शुरुआत थोड़ा पढ़ना उपयोगी रहेगा
    https://www.erlang.org/doc/system/design_principles.html

    • OTP = Open Telecom Platform

  • अगर आपका production app 29 से कम पर है, तो इस version या नवीनतम patch version पर जितना जल्दी हो सके update करना अच्छा हो सकता है। मैंने अभी production में deploy किया, और automated security scan में फरवरी से मई 2026 की तारीख वाले 2 CRITICAL CVE और कई HIGH risk items पकड़े गए

    • क्या उसकी कोई सूची है?

  • सोच रहा हूँ कि क्या अभी भी कोई नए projects में Erlang इस्तेमाल करता है
    मुझे पता है यहाँ Elixir पसंद करने वाले बहुत लोग हैं, लेकिन बात pure Erlang की कर रहा हूँ
    अगर आप अभी भी Erlang इस्तेमाल करते हैं, तो Elixir की तुलना में उसे पसंद करने की वजह क्या है?

    • सिर्फ़ इस साल ही ऐसे उदाहरण हैं। AtomVM-आधारित नया IoT काम, Erlang में लिखा application server, और एक TUI framework जिस पर अभी काम चल रहा है
      Elixir मुझे Erlang के मुकाबले कोई ठोस फ़ायदा नहीं देता। निश्चित रूप से उसके अपने फ़ायदे हो सकते हैं, लेकिन Erlang मेरी सोच से ज़्यादा मेल खाता है। सीखने या मदद लेने को किसी social gathering जैसा बनाना भी अच्छा लगेगा, लेकिन मेरे लिए सही जगह मिल नहीं पाती

  • क्या कोई internal architecture समझा सकता है?

    • यह इस पर निर्भर करता है कि आप किस हिस्से की internal architecture की बात कर रहे हैं। The BEAM Book दिलचस्प लग सकती है
      https://blog.stenmans.org/theBeamBook/

  • records ecosystem में कैसे जगह बनाएँगे, यह जानने की उत्सुकता है

    • मैं कहने ही वाला था, “records तो दशकों से थे, है न?”, लेकिन फिर changelog पढ़ा
      दिलचस्प है। सोच रहा हूँ कि क्या कभी ऐसा समय आएगा जब Elixir maps को native records में compile करेगा

  • क्या किसी को पता है कि WhatsApp अभी भी Erlang पर आधारित है?

    • हाँ
      2010 के शुरुआती वर्षों से वे Erlang इस्तेमाल कर रहे हैं, और उसी समय tech industry को यह पता चला था कि WhatsApp लगभग 30 engineers के साथ 40 करोड़ से ज़्यादा active users को support कर रहा था
      उस समय मैंने वहाँ के एक engineer से संपर्क किया था, और जब मैं अमेरिका में रहता था तब उन्होंने ईमेल पर मेरे कुछ सवालों के बड़े विनम्र जवाब दिए। बाद में हम कॉफ़ी पर भी मिले और आज तक संपर्क में हैं
      इतना कहा जा सकता है कि Erlang आज भी WhatsApp का एक अहम हिस्सा है
    • Code BEAM Europe 2025 में उनकी presentation देखकर लगता है कि ऐसा अभी भी होने की काफ़ी संभावना है: https://www.youtube.com/watch?v=tC435RGwRCI
    • मुझे प्रत्यक्ष रूप से नहीं पता, लेकिन मैं 2019 में वहाँ से निकला था, और WhatsApp के public Erlang repositories अभी भी active हैं। जहाँ तक मुझे पता है, Erlang Meta भर में फैला भी नहीं है, इसलिए अगर WhatsApp Erlang से हट गया होता, तो उसके बाद Erlang पर काम जारी रखने की बहुत वजह नहीं बचती
    • हाँ। मेरा एक पूर्व कर्मचारी अभी वहाँ काम करता है
    • हाँ। वे Erlang इस्तेमाल कर रहे हैं, और Rust भी धीरे-धीरे बढ़ रहा है

  • -unsafe attribute support जोड़ा गया है, यानी Rust में फिर से rewrite करने का एकदम सही समय है /s

  • समझ नहीं आता Erlang आखिर इस्तेमाल कौन करता है। Rails इस्तेमाल करने के बाद मैंने Phoenix भी आज़माया, लेकिन उसमें कुछ हासिल करना बहुत ज़्यादा मुश्किल लगा
    Phoenix के लिए इतना उत्साह क्यों है, यह मेरी समझ से बाहर है
    एक solo developer के लिए Rails शायद सबसे productive webapp system है। LLM भी Ruby on Rails code बहुत अच्छी तरह लिखते हैं। Python training corpus बहुत बड़ा होने के बावजूद, मेरे अनुभव में वे Django से काफ़ी बेहतर लिखते हैं
    experimental apps मैं Rails में लिखता हूँ, और जब वे stable हो जाएँ तो Go में rewrite करता हूँ। जब app का scope साफ़ न हो, तब सीधे Go में लिखने पर tokens काफ़ी ज़्यादा खर्च होते हैं, जबकि Rails में यह बहुत efficient है
    आजकल React या Angular की भी ज़रूरत नहीं रह गई है; Rails में Hotwire और Go में HTMX इस्तेमाल करता हूँ
    Erlang forum भी खुद Rails में बने Discourse का इस्तेमाल करता है

    • मैं 2016 से full-time Elixir apps लिख रहा हूँ। clients इस बात से बहुत खुश रहते हैं कि उन्हें crashes देखने को नहीं मिलते। सच कहूँ तो, पिछले 10 साल में production में deploy किए गए मेरे सभी applications ने 100% uptime दर्ज किया है। इसमें hardware, operating system या network failures शामिल नहीं हैं, जो मेरे नियंत्रण से बाहर हैं
      थोड़ा नज़रिया व्यापक रखना बेहतर होगा
    • Rails, Phoenix से तेज़ है, ऐसा मैं लगभग सिर्फ़ पहले दिन तक ही मानूँगा, अगर पैमाना development speed हो। उसके बाद आप implicit logic, method_missing जैसी चीज़ों से टकराते हैं, और फिर यह समझने में ज़्यादा समय लगता है कि चीज़ें काम कैसे कर रही हैं
      Elixir/Phoenix इस मामले में ज़्यादा explicit है, इसलिए long-term maintenance में, यानी पहले हफ़्ते के बाद, यह काफ़ी आसान हो जाता है। कोई hidden state नहीं, ModuleName.method(params) कहाँ से आया यह खोजते फिरने की ज़रूरत नहीं, और उस method को चलाने के लिए कुछ set up करने की भी ज़रूरत नहीं—बस सही arguments पास कर दीजिए। कमी बस इतनी है कि ready-made package libraries का ecosystem थोड़ा छोटा है
    • ज़रा अंदाज़ा लगाइए Ruby Discord क्या इस्तेमाल करता है?
    • Phoenix मुख्य रूप से OTP, channels, और LiveView की वजह से दिलचस्प है। हालाँकि 2026 में LiveView शायद वह विकल्प नहीं होगा जिसे मैं चुनूँगा, और अगर आपको ऐसी सुविधाओं की ज़रूरत नहीं है तो उसका आकर्षण कम लग सकता है
      Ecto भी बुरा नहीं है
      Claude Code, Elixir code बहुत अच्छा लिखता है
      हैरानी की बात है कि LLM हो या न हो, इंसान उसी tech stack में ज़्यादा productive होता है जिसे वह पहले से जानता है
    • “जब app का scope साफ़ न हो, तब सीधे Go में लिखने पर tokens काफ़ी ज़्यादा खर्च होते हैं, जबकि Rails में यह बहुत efficient है” — इसमें एक ज़बरदस्त विडंबना है। इतना लंबा लिखने के बाद आपने असल में यह बता दिया कि code आप खुद नहीं लिख रहे हैं