Uzun Zaman Geçse de Ruby’nin Hâlâ Neden Ev Gibi Hissettirdiği

 (caio.ca)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Ruby en hızlı ya da en popüler dil değil, ancak 15 yılı aşkın süre boyunca birçok dil arasında gidip geldikten sonra bile işi keyifle yapmak istendiğinde yeniden seçilen bir dil olmaya devam ediyor
  • refinements, Forwardable, SimpleDelegator, Object#then, Kernel#tap ve numaralı parametreler küçük sözdizimsel kolaylıklar ve okunması rahat bir akış sunuyor
  • Standart kütüphanedeki Thread::Queue, json, csv ile RuboCop ve Ruby LSP, küçük gem’ler ve karmaşık yapılandırmalar olmadan da pratik bir geliştirme ortamını korumayı sağlıyor
  • Ruby 3.x’teki YJIT ve 4.x’teki ZJIT, CPU yoğun işlerdeki farkı azaltıyor; basit bir Fibonacci karşılaştırmasında ZJIT’li Ruby, Go’nun 2–3 katı içinde kaldı
  • Rust·Go·Python’ın daha uygun olduğu alanlar olsa da web uygulamaları, arka plan işleri ve iç araçlarda geliştirici mutluluğu ile hızlı yineleme hızı Ruby’nin güçlü yanı olmaya devam ediyor

Ruby’nin rahat hissettiren dil özellikleri

  • Ruby en hızlı ya da en popüler dil değil, ancak 15 yılı aşkın süre boyunca birçok dil arasında gidip geldikten sonra bile gerçekten işten keyif almak istendiğinde yeniden dönülen bir dil olarak kalıyor
  • refinements, sınıfları yalnızca sınırlı bir kapsam içinde açmaya izin vererek tüm ad alanını kirletmeden dosya ya da blok içinde küçük sözdizimsel kolaylıklar eklemeyi sağlıyor
    • Test yardımcıları ya da büyük kod tabanlarındaki iç DSL’ler için çok uygun
    • using QuotingRefinement çağrısının yapıldığı yerde ancak "hello".quote gibi metotlar kullanılabiliyor
  • Standart kütüphanedeki Forwardable ve SimpleDelegator, sarmalayıcı metotları elle yazmadan ya da ek gem çekmeden temiz bir delegation yapmayı mümkün kılıyor
    • Zaten Rails kullanılıyorsa Active Support’taki delegate daha rahat olabilir, ancak çekirdek Ruby sürümü genel betikleri hafif tutuyor
  • Object#then ve Kernel#tap, ara değişken oluşturmadan işleri yukarıdan aşağı okunabilen zincirler halinde bağlamayı sağlıyor
    • User.new(params).tap { ... }.then { ... }.save gibi bir akışla oluşturma, loglama, normalleştirme ve kaydetme adımları peş peşe yazılabiliyor
  • Ruby 2.7 sonrası gelen numaralı parametreler, kısa callback’lerde gürültüyü azaltıyor
    • items.map { _1.price * 1.1 } gibi kullanımlarda blok argümanını açıkça belirtmek gerekmiyor
  • fiber scheduler, bir event loop bağlandığında eşzamanlı kodu sıralı kod gibi görünen bir biçimde yazmayı mümkün kılıyor
    • Fiber.schedule do ... end biçiminde diğer fiber’larla işbirliği yapan kod ifade edilebiliyor

Araçlar, performans ve ekosistemin bugünkü durumu

  • Shopify’ın Ruby LSP’si, minimum yapılandırmayla editör entegrasyonu sunuyor ve kademeli tip uygulaması için Steep ya da RBS ile iyi çalışıyor
  • RuboCop, başka ekosistemlerde görülen törensel süreçler olmadan stilin tutarlı kalmasını sağlıyor
  • Standart kütüphane, yaygın işler için birçok küçük gem eklemeyi gerektirmemesiyle sessiz ama önemli bir güç olmaya devam ediyor
    • Kuyruk gerekirse Thread::Queue kullanılabiliyor
    • JSON ya da CSV ayrıştırma için json ve csv kütüphaneleri, çoğu gerçek kullanım senaryosunu büyük prosedürler olmadan karşılıyor
  • Ruby 3.x’teki YJIT’in ardından 4.x serisine ZJIT geliyor
    • ZJIT, aynı temel üzerinde daha agresif çalışan bir JIT ve daha sıcak yürütme yollarını daha etkili biçimde derliyor
    • İlk veriler, CPU yoğun işlerde Ruby ile büyük fark açan diller arasındaki mesafenin anlamlı biçimde azaldığını gösteriyor
    • CRuby ZJIT, Ruby’nin ana deposunda geliştiriliyor
  • Aynı makinede özyinelemeli Fibonacci uygulamasını karşılaştıran basit bir benchmark’ta ZJIT’li Ruby, Go’nun 2–3 katı içinde kaldı; bu örnekte optimize edilmiş Rust’tan da çok geri düşmedi, Python with pypy ise geride kaldı
    • Mikrobenchmark’ların sınırları olsa da, JIT’in optimize etmek için zaman bulduğu ısınmış kod yollarında gerçek uygulamalar daha da büyük kazanç görebilir
  • Rust ile karşılaştırıldığında Ruby’nin gücü, iş mantığını yineleme hızında ortaya çıkıyor
    • Rust’ta çalışma zamanında açık olan işlerde bile borrow checker ile uğraşmak zaman alabiliyor
    • Go’nun eşzamanlılık temel bileşenleri çok güçlü, ancak yakın zamana kadar generics yoktu ve biraz katı hata işleme yüzünden basit betikler gerekenden ağır hale gelebiliyor
    • Python en yakın zihinsel kuzen olsa da, özellikle sınıflar ve decorator’lar çevresinde aynı üst düzey fikirleri ifade etmek için daha fazla boilerplate gerektiriyor
  • Modele kod yerleştirirken token verimliliği de Ruby’nin pratik bir avantajı oluyor
    • Bloklar do/end ya da süslü parantezlerle ifade edilebiliyor ve okunabilirliğin izin verdiği yerde metot çağrılarında parantez neredeyse hiç gerekmiyor
    • Hash’ler ve keyword argümanlar birinci sınıf özellikler ve özlü; bu da yapısal gürültüsü fazla dillere kıyasla aynı bağlam penceresine daha fazla gerçek mantık sığdırmayı sağlıyor
  • Ruby’nin metaprogramming araçları, küçük ve okunabilir API’ler oluşturmak için çok uygun
    • define_method, class_eval, missing method yakalama gibi özelliklerle kod üretim aşaması olmadan ifade gücü yüksek API’ler kurulabiliyor
    • dry-rb ya da aasm gibi kütüphaneler bu özellikleri ölçülü kullanarak temiz durum makineleri ve doğrulama katmanları sunuyor
  • Topluluk araçları ve dağıtım akışları da olgunlaştı
    • byebug ve pry, başka yerlerde kullanılmış birçok debugger’dan daha esnek hissettiriyor
    • Arka plan işlerinde solid_queue ve good_job yeterince sade; tüm uygulamayı bir öğleden sonra içinde anlayabilecek kadar erişilebilirler
    • Kamal, birçok kişi için eski capistrano tarzı prosedürlerin yerini aldı ve gerçekten küçük ekip işleten insanların yaptığı bir araç gibi hissettiriyor
  • Bu, Ruby’nin her işte Rust ya da Go’yu yendiği anlamına gelmiyor; Rust ya da Go’nun daha uygun olduğu alanlar var
  • Web uygulamaları, arka plan işleme ve iç araçlardan oluşan geniş orta alanda Ruby, aşırı törensellik ya da sık bağlam değişimi olmadan geliştirici mutluluğu sunmayı sürdürüyor
  • Küçük kolaylıklar ve dilin genel hissi, 10 yıldan uzun süre sonra bile elde ilk ona uzanılan seçenek olmasını sağlıyor; yeni JIT çalışmaları ve dildeki sürekli iyileştirmeler de bunu daha da güçlendiriyor

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Lobste.rs görüşleri

  • “törensiz RuboCop” ifadesine katılmak zor
    RuboCop’ta hangi cop’ların seçilip ayarlanacağı ve son güncellemelerle eklenen yeni cop’ların açılıp açılmayacağı konusunda epey tartışma oluyor
    StandardRB çok daha törensiz bir yaklaşıma yakın, ama sonuçta onda da birini seçmek gerekiyor
    Lint’in dile gömülü olduğu diller, Ruby’ye kıyasla çok daha az zahmetli ve küçük stil tartışmaları da daha az

    • Yaklaşık 10 yıl önce Sidekiq kod tabanında Standard’ı seçtim ve bir kez bile pişman olmadım
      Kısıtlamalar aslında özgürlük sağlar
    • Neden tüm varsayılanları kullanmıyoruz ki?
      Genel olarak linter yapılandırmalarına karşıyım ve bu tür kararları topluluk varsayılanlarına bırakmayı tercih ederim
    • Açıkçası bu konuda ben de gidip geliyorum
      Bir yandan RuboCop varsayılanları yeterince iyi, bu yüzden kodlama stilini daha da parçalamak yerine onları takip edip birlikte geliştirmek gerektiğini düşünüyorum
      Öte yandan bazen fazla kanaatli oluyor; bu yüzden standard.rb gibi bir şeye ihtiyaç varmış gibi de görünüyor
      Bunu, Ruby öğrenen ya da Ruby’ye geri dönmeye çalışan birinin rahatça kod yazabilmesi için sayısız gem ile uğraşmak zorunda kalmaması açısından yazmıştım
    • %100 katılıyorum
      Go çıktığında tek bir resmî biçimlendirme sistemi sunmasının gerçekten çok iyi bir karar olduğunu düşünmüştüm
      Beyin bir örüntü eşleştirme makinesi; bir şeye alışınca onu görmezden gelmeye başlıyor, ama seçenekler olduğunda rahatsızlık hissediyor ve herkes bir yana bir yana çekiliyor
      Sorun şu ki ne RuboCop ne de Standard, Ruby’de böyle bir otoriteye sahip olabilir
      O otoritenin çekirdek ekipten gelmesi gerekir, ama Ruby felsefesine aykırı olduğu için bunun olması pek olası değil
      Kendi projelerimde tüm RuboCop cop’larını kapatıp sadece bazılarını açıyorum
      Tek tırnak en iyisidir 😀
    • Ben de o noktada duraksadım
      Başka yazılar da bu noktaya değiniyor gibi: https://caio.ca/blog/coding/my-complicated-relationship - “The Wild West of Code Formatting”
      Yani “basit bir yerleşik çözüm değil; yüzlerce yapılandırılabilir cop var ve hangilerinin etkinleştirileceği bitmeyen tartışmalara yol açıyor” deniyor

  • Genel olarak katılıyorum, ama refinements’ın ilk örnek olması biraz talihsiz
    Neden sevildiğini anlıyorum, ama daha çok sosisin nasıl yapıldığını bilmesen daha iyi olur türünden bir şey
    Anlamsal yapısı o kadar hassas ki, kullanılmaya başlanmasının üzerinden 10 yıl geçmiş olmasına rağmen MRI’da hâlâ baş ağrıtan bug’lar bulunuyor
    Örneğin sadece son iki hafta içinde https://bugs.ruby-lang.org/issues/22071 ve https://bugs.ruby-lang.org/issues/22058 vardı
    Performans açısından da birçok optimizasyonu zorlaştırıyor ve şu anda boxes’ta da benzer bir şey yeniden yaşanıyor

    • boxes fikri, her şeyin onlarca yıldır aynı küresel ad alanında yaşadığı bir dile sonradan eklenmesi zor bir şey gibi görünüyor
      Uygulama düzeyinde de hâlâ çok sayıda gizli bug vardır diye tahmin ediyorum; kütüphane tarafında da muhtemelen öyledir
      Artık Ruby’yi çok kullanmıyorum ama bunun nasıl oturacağını merak ediyorum
      İlginç görünüyor

  • Bu yazı, benim “Returning to Rails” yazımdaki[1] deneyimlerle de büyük ölçüde örtüşüyor
    Doğrulama yanlılığı olabilir, ama Rails kodunun güzelliğini yeniden keşfeden ya da yeniden takdir eden daha fazla insan varmış gibi geliyor
    Yine de müzik veya sanat zevklerinin geç ergenlikte ya da 20’li yaşlarda yerleşmesi olgusu da aklıma geliyor
    Ruby ile Rails’in “altın çağında” ilk tanışan insanlar olarak, Rails 3 ve Capistrano’nun olduğu döneme pembe gözlüklerle bakıyor olabilir miyiz diye düşünüyorum
    O zamanlar bir Ruby “shop”unun içindeydim ve çevremde de sadece Rails geliştiricileri vardı; bu yüzden sanki her yerde Ruby varmış gibi geliyordu
    Ama lobste.rs dizisindeki[2] Ruby’nin aslında her zaman oldukça niş bir dil olduğu görüşünü görünce, bunun da etkisi olmuş olabilir diye düşündüm
    Yine de Ruby bana hâlâ ev gibi geliyor ve zihnimin çalışma biçimiyle birebir örtüşüyor sanki
    Neredeyse hiç çeviri süreci yok, sürpriz yok; resmî bir makale yazmaktan çok bir arkadaşla konuşuyormuşum gibi
    Henüz bu kadar iyi oturan başka bir dil bulamadım ve bunun tamamen “bugünün gençleri işte” tarzı bir düşünceden kaynaklandığını da sanmıyorum
    Her hâlükârda bu kadar uzun süre hayatta kalmış olmasına seviniyorum
    Ayrıca “tap / new” zincirini gösterdiğin için teşekkürler
    Yapı o kadar güzel ve kullanışlı ki durup baktım; kesinlikle kullanacağım gibi görünüyor
    PS - Konuyla doğrudan ilgili değil ama ana sayfadaki AI avatarı biraz ürkütücü
    Güçlü biçimde “bu yazıyı bir bot mu yazdı?” türünden bir uncanny valley hissi veriyor
    Böyle bir şey gördüğümde kısa süreliğine gerçekten bir insanla konuşup konuşmadığımı sorguluyorum
    [1]=https://www.markround.com/blog/2026/03/05/returning-to-rails-in-2026/
    [2]=https://lobste.rs/s/jreqtw/returning_rails_2026

    • Gerçek bir insan olduğumu kesin olarak söyleyebilirim
      Sadece gerçek fotoğrafımı paylaşmak istemiyorum ve o avatar da beni gerçekten tanıyanların tanıyabileceği kadar benziyor

  • Ruby 3.4’e it blok parametresi eklendi; örnekteki _1 yerine kullanılabilir

    items.map { it.price * 1.1 }

    https://rubyreferences.github.io/rubychanges/3.4.html/…

    • it’ten bahsetmeyi unutmuşum
      Görece yeni bir özellik olduğu için olsa gerek, iterator’larda it yazmak elimde bir türlü alışkanlık haline gelmedi

  • Ruby ile kod yazmayı gerçekten seviyordum ama test yükü fazla büyüdü
    Dile biraz daha fazla tür güvenliği eklemenin yardımcı olacağını düşünmüştüm, ama #{last_job} içinde kod tabanına Sorbet ekleyince kod yazmanın ivmesi ve keyfi tamamen öldü
    Popüler olmayan bir görüş olabilir ama Sorbet gibi bir şeyin varlığının kendisi bile bana Ruby’de kötü bir koku gibi geliyor
    Ruby’nin kendisi güçlü ve eğlenceli bir dil, ama insanlar onu başlangıçta tasarlanmadığı işlerde kullanmaya başladı ve bu süreçte dilin eksik yanlarını telafi etmek için araçlar eklemeye başladılar
    Sonunda her satır sıkıcı bir angarya gibi gelmeye başladı ve gerçek kodu yazmaktan çok çeşitli build, test ve lint araçlarını bekleyerek zaman geçiriyordum
    Buna bir de aşırı tasarlanmış build ve dağıtım süreçleri eklenince, en temel işler bile uzun sürmeye ve işkenceye dönüşmeye başladı
    2012 civarındaki Ruby dünyasını çok özlüyorum
    Geriye dönüp bakınca gerçekten güzel zamanlardı

    • Deneyimine göre daha uygun dil neydi?
      “Başlangıçta tasarlanmadığı işler” derken büyük Rails uygulamalarını kastettiğini varsaydım

  • 10 yıl sonra Ruby’ye geri döndüm ve “AI” çağında, gözümün önünden akıp giden kodu gerçekten anlayabilmek ve LLM’i yönlendirebilmek ya da durdurabilmek faydalı
    Daha laf kalabalığı yapan dillerde bu daha zor

  • Ruby’yi özlüyorum; hatta daha da ötesi, günlük production işlerinde böyle bir dilin mümkün olmasını özlüyorum
    Bu bir umuttu, hatta umutun kendisiydi
    En azından benim için uzun süre öyleydi

    • Ne oldu ki?

  • AI’nin alelacele ürettiği bir yazı gibi okunuyor
    Son dönemdeki diğer blog yazıları da benzer

    • Ben öyle bir izlenim almadım
      Sana bunu düşündüren ipuçları nelerdi?
      Bu sitede AI üretimi düşük kaliteli yazılara dikkat çekmek iyi, ama yanlış pozitiflerden kaçınmak ve neden böyle düşündüğünü açıkça söylemek gerekiyor
    • Bana AI’nin alelacele ürettiği bir yazı gibi gelmedi
      Neden böyle düşündün?
      Bu tür uyarılar iyi, ama yanında gerekçenin de söylenmesini çok daha fazla tercih ederim

  • Kariyerimin başlarında Ruby ile çalıştığıma dair güzel anılarım var
    Ruby’de gerçekten iyi hissettiren bir şey var
    Ama sanırım geçen yıl yakın zamanda biraz Ruby kullandığımda, web tabanlı standart kütüphane dokümantasyonunda gezinmenin zor olduğunu hissetmiştim
    Bu sadece bana mı öyle geliyor? ruby-lang.org dokümantasyonuna alternatif var mı?

  • Bu yazı biraz tuhaf hissettiriyor
    Ruby ile bir proje ve bir SDK yazma fırsatım olmuştu; o deneyimden sonra bir daha Ruby kullanmak isteyeceğimi hiç sanmıyorum