Ruby 3.3 yayımlandı

• YJIT, Ruby 3.2’ye kıyasla performansı ve bellek kullanımını önemli ölçüde iyileştirdi; Optcarrot’ta yorumlayıcıdan 3 kattan fazla hızlı hale geldi
• YJIT’in Code GC’si varsayılan olarak devre dışı bırakıldı; --yjit-exec-mem-size, yeni kod derlemeyi durduran katı bir sınır olarak çalışıyor
• RubyVM::YJIT.enable eklendi; komut satırı argümanlarını veya ortam değişkenlerini değiştirmeden çalışma zamanında YJIT’i etkinleştirmek mümkün
• Varsayılan gem olarak Prism ayrıştırıcısı eklendi; Prism.parse(source), Prism.parse_comments(source), Prism.parse_success?(source) API’leri kullanılabiliyor
• Prism derleyicisi ruby --parser=prism veya RUBYOPT="--parser=prism" ile denenebiliyor; ancak bu bayrak yalnızca hata ayıklama amaçlı
• Ayrıştırıcı üreteci Bison’dan Lrama’ya değiştirildi; Lrama’nın dahili ayrıştırıcısı da bakım kolaylığı için Racc tarafından üretilen LR ayrıştırıcısıyla değiştirildi
• Pure-Ruby JIT derleyicisi RJIT, MJIT’in yerini alıyor; ancak yalnızca Unix’te x86-64 mimarisini destekliyor ve deneysel amaçlarla sınırlı
• M:N thread scheduler getirildi; M adet Ruby iş parçacığını N adet yerel iş parçacığı yönetiyor, ancak C eklentileriyle uyumluluğu bozabileceği için main Ractor’da varsayılan olarak devre dışı
• it’in argümansız çağrılıp normal parametresi olmayan bloklarda kullanılması destekten kaldırılıyor (deprecation); Ruby 3.4’te ilk blok parametresine referans haline gelmesi planlanıyor
• Regexp::new, Ruby 3.2’de destekten kaldırılan 3 argümanlı çağrı yerine en fazla 2 argümana izin veriyor
• ext/readline emekliye ayrıldı; gelecekte ext/readline API’siyle uyumlu pure Ruby uygulaması olan reline’a bağlı olacak
• ext/readline gerektiğinde rubygems.org’dan gem install readline-ext ile kurulabilir; libreadline veya libedit gibi kütüphanelerin kurulması artık gerekmiyor
• RubyGems ve Bundler, bazı gem’ler Gemfile veya gemspec’e eklenmeden require edilirse uyarı veriyor; bu gem’ler gelecekteki Ruby sürümlerinde bundled gem olacak
• bootsnap gem kullanılırken bu uyarı bastırılıyor; bu sürümdeki sınırlama nedeniyle uygulamanın en az bir kez DISABLE_BOOTSNAP=1 ortam değişkeniyle çalıştırılması öneriliyor
• Varsayılan gem olarak prism 0.19.0 eklendi; racc 1.7.3 ise default gem’den bundled gem’e yükseltildi

[GN⁺]

Hacker News yorumları

• Ruby 3.3 ile Ruby’nin büyük bir dönüş yaptığını düşünüyorum. Geliştirici mutluluğuna odaklanan ama yavaş diye alaya alınan dil artık yavaş değil
  YJIT şaşırtıcı bir teknoloji; nesne shape’leri ve çeşitli çöp toplama optimizasyonlarıyla birlikte Ruby epey hızlanıyor. Shopify gibi büyük Ruby kullanıcıları da 3.3 ön sürümünde YJIT’yi açıp üretimde çalıştırarak çift haneli yüzde performans iyileşmeleri bildirdi
  Kişisel olarak Ruby ve geleceği konusunda gerçekten heyecanlıyım; Ruby 3.3 ile çalışıp bunu müşterilerin üretimdeki sitelerine uygulamayı denemek istiyorum
  https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...

  • Biraz performans artışı Ruby’yi yeniden tercih ettirir mi bilmiyorum, ama kademeli iyileşme görmek sevindirici. Performans konusunda aşırı endişelenmek neredeyse her zaman erken optimizasyondur; Ruby de şimdiye kadar ondan istediğim işler için yeterince hızlıydı
    Redis tabanlı DNS kaydı deposu ile PowerDNS arasındaki yapıştırıcı kodda da kullandım; tüm yığın, 14 küçük VPS üzerinde ayda 500 milyon sorguyu işlerken htop’ta kendini belli bile etmiyordu. PowerDNS’i performans yüzünden kullanmadım; herkese açık internete maruz kalan şifreleme, HTTP, DNS gibi şeyleri doğrudan uygulamak genelde iyi bir fikir olmadığı için kullandım
    Günümüz web’inin ironisi şu: “yavaş” Ruby ve sunucu tarafı render ile yapılmış bir web uygulaması, gerçekten yavaş olan nihai tutarlılıklı veritabanlarından ve şişkin frontend web uygulamalarından sayfaları daha hızlı yüklüyor. Modern web’de önemsiz bir iş yaparken bile yükleme spinner’larını çok sık görüyorum
  • Ruby dilinin kendisi hızlı olabilir, ama tüm ekosistem acı verecek kadar yavaş. Veritabanı sorguları ve başka servis çağrılarından geçip her istek için 1 MB JSON döndüren bir sunucuyu Rails ile yaptığımızda saniyede yaklaşık 100 istek alıyorduk; aynı servisi Go ile yeniden yazınca saniyede 100 bin istek işledi
  • “Çift haneli performans iyileşmesi”nin %10 daha hızlı mı, yoksa 10 kat daha hızlı mı demek olduğunu merak ettim
    Bağlantıya tıklayınca bunun %10’lar seviyesinde bir iyileşme olduğunu gördüm. Ruby’nin Rust, Java, Go, C++ gibi “hızlı” dillere göre kabaca 50–200 kat daha yavaş olduğu algısını pek değiştirecek gibi görünmüyor
  • Ruby’nin geliştirici deneyimini iyileştirebileceği alanlardan biri daha iyi bir hata ayıklama deneyimi. Chrome DevTools’a fazla alıştığımdan mı bilmiyorum; en son metaprogramlaması yoğun Ruby kodu debug ederken neler olduğunu anlamak acı vericiydi
  • “Çift haneli” sözünü duyunca %50 ya da %80 bekledim; bağlantıya bakınca %13–15 olduğunu gördüm

• Ruby 3.3, son 10 yılın en önemli ve en zengin özellikli Ruby sürümlerinden biri gibi görünüyor. Python’dan önce üretime hazır bir JIT çıkaracaklarını beklemiyordum; ayrıca Prism, Lrama ve IRB de var
  Ama yeterince ele alınmayan şeyler Ractor, M:N thread zamanlayıcısı, Fiber ve Async. Özellikle Rails bağlamında bu özellikleri üretim ortamında kullanan biri var mı, düşünceleri duymak isterim

  • Ruby’nin Python’dan önce üretime hazır bir JIT çıkarması aslında oldukça öngörülebilirdi. Çünkü Ruby’de, host yorumlayıcının uygulama ayrıntılarının her birine bağımlı devasa bir bilimsel hesaplama topluluğu yoktu
  • Ruby 3.3’ün gerçekten bu kadar önemli bir sürüm olup olmadığını merak ediyorum. Neyi bu kadar anlamlı kılıyor bilmiyorum
    Yine de Ractor daha çok öne çıkarılmayı hak ediyor. Muazzam büyük bir özellik
  • Ruby ve Python’u birlikte kapsayan tek bir iş kuyruğunun neden olmadığını gerçekten anlamıyorum. Bir noktadan sonra insanların HTTP tabanlı mikroservislerle bilgi alışverişi yapmaya başladığını biliyorum; ama sonuçta iki dilin paylaştığı bir depolama formatına sahip basit bir iş kuyruğu, Ruby/Rails tabanlı sistemlerle makine öğrenimi yığınını bağlamak için daha iyi bir yol
    Muhtemelen şirketlerin içinde RabbitMQ ya da Redis tabanlı binlerce özel, şirket içi çözüm vardır

• Her yıl Noel’de saat gibi Ruby Lang yeni bir sürüm çıkarıyor

• Heroku’da kullanılabilir: https://devcenter.heroku.com/changelog-items/2772

• İyi görünüyor. Yeni IRB, otomatik tamamlama ve hata ayıklaması iyileştirilmiş etkileşimli Ruby yorumlayıcısı. Ruby 3.3’teki değişikliklerin çoğu geliştirici araçlarında iyileşmeye dönüşecek gibi
  Dil API’si genel olarak önceki sürümlerle tutarlı kalıyor. Çeşitli sürüm yöneticilerine ilişkin notları içeren bir Ruby 3.3 güncelleme rehberi yazdım: https://mac.install.guide/ruby/update.html
  Merak ediyorum, hangi sürüm yöneticisini önermek gerekir bilmiyorum. Daha önce asdf, frum, chruby önermiştim

  • rbenv ya da asdf ile pek sorun yaşamıyorum. Hem yerelde hem üretim ortamında ikisini de kullanıyorum

• Socket.getaddrinfo gibi ad çözümleme işlemleri artık kesintiye uğratılabiliyor; ad çözümleme gerektiğinde her seferinde bir worker pthread oluşturup onun içinde getaddrinfo(3) çalıştırdığı söyleniyor
  Diğer dil runtime’ları da benzerini yapıyor mu merak ediyorum. Thread oluşturmak çok ağır görünüyor ama pratikte büyük bir sorun olmayabilir. Kendi benchmark’larına göre de ek yük küçük ama sıfır değil
  10000.times { Addrinfo.getaddrinfo("www.ruby-lang.org";, 80) } yamadan önce 2,3 saniye, yamadan sonra 3,0 saniyeydi; 100.times { URI.open("https://www.ruby-lang.org";).read } ise yamadan önce 3,36 saniye, yamadan sonra 3,40 saniyeydi

  • Bunun, standart kütüphanedeki tüm giriş/çıkış işlemlerinin async/fiber desteklemesi gerektiği için mi olduğunu merak ediyorum
    Python’daki gibi aynı işlemin async “renkli” bir sürümünü yeniden uygulamak yerine, her şeyin varsayılan olarak asenkrona taşındığı izlenimini aldım; doğru mu bilmiyorum
  • Yeni thread oluşturmaktansa fiber daha hafif olmaz mı diye düşünüyorum

• Zaten Python ve NodeJS biliyorsanız Ruby öğrenmeye değip değmeyeceğini merak ediyorum. Ruby ilginç ama zor görünüyor

  • Ruby temelde daha az popüler ama daha zarif bir Python’a yakın. Sağlam bir genel amaçlı dil ve özellikle shell script’leri ya da veri temizleme gibi işler için iyi
    Node ve Python’da yetkinseniz öğrenmesi epey kolay olacaktır. Dezavantajı, o dilleri zaten biliyorsanız temelde yeni bir şey sunmaması. Avantajı daha çok estetik tarafında; Ruby kodu gerçekten güzel ifade etmenin yollarını sunar ve teşvik eder, bunu deneyimlemek de keyiflidir
  • Ruby’nin, Python veya Node’a kıyasla shell script tarzı işler ve sistem işleri için etkileşimli/keşif odaklı programlamada çok daha iyi olduğunu düşünüyorum. “Daha iyi bash” ya da “daha iyi Perl” olarak kullanmak bile yeterince değerli
    Çoğunlukla TypeScript kod tabanlarında çalışıyorum ama log verileri ya da yarı yapılandırılmış metinlerle uğraşırken veya birden çok dosyada regex tabanlı yeniden yazımlar yaparken Ruby’yi sık sık çıkarıp kullanıyorum. Ruby çok eğlenceli; düzenli kullandığım diller arasında muhtemelen en eğlencelisi, bu da başlı başına bir ödül
  • Ne elde etmek istediğinize bağlı. En ilginç yanı, Ruby’nin birçok açıdan Python’a çok benzerken aynı zamanda epey farklı olması
    En büyük örnek, Ruby’nin blokları gerçekten sevmesi. Standart kütüphanenin her yerindeler, bolca sözdizim şekeri var ve bloklar etrafında kurulmuş sayısız DSL bulunuyor. Standart işlevsel özellikler de uzun zamandır standart kütüphanede yer aldığı için işlevsel stili akıcı ve okunabilir şekilde kullanmak mümkün
    Python’da da teknik olarak bunların çoğu yapılabilir, ama yazması ve okuması çok daha hantal görünür. Python’da lambda var, ancak basit kullanımların ötesinde pek sevilmiyor gibi; bunun yerine fonksiyonlar her yerde birinci sınıf değer olarak kullanılıyor
  • Öğrenirken kodu iyileştirmeye yönelik ipuçları almak için Rubocop kullanmak iyi olur. Harika bir linter ve öğretmen
  • 10 yıldan biraz daha uzun süre önce, 2011–2013 civarında Ruby’yi, daha doğrusu Rails’in Ruby’sini biraz kullanmıştım. O dönem, 2005’te ortaya çıkıp 2007–2009’da büyük popülerlik kazanan RoR’un etkisinin hâlâ sürdüğü bir zamandı
    Yeni teknolojilere duyarlı kişiler, RoR ile yapılanlardan çok daha hızlı olan node.js ve AngularJS tabanlı API odaklı geliştirmeye geçiyordu. 2013’te RoR’un standart yaklaşımı hâlâ monolitikti ve frontend/backend ayrımı şeklindeki yeni paradigmaya iyi uyum sağlayamadığı için yaşlı görünüyordu
    Ruby’nin kendisinden değil de Ruby ile yapılmış framework’ten uzun uzun bahsetmemin nedeni, bugün bile Ruby geliştirmesinin %95’inin Rails uygulamaları olduğunu sanmam. Ruby’nin ünlenmesi büyük ölçüde Ruby on Rails sayesinde oldu; RoR düşüşteyse Ruby de Perl gibi küçük ama tutkulu bir topluluğa küçülene kadar aynı yolu izleyecek gibi
    Sadece dilin kendisine bakınca Python veya TypeScript yerine Ruby seçmek için bir neden aklıma gelmiyor. Dil ya da platform açısından Ruby’nin, zaten daha iyi yerleşmiş rakiplerinden daha iyi yaptığı bir şey yok gibi görünüyor

• Prism ilginç. Bunu kullanan Ruby kod analiz araçları var mı merak ediyorum. Şirket kodunu analiz etmenin bir yolunu arıyordum

  • Ruby LSP Prism kullanıyor. Kevin Newton, Rubocop ile birlikte kullanılabilen whitequark/parser gem’i için Prism tabanlı bir backend uyguladı: https://github.com/kddnewton/parser-prism

• RUBY_MAX_CPU=n ortam değişkeninin en fazla N, yani en fazla yerel thread sayısını belirlediği ve varsayılan değerin 8 olduğu söyleniyor
  Varsayılanın Rust’ın Tokio’su veya pek çok M:N runtime’da olduğu gibi mantıksal çekirdek sayısı olması gerekmez mi diye düşünüyorum

  • Sonradan eklenebilecek bir optimizasyon ve bazı incelikleri var. Hatırladığım kadarıyla Go da birkaç yıl benzer durumdaydı; init() veya main() içinde GO_MAX_PROCS ayarladığımı hatırlıyorum
  • Maksimum CPU sayısına sabit bir üst sınır koymak doğru görünmüyor. Kullanılabilir çekirdek sayısına dayanması yeterli olmaz mı

• Ruby 4.0’da, gem’leri şu anki gibi örtük biçimde ve global namespace’e almak yerine açık importa izin verilse iyi olur

  • Chris Salzberg’in Im’i ilginizi çekebilir. Ruby 3.2’de bile şimdiden kullanılabiliyor: https://github.com/shioyama/im
    Varsayım aşamasındaki “namespace on read” özelliği tartışması da var: https://bugs.ruby-lang.org/issues/19744
  • Örtük ya da açık olsun, global namespace bence sorun değil. Teoride garip ama pratikte teamüller ve sosyal normlar sayesinde nadiren sorun yaratıyor
    Global namespace’in her gem’in tam olarak tek bir sürümünü desteklemesi, kararlı ABI ve kullanımdan kaldırma için geçiş süresi önemseyen sağlıklı bir kültürü de teşvik ediyor. Bazı dil ekosistemleriyle karşılaştırınca rüya gibi bir ortam
  • Bu Ruby’den çok Rails tarafıyla ilgili değil mi diye düşünüyorum. Çoğu projede aradaki farkın fiilen olmadığını biliyorum ama bu Rails geliştiricilerinin kararı ve Ruby geliştiricilerinin yaptığı işle ilgisiz olabilir
    Ya da tamamen yanlış konuşuyor da olabilirim
  • Ruby 4.0’ı 2030’dan önce görmek zor olacaktır
    https://youtu.be/4MM5b2F9zrM?si=UT3aUbD6p_uBZehS&t=2347