Ruby 3.3 रिलीज़

 (ruby-lang.org)
1 पॉइंट द्वारा GN⁺ 2023-12-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • YJIT ने Ruby 3.2 की तुलना में परफॉर्मेंस और मेमोरी उपयोग में बड़ा सुधार किया है, और Optcarrot में यह इंटरप्रेटर से 3 गुना से भी अधिक तेज़ है
  • YJIT का Code GC डिफ़ॉल्ट रूप से निष्क्रिय कर दिया गया है, और --yjit-exec-mem-size नए कोड कंपाइल को रोकने वाली हार्ड लिमिट की तरह काम करता है
  • RubyVM::YJIT.enable जोड़ा गया है, जिससे कमांड लाइन आर्ग्युमेंट या environment variable बदले बिना runtime पर YJIT को सक्रिय किया जा सकता है
  • डिफ़ॉल्ट gem के रूप में Prism parser जोड़ा गया है, और Prism.parse(source), Prism.parse_comments(source), Prism.parse_success?(source) API का उपयोग किया जा सकता है
  • ruby --parser=prism या RUBYOPT="--parser=prism" से Prism compiler का प्रयोग किया जा सकता है, लेकिन यह फ़्लैग केवल debugging के लिए है
  • parser generator को Bison से Lrama में बदला गया है, और Lrama के internal parser को maintainability के लिए Racc-जनरेटेड LR parser से बदला गया है
  • pure-Ruby JIT compiler RJIT अब MJIT की जगह लेता है, लेकिन यह केवल Unix की x86-64 architecture को सपोर्ट करता है और प्रयोगात्मक उपयोग तक सीमित है
  • M:N thread scheduler जोड़ा गया है, जिसमें N native threads, M Ruby threads को मैनेज करते हैं, लेकिन यह C extension compatibility को तोड़ सकता है, इसलिए main Ractor में यह डिफ़ॉल्ट रूप से निष्क्रिय है
  • it को बिना arguments के कॉल करना और सामान्य parameters के बिना block में उसका उपयोग अब deprecated है, और Ruby 3.4 में यह पहले block parameter का reference बन जाएगा
  • Regexp::new अब Ruby 3.2 में deprecated की गई 3-argument call के बजाय अधिकतम 2 arguments ही स्वीकार करता है
  • ext/readline को रिटायर कर दिया गया है, और आगे चलकर ext/readline API के साथ compatible pure Ruby implementation reline पर निर्भर किया जाएगा
  • अगर ext/readline की ज़रूरत हो, तो इसे rubygems.org से gem install readline-ext द्वारा इंस्टॉल किया जा सकता है, और अब libreadline या libedit जैसी लाइब्रेरी इंस्टॉल करने की ज़रूरत नहीं है
  • RubyGems और Bundler अब कुछ gems को Gemfile या gemspec में जोड़े बिना require करने पर चेतावनी देते हैं, और ये gems भविष्य के Ruby versions में bundled gem बन जाएंगे
  • bootsnap gem का उपयोग करने पर यह चेतावनी दबा दी जाती है, और इस version की सीमा के कारण application को कम से कम एक बार DISABLE_BOOTSNAP=1 environment variable के साथ चलाने की सिफारिश की जाती है
  • डिफ़ॉल्ट gem के रूप में prism 0.19.0 जोड़ा गया है, और racc 1.7.3 को default gem से बढ़ाकर bundled gem बनाया गया है

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

1 टिप्पणियां

 
GN⁺ 2023-12-26
Hacker News की राय

  • मुझे लगता है Ruby 3.3 के साथ Ruby ने जोरदार वापसी की है। यह भाषा developer happiness पर फोकस करती थी, लेकिन धीमी होने के लिए उसका मजाक उड़ाया जाता था; अब यह धीमी नहीं रही
    YJIT कमाल की तकनीक है, और object shape व कई तरह के garbage collection optimizations के साथ Ruby काफी तेज हो रही है। Shopify जैसे बड़े Ruby users भी 3.3 pre-release में YJIT चालू करके production में चला रहे हैं और double-digit percentage performance improvement रिपोर्ट कर रहे हैं
    निजी तौर पर मैं Ruby और उसके भविष्य को लेकर सच में उत्साहित हूं, और Ruby 3.3 के साथ काम करके इसे customers की production sites पर लागू करके देखना चाहता हूं
    https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...

    • थोड़ी-सी performance improvement शायद Ruby को नए सिरे से चुनने की वजह न बने, लेकिन incremental improvements स्वागतयोग्य हैं। Performance को लेकर जरूरत से ज्यादा चिंता करना लगभग हमेशा premature optimization होता है, और Ruby अब तक मांगे गए कामों के लिए काफी तेज रही है
      मैंने इसे Redis-based DNS record store और PowerDNS के बीच glue code के लिए भी इस्तेमाल किया, और पूरा stack 14 छोटे VPS पर महीने में 500 million queries संभालता था, htop में कोई खास असर दिखे बिना। Performance की वजह से PowerDNS नहीं चुना था; वजह यह थी कि public internet पर expose होने वाली encryption, HTTP, DNS जैसी चीजें खुद implement करना आमतौर पर अच्छा नहीं होता
      आज के web की विडंबना यह है कि “धीमी” Ruby और server rendering से बना webapp, असल में धीमे eventually consistent databases और भारी-भरकम frontend webapps की तुलना में page loading में ज्यादा तेज होता है। Modern web में छोटे-छोटे काम करते समय भी loading spinner बहुत बार दिखता है
    • Ruby भाषा खुद तेज हो सकती है, लेकिन पूरा ecosystem तकलीफदेह हद तक धीमा है। Database queries और दूसरी service calls के बाद हर request पर 1MB JSON लौटाने वाला server Rails में बनाया तो करीब 100 requests per second मिले; वही service Go में फिर से लिखी तो 100,000 requests per second संभाल ली
    • मैं सोच रहा था कि “double-digit performance improvement” का मतलब 10% तेज है या 10 गुना तेज
      लिंक खोला तो यह 10% के आसपास improvement था। इससे Rust, Java, Go, C++ जैसी “fast” languages की तुलना में Ruby के लगभग 50–200 गुना धीमी होने वाली धारणा में ज्यादा फर्क नहीं पड़ेगा
    • एक क्षेत्र जहां Ruby developer experience सुधार सकती है, वह बेहतर debugging experience है। शायद मैं Chrome DevTools का बहुत आदी हो गया हूं, लेकिन पिछली बार जब मैंने बहुत metaprogramming वाले Ruby code को debug किया था, तो क्या हो रहा है यह समझना बेहद कष्टदायक था
    • “double-digit” सुनकर मैंने 50% या 80% की उम्मीद की थी, लेकिन लिंक देखा तो यह 13–15% था

  • Ruby 3.3 पिछले 10 वर्षों में सबसे महत्वपूर्ण और feature-rich Ruby releases में से एक लगती है। मुझे नहीं लगा था कि Python से पहले production-ready JIT आ जाएगा, और इसमें Prism, Lrama, IRB भी हैं
    लेकिन जिन चीजों पर पर्याप्त चर्चा नहीं हो रही, वे हैं Ractor, M:N thread scheduler, Fiber, Async। खासकर Rails के संदर्भ में, क्या कोई इन features को production environment में इस्तेमाल कर रहा है—उनकी राय सुनना चाहूंगा

    • Ruby का Python से पहले production-ready JIT निकालना काफी अनुमानित था। वजह यह है कि Ruby में host interpreter की implementation details पर निर्भर रहने वाली विशाल scientific computing community नहीं थी
    • सोच रहा हूं कि Ruby 3.3 सच में इतनी महत्वपूर्ण release है या नहीं। समझ नहीं आ रहा कि इसमें इतना अर्थपूर्ण क्या है
      फिर भी Ractor को ज्यादा spotlight मिलनी चाहिए। यह बहुत बड़ा feature है
    • मुझे सच में समझ नहीं आता कि Ruby और Python दोनों को कवर करने वाली एक single job queue क्यों नहीं है। मुझे पता है कि किसी समय से लोग HTTP-based microservices के जरिए जानकारी भेजने-लेने लगे, लेकिन आखिरकार दोनों languages द्वारा साझा किए जा सकने वाले storage format वाली एक simple job queue, Ruby/Rails based systems और machine learning stack को जोड़ने का बेहतर तरीका है
      शायद कंपनियों के अंदर RabbitMQ या Redis based हजारों private custom solutions होंगे

  • हर साल Christmas पर घड़ी की तरह Ruby Lang नई release निकालता है

  • Heroku पर उपलब्ध है: https://devcenter.heroku.com/changelog-items/2772

  • अच्छा लग रहा है। नया IRB बेहतर auto-completion और debugging वाला interactive Ruby interpreter है। Ruby 3.3 के ज्यादातर changes developer tools में सुधार की ओर जाते दिखते हैं
    Language API मोटे तौर पर पिछली releases के साथ consistent रहती है। कई version managers के notes के साथ मैंने Ruby 3.3 update guide लिखी है: https://mac.install.guide/ruby/update.html
    जिज्ञासा है कि किस version manager की सिफारिश करनी चाहिए, यह समझ नहीं आ रहा। पहले asdf, frum, chruby recommend किए थे

    • rbenv या asdf में मुझे कोई खास समस्या नहीं दिखती। local और production environment दोनों में इनका इस्तेमाल कर रहा हूं

  • Socket.getaddrinfo जैसे name resolution को अब interrupt किया जा सकता है, और कहा जा रहा है कि जब भी name resolution की जरूरत होती है, एक worker pthread बनाकर उसके अंदर getaddrinfo(3) चलाया जाता है
    सोच रहा हूं कि दूसरी language runtimes भी कुछ ऐसा ही करती हैं या नहीं। Thread बनाना बहुत heavy लगता है, लेकिन असल में शायद यह बड़ी समस्या न हो। इनके अपने benchmarks के हिसाब से भी overhead छोटा है, लेकिन zero नहीं
    10000.times { Addrinfo.getaddrinfo("www.ruby-lang.org";, 80) } patch से पहले 2.3 सेकंड और patch के बाद 3.0 सेकंड था, और 100.times { URI.open("https://www.ruby-lang.org";).read } patch से पहले 3.36 सेकंड और patch के बाद 3.40 सेकंड था

    • सोच रहा हूं कि क्या ऐसा इसलिए है क्योंकि standard library के सभी input/output operations को async/fiber support करना चाहिए
      Python की तरह उसी operation को async “color” में फिर से implement करने के बजाय, मुझे यह impression मिला कि सब कुछ default रूप से asynchronous में ले जाया गया है; पता नहीं यह सही है या नहीं
    • मुझे लगता है कि नया thread बनाने से fiber ज्यादा हल्का नहीं होगा क्या

  • अगर पहले से Python और NodeJS जानते हैं, तो सोच रहे हैं कि Ruby सीखने लायक है या नहीं। Ruby दिलचस्प है, लेकिन कठिन लगती है

    • Ruby मूल रूप से कम लोकप्रिय, लेकिन ज़्यादा सुरुचिपूर्ण Python जैसी है। यह एक मजबूत general-purpose language है, और खास तौर पर shell scripts या data cleaning जैसे कामों के लिए अच्छी है
      अगर आप Node और Python में दक्ष हैं, तो इसे सीखना काफ़ी आसान होगा। कमी यह है कि अगर आप वे भाषाएँ पहले से जानते हैं, तो यह मूल रूप से कुछ नया नहीं देगी। फायदा मुख्यतः सौंदर्यात्मक है: Ruby कोड को सचमुच खूबसूरती से व्यक्त करने के तरीके देती और प्रोत्साहित करती है, और उसे अनुभव करना मज़ेदार है
    • मेरे हिसाब से Ruby, Python या Node की तुलना में shell scripting जैसे कामों और system tasks के लिए interactive/exploratory programming में कहीं बेहतर है। इसे “बेहतर bash” या “बेहतर Perl” की तरह इस्तेमाल करना ही पर्याप्त मूल्य देता है
      मैं मुख्य रूप से TypeScript codebase पर काम करता हूँ, लेकिन log data या semi-structured text संभालते समय, या कई files में regex-आधारित rewrites करते समय, अक्सर Ruby निकालता हूँ। Ruby बहुत मज़ेदार है, और जिन भाषाओं का मैंने नियमित रूप से इस्तेमाल किया है उनमें शायद सबसे मज़ेदार है, इसलिए यह अपने आप में reward है
    • यह इस पर निर्भर करता है कि आप क्या पाना चाहते हैं। सबसे दिलचस्प बात यह है कि Ruby कई मायनों में Python से बहुत मिलती-जुलती है, फिर भी काफी अलग भी है
      सबसे बड़ा उदाहरण यह है कि Ruby को blocks वाकई बहुत पसंद हैं। वे standard library में हर जगह हैं, syntax sugar भी बहुत है, और blocks के इर्द-गिर्द बने DSL तो अनगिनत हैं। मानक functional features भी standard library में बहुत पहले से हैं, इसलिए functional style को सहज और पढ़ने योग्य तरीके से लिखा जा सकता है
      Python में भी तकनीकी रूप से ज़्यादातर चीजें संभव हैं, लेकिन लिखने और पढ़ने में बहुत ज़्यादा awkward लगती हैं। Python में lambda है, पर लगता है कि उसे मामूली उपयोगों से आगे ज़्यादा पसंद नहीं किया जाता, और उसकी जगह functions हर जगह first-class values के रूप में इस्तेमाल होते हैं
    • सीखते समय code सुधारने के hints पाने के लिए Rubocop इस्तेमाल करना अच्छा रहेगा। यह एक बेहतरीन linter और शिक्षक है
    • 10 साल से थोड़ा ज़्यादा पहले, 2011–2013 में, मैंने Ruby, या अधिक सही कहें तो Rails की Ruby, थोड़ी इस्तेमाल की थी। उस समय RoR की लहर अभी भी बाकी थी, जो 2005 में आया था और 2007–2009 में बहुत लोकप्रिय हुआ था
      नई तकनीक पर नज़र रखने वाले लोग node.js और AngularJS आधारित API-oriented development की ओर जा रहे थे, जो RoR से बने कामों की तुलना में काफी तेज़ था। 2013 का RoR अब भी standard तरीके से monolithic था, और frontend/backend separation वाले नए paradigm में अच्छी तरह shift नहीं कर पा रहा था, इसलिए पुराना दिखने लगा था
      Ruby खुद नहीं, बल्कि Ruby से बने framework की बात इतनी लंबी इसलिए की, क्योंकि मुझे लगता है कि आज भी Ruby development का 95% Rails applications ही होगा। Ruby ज्यादातर Ruby on Rails की वजह से मशहूर हुई, और अगर RoR गिरावट पर है, तो Ruby भी शायद Perl की तरह उसी दिशा में जाएगी, जब तक कि वह एक छोटे लेकिन उत्साही community तक सीमित न हो जाए
      भाषा को अलग से देखें, तो Python या TypeScript की जगह Ruby चुनने का कोई कारण याद नहीं आता। भाषा या platform, किसी भी लिहाज़ से Ruby अपने पहले से बेहतर स्थापित competitors से बेहतर कुछ करती हुई नहीं दिखती

  • Prism दिलचस्प है। सोच रहा हूँ कि क्या इसका इस्तेमाल करने वाले Ruby code analysis tools हैं। मैं company code analysis का तरीका खोज रहा था

    • Ruby LSP Prism का इस्तेमाल करता है। Kevin Newton ने Rubocop के साथ इस्तेमाल हो सकने वाले whitequark/parser gem के लिए Prism-based backend implement किया है: https://github.com/kddnewton/parser-prism

  • कहा गया है कि RUBY_MAX_CPU=n environment variable अधिकतम N, यानी अधिकतम native threads की संख्या सेट करता है, और default 8 है
    लगता है default Rust के Tokio या ढेरों M:N runtimes की तरह logical cores की संख्या होना चाहिए

    • यह बाद में जोड़ा जा सकने वाला optimization है और इसमें थोड़ी subtlety है। जहाँ तक याद है Go में भी कई साल तक कुछ ऐसा ही था, और init() या main() में GO_MAX_PROCS सेट करने की याद है
    • maximum CPU count पर hard cap लगाना सही नहीं लगता। उपलब्ध cores की संख्या पर निर्भर करना काफी नहीं होगा क्या?

  • Ruby 4.0 में मौजूदा implicit तरीके से global namespace में gems लाने के बजाय explicit import की अनुमति मिले तो अच्छा होगा

    • Chris Salzberg के Im में आपकी रुचि हो सकती है। यह Ruby 3.2 में भी पहले से इस्तेमाल किया जा सकता है: https://github.com/shioyama/im
      “namespace on read” नाम की अनुमानित/प्रस्तावित feature पर चर्चा भी है: https://bugs.ruby-lang.org/issues/19744
    • implicit हो या explicit, global namespace मुझे ठीक लगता है। सिद्धांत में यह अटपटा है, लेकिन व्यवहार में conventions और social norms की वजह से कम ही समस्या बनता है
      यह बात कि global namespace हर gem के ठीक एक version को ही support करता है, stable ABI और deprecation grace periods को महत्व देने वाली स्वस्थ संस्कृति को भी बढ़ावा देती है। कुछ language ecosystems की तुलना में यह सपने जैसा environment है
    • यह Ruby नहीं, Rails की तरफ की बात नहीं है क्या? मुझे पता है कि ज़्यादातर projects में वह फर्क व्यावहारिक रूप से नहीं होता, लेकिन यह Rails developers का निर्णय है और Ruby developers जो करते हैं उससे असंबंधित भी हो सकता है
      या फिर हो सकता है कि मैं पूरी तरह गलत बात कर रहा हूँ
    • Ruby 4.0 को 2030 से पहले देखना मुश्किल होगा
      https://youtu.be/4MM5b2F9zrM?si=UT3aUbD6p_uBZehS&t=2347