Ruby 3.3 Dirilis

• YJIT meningkatkan performa dan penggunaan memori secara signifikan dibanding Ruby 3.2, dan menjadi lebih dari 3 kali lebih cepat daripada interpreter pada Optcarrot
• Code GC pada YJIT dinonaktifkan secara default, dan --yjit-exec-mem-size berfungsi sebagai hard limit yang menghentikan kompilasi kode baru
• Dengan penambahan RubyVM::YJIT.enable, YJIT dapat diaktifkan saat runtime tanpa mengubah argumen command-line atau variabel lingkungan
• Parser Prism ditambahkan sebagai gem default, dan API Prism.parse(source), Prism.parse_comments(source), Prism.parse_success?(source) dapat digunakan
• Compiler Prism dapat dicoba dengan ruby --parser=prism atau RUBYOPT="--parser=prism", tetapi flag tersebut hanya untuk debugging
• Generator parser diganti dari Bison ke Lrama, dan parser internal Lrama diganti dengan parser LR yang dihasilkan Racc demi kemudahan pemeliharaan
• Compiler JIT pure-Ruby RJIT menggantikan MJIT, tetapi hanya mendukung arsitektur x86-64 di Unix dan terbatas untuk tujuan eksperimental
• M:N thread scheduler diperkenalkan, sehingga M thread Ruby dikelola oleh N thread native, tetapi dinonaktifkan secara default pada main Ractor karena dapat merusak kompatibilitas ekstensi C
• Cara it dipanggil tanpa argumen dan digunakan dalam blok yang tidak memiliki parameter biasa akan dihentikan dukungannya (deprecation), dan pada Ruby 3.4 akan menjadi referensi ke parameter blok pertama
• Regexp::new hanya mengizinkan maksimal 2 argumen, menggantikan pemanggilan 3 argumen yang telah dihentikan dukungannya pada Ruby 3.2
• ext/readline dipensiunkan, dan ke depannya akan bergantung pada reline, implementasi pure Ruby yang kompatibel dengan API ext/readline
• Jika ext/readline diperlukan, ia dapat diinstal dari rubygems.org dengan gem install readline-ext, dan instalasi library seperti libreadline atau libedit tidak lagi diperlukan
• RubyGems dan Bundler akan memberi peringatan jika beberapa gem di-require tanpa menambahkannya ke Gemfile atau gemspec, dan gem-gem ini akan menjadi bundled gem pada versi Ruby mendatang
• Saat menggunakan gem bootsnap, peringatan tersebut ditekan; karena keterbatasan versi ini, disarankan menjalankan aplikasi setidaknya sekali dengan variabel lingkungan DISABLE_BOOTSNAP=1
• prism 0.19.0 ditambahkan sebagai gem default, dan racc 1.7.3 dipromosikan dari default gem menjadi bundled gem

[GN⁺]

Komentar Hacker News

• Menurut saya, dengan Ruby 3.3, Ruby benar-benar bangkit kembali. Bahasa yang berfokus pada kebahagiaan developer tetapi sering diejek karena lambat, kini tidak lagi lambat
  YJIT adalah teknologi yang luar biasa, dan bersama object shape serta berbagai optimisasi garbage collection, Ruby menjadi cukup cepat. Pengguna Ruby berskala besar seperti Shopify juga melaporkan peningkatan performa dua digit dalam persen saat menjalankan pra-rilis 3.3 dengan YJIT aktif di produksi
  Secara pribadi saya sangat antusias dengan Ruby dan masa depannya, dan ingin bekerja dengan Ruby 3.3 lalu menerapkannya ke situs produksi pelanggan
  https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...

  • Sedikit peningkatan performa mungkin tidak akan membuat orang memilih Ruby dari nol, tetapi perbaikan bertahap tetap menyenangkan untuk dilihat. Terlalu mengkhawatirkan performa hampir selalu merupakan optimisasi prematur, dan Ruby selama ini sudah cukup cepat untuk pekerjaan yang diminta darinya
    Saya bahkan pernah memakainya untuk kode perekat antara penyimpanan record DNS berbasis Redis dan PowerDNS, dan seluruh stack memproses 500 juta query per bulan di 14 VPS kecil tanpa terlihat di htop. Saya memakai PowerDNS bukan karena performa, melainkan karena biasanya bukan ide bagus mengimplementasikan sendiri hal-hal seperti kriptografi, HTTP, atau DNS yang terekspos ke internet publik
    Ironi web masa kini adalah web app yang dibuat dengan Ruby yang “lambat” dan server-side rendering justru memuat halaman lebih cepat daripada database eventually consistent yang memang lambat dan web app frontend yang membengkak. Di web modern, terlalu sering melihat loading spinner bahkan untuk hal-hal sepele
  • Bahasa Ruby itu sendiri mungkin cepat, tetapi ekosistem secara keseluruhan terasa menyakitkan lambatnya. Saat membuat server di Rails yang untuk setiap request melewati query database dan pemanggilan layanan lain lalu mengembalikan JSON 1MB, hasilnya sekitar 100 request per detik, dan ketika layanan yang sama ditulis ulang dalam Go, ia menangani 100 ribu request per detik
  • Saya sempat bertanya-tanya apakah “peningkatan performa dua digit” berarti 10% lebih cepat atau 10 kali lebih cepat
    Setelah membuka tautannya, ternyata itu peningkatan belasan persen. Rasanya ini tidak banyak mengubah anggapan bahwa Ruby kira-kira 50~200 kali lebih lambat daripada bahasa yang dianggap “cepat” seperti Rust, Java, Go, atau C++
  • Satu area di mana Ruby bisa meningkatkan pengalaman developer adalah pengalaman debugging yang lebih baik. Mungkin karena saya sudah terlalu terbiasa dengan Chrome DevTools, tapi terakhir kali saya men-debug kode Ruby yang penuh metaprogramming, sangat menyiksa untuk memahami apa yang sebenarnya sedang terjadi
  • Ketika mendengar istilah “dua digit”, saya mengharapkan 50% atau 80%, tetapi setelah membuka tautannya ternyata 13~15%

• Ruby 3.3 tampaknya menjadi salah satu rilis Ruby paling penting dan paling kaya fitur dalam 10 tahun terakhir. Saya tidak menyangka ia akan menghadirkan JIT yang siap produksi lebih dulu daripada Python, dan ada juga Prism, Lrama, serta IRB
  Namun yang belum cukup dibahas adalah Ractor, scheduler thread M:N, Fiber, dan Async. Khususnya dalam konteks Rails, saya ingin mendengar apakah ada orang yang memakai fitur-fitur ini di lingkungan produksi

  • Bahwa Ruby lebih dulu menghadirkan JIT siap produksi daripada Python sebenarnya cukup bisa diprediksi. Ruby tidak memiliki komunitas komputasi ilmiah yang sangat besar dan bergantung pada detail implementasi host interpreter seperti Python
  • Saya penasaran apakah Ruby 3.3 memang rilis sepenting itu. Saya tidak paham apa yang membuatnya begitu berarti
    Meski begitu, Ractor memang layak mendapat lebih banyak sorotan. Itu fitur yang sangat besar
  • Saya benar-benar tidak paham kenapa tidak ada satu job queue tunggal yang mencakup Ruby dan Python sekaligus. Saya tahu pada titik tertentu orang mulai saling bertukar informasi lewat microservice berbasis HTTP, tetapi pada akhirnya job queue sederhana dengan format penyimpanan bersama untuk kedua bahasa akan menjadi cara yang lebih baik untuk menghubungkan sistem berbasis Ruby/Rails dengan stack machine learning
    Mungkin di dalam perusahaan ada ribuan solusi kustom privat berbasis RabbitMQ atau Redis

• Setiap Natal, Ruby Lang merilis versi baru setepat jam

• Tersedia di Heroku: https://devcenter.heroku.com/changelog-items/2772

• Kelihatannya bagus. IRB baru adalah interpreter Ruby interaktif dengan autocomplete dan debugging yang lebih baik. Sebagian besar perubahan di Ruby 3.3 tampaknya akan bermuara pada perbaikan alat developer
  API bahasanya sebagian besar tetap konsisten dengan rilis sebelumnya. Saya menulis panduan pembaruan Ruby 3.3 yang memuat catatan untuk berbagai version manager: https://mac.install.guide/ruby/update.html
  Saya penasaran version manager mana yang layak direkomendasikan. Sebelumnya saya merekomendasikan asdf, frum, dan chruby

  • Saya tidak merasa ada masalah besar dengan rbenv atau asdf. Saya memakai keduanya baik di lingkungan lokal maupun produksi

• Name resolution seperti Socket.getaddrinfo sekarang bisa diinterupsi, dan setiap kali name resolution diperlukan, Ruby akan membuat worker pthread lalu menjalankan getaddrinfo(3) di dalamnya
  Saya penasaran apakah runtime bahasa lain juga melakukan hal serupa. Membuat thread tampak terlalu berat, tetapi mungkin dalam praktiknya bukan masalah besar. Bahkan menurut benchmark internal mereka sendiri, overhead-nya kecil tetapi bukan nol
  10000.times { Addrinfo.getaddrinfo("www.ruby-lang.org";, 80) } memakan 2.3 detik sebelum patch dan 3.0 detik sesudah patch, sedangkan 100.times { URI.open("https://www.ruby-lang.org";).read } memakan 3.36 detik sebelum patch dan 3.40 detik sesudah patch

  • Saya penasaran apakah ini karena semua operasi I/O di standard library harus mendukung async/fiber
    Kesannya bukan seperti Python yang mengimplementasikan ulang operasi yang sama dalam “warna” async, melainkan semuanya pada dasarnya dipindahkan ke mode asynchronous. Saya tidak yakin apakah pemahaman itu benar
  • Rasanya fiber akan lebih ringan daripada membuat thread baru

• Bertanya-tanya apakah Ruby layak dipelajari jika sudah mengenal Python dan NodeJS. Ruby terasa menarik, tetapi juga sulit

  • Ruby pada dasarnya mirip Python yang kurang populer tetapi lebih elegan. Ini bahasa serbaguna yang solid, dan sangat bagus khususnya untuk tugas seperti skrip shell atau merapikan data
    Jika sudah mahir dengan Node dan Python, mempelajarinya akan cukup mudah. Kekurangannya adalah, jika sudah tahu bahasa-bahasa itu, Ruby pada dasarnya tidak memberi hal yang benar-benar baru. Kelebihannya terutama bersifat estetis: Ruby menyediakan dan mendorong cara mengekspresikan kode yang benar-benar indah, dan menyenangkan untuk mengalaminya
  • Menurut saya Ruby jauh lebih baik daripada Python atau Node untuk tugas bergaya skrip shell dan pemrograman interaktif-eksploratif untuk pekerjaan sistem. Cukup bernilai jika dipakai sebagai “bash yang lebih baik” atau “Perl yang lebih baik”
    Saya terutama bekerja di codebase TypeScript, tetapi sering memakai Ruby saat menangani data log atau teks semi-terstruktur, atau ketika melakukan penulisan ulang berbasis regex di banyak file. Ruby sangat menyenangkan, dan mungkin bahasa paling menyenangkan di antara yang saya pakai secara rutin, jadi itu sendiri sudah jadi ganjaran
  • Tergantung apa yang ingin didapat. Bagian yang paling menarik adalah bahwa Ruby dalam banyak hal sangat mirip dengan Python, tetapi pada saat yang sama juga cukup berbeda
    Contoh terbesarnya adalah Ruby sangat menyukai block. Itu ada di seluruh standard library, ada banyak sugar sintaks, dan tak terhitung banyaknya DSL yang berpusat pada block. Fitur-fitur fungsional yang standar juga sudah lama ada di standard library, sehingga gaya fungsional bisa dipakai dengan mulus dan tetap enak dibaca
    Secara teknis sebagian besar itu juga bisa dilakukan di Python, tetapi terasa jauh lebih canggung untuk ditulis dan dibaca. Python memang punya lambda, tetapi kesannya tidak terlalu disukai untuk penggunaan lebih dari hal-hal sepele, dan sebagai gantinya fungsi dipakai sebagai nilai kelas satu di mana-mana
  • Jika ingin mendapatkan petunjuk untuk memperbaiki kode sambil belajar, Rubocop bagus untuk dipakai. Itu linter sekaligus guru yang hebat
  • Saya sempat sedikit memakai Ruby, lebih tepatnya Ruby untuk Rails, pada 2011~2013, sedikit lebih dari 10 tahun lalu. Saat itu masih tersisa gaung RoR yang muncul pada 2005 dan sangat populer pada 2007~2009
    Orang-orang yang peka terhadap teknologi terbaru sedang beralih ke pengembangan berorientasi API berbasis node.js dan AngularJS yang jauh lebih cepat daripada yang dibuat dengan RoR. Pada 2013, pendekatan standar RoR masih monolitik, dan terlihat menua karena tidak berhasil beralih dengan baik ke paradigma baru pemisahan frontend/backend
    Alasan saya panjang lebar membahas framework yang dibuat dengan Ruby, bukan Ruby itu sendiri, adalah karena bahkan sekarang pun rasanya 95% pengembangan Ruby adalah aplikasi Rails. Ruby menjadi terkenal sebagian besar berkat Ruby on Rails, dan jika RoR sedang menurun, maka Ruby tampaknya akan mengikuti arus yang sama sampai menyusut menjadi komunitas kecil yang fanatik seperti Perl
    Jika hanya melihat bahasanya sendiri, saya tidak terpikir alasan untuk memilih Ruby ketimbang Python atau TypeScript. Baik dari sisi bahasa maupun platform, Ruby tampaknya tidak punya sesuatu yang lebih baik daripada para pesaing yang sudah jauh lebih mapan

• Prism terlihat menarik. Penasaran apakah ada alat analisis kode Ruby yang menggunakannya. Saya sedang mencari cara menganalisis kode di perusahaan

  • Ruby LSP memakai Prism. Kevin Newton telah mengimplementasikan backend berbasis Prism untuk gem whitequark/parser yang bisa dipakai bersama Rubocop: https://github.com/kddnewton/parser-prism

• Katanya variabel lingkungan RUBY_MAX_CPU=n mengatur maksimum N, yaitu jumlah maksimum native thread, dan nilai bawaan adalah 8
  Rasanya nilai bawaannya seharusnya jumlah core logis seperti Tokio di Rust atau banyak runtime M:N lainnya

  • Itu optimasi yang bisa ditambahkan nanti, dan ada sedikit nuansa di situ. Kalau tidak salah, Go juga mirip begitu selama beberapa tahun, dan saya ingat mengatur GO_MAX_PROCS di init() atau main()
  • Rasanya tidak tepat memberi hard cap pada jumlah CPU maksimum. Bukankah cukup bergantung pada jumlah core yang tersedia?

• Saya berharap Ruby 4.0 mengizinkan import eksplisit, alih-alih cara sekarang yang implisit dan memasukkan gem ke namespace global

  • Mungkin Anda tertarik pada Im karya Chris Salzberg. Itu sudah bisa dipakai bahkan di Ruby 3.2: https://github.com/shioyama/im
    Ada juga diskusi tentang fitur “namespace on read” yang masih tahap perkiraan: https://bugs.ruby-lang.org/issues/19744
  • Menurut saya namespace global tetap baik, baik implisit maupun eksplisit. Secara teori memang terasa canggung, tetapi dalam praktiknya jarang jadi masalah berkat konvensi dan norma sosial
    Fakta bahwa namespace global hanya mendukung tepat satu versi dari tiap gem juga mendorong budaya sehat yang menekankan ABI yang stabil dan masa tenggang deprecation. Dibandingkan dengan beberapa ekosistem bahasa lain, itu seperti lingkungan impian
  • Rasanya ini soal Rails, bukan Ruby. Saya tahu di sebagian besar proyek perbedaannya pada praktiknya nyaris tidak ada, tetapi itu bisa jadi keputusan tim Rails dan tidak ada hubungannya dengan apa yang dikerjakan tim Ruby
    Atau mungkin saya sepenuhnya salah bicara
  • Ruby 4.0 mungkin sulit terlihat sebelum tahun 2030
    https://youtu.be/4MM5b2F9zrM?si=UT3aUbD6p_uBZehS&t=2347