Rust'tan Ruby'ye

• Rust web uygulaması crate'ini Ruby on Rails'e taşıma üzerine kişisel bir proje deneyi; hedef, Tera ve Axum tabanlı 14.943 satırlık kod
• Mevcut Rust yapısında Playwright E2E, izole veritabanı namespace'leri, mocking servisleri ve dahili API crate'i gerektiği için test maliyeti yüksek
• LLM karşılaştırmasında Rails, toplam 710 puanla Rust/Axum/Diesel'in 480 puanını geride bırakıyor; geliştirme hızı ve birim testi kolaylığı güçlü yanlar olarak değerlendiriliyor
• Local Qwen3.6 ile yapılan tek seferlik dönüşüm yaklaşık 30 dakika sürdü ve Ruby kodu 3.322 satıra indi, ancak henüz çalıştırılıp doğrulanmadı
• Rails'in avantajları varsayılan özellikleri ve sade test yapısı; Ruby'nin tip güvenliği eksikliği ise Sorbet veya ajan tabanlı tip ekleme ile telafi edilebilir

---

Geçiş deneyinin arka planı

• Kişisel projenin bir parçası olan Rust web uygulaması crate'i, Ruby on Rails'e geçiş hedefi olarak seçildi
  • Projenin tamamı yaklaşık 30 bin satır ölçeğinde ve geçiş hedefi olan crate, Tera ve Axum ile yazılmış bir web uygulamasına daha yakın
  • Geçiş hedefi Rust kodu toplam 14.943 satır ve derlenmesi yaklaşık 10 saniye sürüyor
  • Kodun kendisi çok büyük olmasa da, peşinden gelen bağımlılık yapısı oldukça ağır
• Mevcut Rust yapısında test maliyeti yüksek
  • E2E testleri için Playwright yapılandırması gerekiyor
  • Mocking zor olduğu için izole veritabanı namespace'leri ve mocking servisleri gerekiyor
  • Playwright'ın uygulamayla headless modda etkileşime girmesi için ayrıca dahili bir API crate'i de gerekiyor
• Ruby ve Ruby on Rails daha sade bir alternatif olarak değerlendirildi
  • Ruby tipsiz olduğu için kararlılığı Rust'a göre daha düşük olabilir
  • Sorbet kullanılırsa Ruby'de de tip güvenliği kısmen güçlendirilebilir
• Birden fazla LLM örneğiyle karmaşıklık, kararlılık, test kolaylığı gibi ölçütler karşılaştırıldığında Rails daha yüksek puan aldı
  • Rust/Axum/Diesel toplamı 480, Rails 710, Rails + Sorbet ise 695 olarak hesaplandı
  • Rails; bireysel geliştiriciye uygunluk 90, geliştirme hızı 90, birim testi kolaylığı 90 ile yüksek değerlendirildi
  • Rust/Axum/Diesel ise güvenlik 95, performans 95 ile yüksek puan alırken birim testi kolaylığı 20 ve entegrasyon testi kolaylığı 30 ile düşük değerlendirildi
  • Basit toplam ölçütüne göre Rails uygulamasının 1,47 kat daha iyi sonuç verebileceği düşünüldü

Dönüşüm sonucu ve değerlendirme noktaları

• Local Qwen3.6 ile nispeten küçük proje tek seferde dönüştürüldü
  • Dönüşüm yaklaşık 30 dakika sürdü
  • Henüz çalıştırılmadığı için gerçekten işleyip işlemediği doğrulanmış değil
• En büyük değişim kod satırı sayısındaki azalma oldu
  • Rust dosyalarının toplam satır sayısı: 14.943 satır
  • Ruby dosyalarının toplam satır sayısı: 3.322 satır
  • Satır sayısı %77 azaldı ve Ruby'deki 1 satır yaklaşık 4,49 satır Rust'a karşılık geliyor
• Dönüştürülen Ruby kodu, göz gezdirilen kapsamda temiz ve idiomatik görünüyor
  • Hâlâ hata ihtimali var
  • Sonrasında daha ayrıntılı incelenecek
• Ek değerlendirme noktaları tip desteği, Rails'in yerleşik özellikleri ve testlerin sadeleşmesi
  • Ajan kullanarak tip eklemek, tip güvenliği sorununu hafifletebilir
  • Ruby/Rails, “batteries + kitchen sink included” yaklaşımına daha yakın ve 3GiB boyutundaki derlenmiş bağımlılıklardan daha iyi olarak değerlendiriliyor
  • Testlerin çok daha kolay hale gelmesi bekleniyor
• Ruby test örneğinde LLM çağrısı VCR.use_cassette("llm_call") ile sarılıyor ve sonuç boyutu kısa bir yapıyla doğrulanıyor

    VCR.use_cassette("llm_call") do
      result = LlmClient.match(entry, data_list)
      expect(result.results.size).to eq(data_list.size)
    end
  

• Rust test örneği ise mocking sağlayıcısının doğrudan uygulanmasını gerektiren daha uzun bir yapıya sahip
  • Arc<RwLock<Vec<Response>>>, AtomicUsize, async_trait, tokio::test kullanılıyor
  • Yanıt listesini ve çağrı sayısını yöneten bir MockProvider oluşturuluyor, ardından Provider trait'inin match fonksiyonu uygulanıp testte sonuçlar ve çağrı sayısı doğrulanıyor
• Bu bir kişisel proje olduğu için daha cesur seçimler yapılabiliyor; Rust'tan Ruby'ye geçiş bundan sonra da dikkatle değerlendirilecek

[GN⁺]

Hacker News görüşleri

• İnanması güç bir hikâye. Kulağa şöyle geliyor: “Teknik olarak kaşımak istediğim bir yer vardı ve yerel yapay zeka işi 30 dakikada bitirdi. Çalışıyor mu diye Start’a basmayı bile denemedim ama blog yazısını yazdım…”

  • Şu an ilk sayfada 1 numara olması, projenin gerçekten çalışmasının önemli olmadığını gösteriyor. Okurlar da yazıyı düzgün okumamış olmalı
    Tabii bunu botlar yukarı taşımadıysa
  • 2016: Yeni JavaScript kütüphaneme bakın!
    2026: Benim yazmadığım çalışmaya bakın!
    2036: C denen antik Latinceyle 200 satırı nasıl yazdım
  • “İnanması güç”ten çok, 2026 itibarıyla gayet sıradan bir şeye yakın
  • Yine de 5 saat inceleme yapmış. O yüzden ¯\(ツ)/¯

• Başta ilginç bir yazı olacak sandım ama dönüşüm için LLM kullandığını görünce ilgim hemen kayboldu. “Bunu yapmak istedim, astıma yaptırdım, şimdi de size onu anlatacağım” demeye benziyor
  Dönüşümü gerçekten kendisi yapmamış ve üzerine derin düşünmemişken bunu okumak için bir sebep göremiyorum

  • En büyük sorun, yazarın doğrulama bile yapmamış olması. Birkaç modeli birleştiren büyük bir araç dönüşümü 6 saat çalıştırdıktan sonra, zorlu hesapları ya da mantığı nasıl ele aldığını elle kontrol ettiğimde stub’lar veya hardcode edilmiş true dönüşleri gördüğüm oldu
    Bu yüzden sadece smoke test çalıştırırsanız başarılıymış gibi görünebilir
  • Daha büyük sorun, gelecekte yazılım geliştirmenin böyle ilerleyecek olması
    Zanaatkâr programlama dışında programlama dillerinin kendisi çok da önemli olmaktan çıkacak
    LLM’ler geliştikçe mesele sonunda sadece spesifikasyonu hangi tür dilde üreteceğinizi seçmeye dönüşecek
    UML ve RUP kampı intikamını almış olacak
  • Mesele kodu bizzat yazıp yazmaması değil, farkları görüp muhtemelen en iyi olmayan bazı seçimleri yapmış olması
    Başka bir yorumda da söylendiği gibi oldukça kapsamlı inceleme yapmış. Büyük bir proje değil; birkaç can sıkıcı kısmı dışında çoğu bir web uygulaması
    “Hiç düşünmedi” değerlendirmesini haksız buluyorum. Düğmeye basıp YOLO yapmış değil
    Takasları ve sonuçları araştırdı; Rust kod parçalarıyla Rails arasındaki fark gerçekten büyüktü ve Rust uygulamasının test edilebilirliği 2 aydır düşündüğü bir konuydu
    LLM meraklılarının dediği gibi bağlam önemlidir ;)

• Herhangi bir dilin ve framework’ün, Ruby on Rails kadar geliştirici mutluluğunu öncelediğinden emin değilim

  • Rails projesinde çalıştığım zamanlardaki kadar mutsuz olduğum çok az olmuştur. Sitede bir bug görüyorsun, yanlış render edilen view’ı bulmak için grep çalıştırıyorsun. O bölümü render eden method çağrısını buluyorsun, method adıyla tekrar grep yapınca sonuç 0 çıkıyor
    Bir yerlerde bir şey birleştiriliyor ama nerede olduğunu anlayamıyorsun; sonunda işi bırakıp bir saat dokümantasyon okuyorsun. Bütün gün Rails kullanan biri için sorun olmayabilir ama configuration yerine convention benim için devasa bir antipattern
  • Elixir ve Phoenix’te de benzer bir his alıyorum ama en azından method_missing gibi kendi ayağına sıkan bir mekanizma yok
  • Silikon Vadisi zevklerine sahip topluluklarda çekici görünmeyebilir ama Java ve .NET framework’leriyle de oldukça memnun çalıştım
    Mutluluk her zaman performansa dönüşmüyor. Twitter’ın JVM ve Scala’ya geçmeden önceki meşhur logo vakası aklıma geliyor
    Ruby on Rails ün kazandı ama benzer deneyimleri daha önce Tcl tabanlı AOLServer ve Vignette’te de yaşamıştım
    Portekizli bir startup’ta da kendi varyantlarını yaptılar, kurucular daha sonra OutSystems’i kurdu. Bu, web sitesi ve dağıtık sistem geliştirme için erken dönem grafiksel RAD araçlarından biriydi; low-code/no-code yaklaşımla JVM veya CLR altyapısını hedefliyordu
    Yine de artık CRuby’de JIT’in varsayılan olarak gelmesini görmek sevindirici
  • En fazla kısa vadeli mutluluk sağlıyor; bakım yapılabilirlik, performans, güvenilirlik, ölçeklenebilirlik gibi diğer tüm mimari niteliklerin bedeliyle geliyor

• Zaten özlü olan Ruby on Rails kodunu daha da uç noktaya taşıyan propel_rails adında bir gem paketi yaptım. En üst düzey API controller’ları ve concern’leri oluşturuyor; oradan da tüm RESTful resource’ları (model, controller, serializer, unit test ve E2E test) sıfır boilerplate ile üretiyor
  Sonuçta controller’larda sadece API’nin izin verdiği niteliklerin listesi kalıyor çünkü RESTful action’lar otomatik üretiliyor. Tam anlatması biraz zor ama Ruby’nin metaprogramming gücü gerçekten şaşırtıcı şeyleri kolaylaştırıyor

  • Bu, rafine edilmiş bir CRUD gibi geliyor
    Domain model temelinde çalıştığını mı düşünmeliyim?
  • rubygems’de bulunabiliyor ama oradan verilen GitHub bağlantısı 404 dönüyor

• Ben de benzer bir durumdayım
  Go ve Rust’ı seviyorum; ikisi de artıları ve eksileri olan harika diller. Ama ne yazık ki ikisiyle de bir SaaS uygulaması yapamadım. Sanki kare bir çiviyi yuvarlak deliğe sokmaya çalışmak gibi
  Çok yanlış düşünüyor olabilirim ama SaaS araçları beraberinde çok fazla hazır mekanizma getiriyor ve ben bunları yeniden icat etmek istemiyorum
  RoR “yeterince iyi”. İstediğinde tip ekleyebiliyorsun, hızlı geliştirebiliyorsun ve araçları da fena değil
  İlk profesyonel işim PHP idi ve içinde çok fazla tuzak vardı. Ruby biraz daha e-ticarete dönük gibi geldiği için ilginçti; Shopify için yeterliyse bana da yeter diye düşünüyorum

• Rust’tan Ruby’ye geçmek mantıklı geliyorsa, başlangıçta Rust’ı seçmek zaten bir hataymış demektir

  • Bu yazının çok iyi bir özeti ve paylaşma kararımın sebebi de buydu

• Ruby’nin Rust’tan yavaş olduğunu düşünenler, Ruby’nin artık pratikte Python’dan daha hızlı olduğunu ama Go ya da Rust’tan daha yavaş kaldığını öğrenince şaşırabilir

  • Genelde hızdan çok bellek kullanımı daha önemli oldu. Çoğu Ruby uygulaması Ruby yüzünden değil, veritabanı yüzünden yavaşlıyor
    Ama birden fazla background worker varsa ve her biri 2 GB’tan fazla bellek tüketmeye başlarsa, bu hızla birikiyor
    Prodüksiyonda bir Rust servisi yazdım; hızdan da etkileyici olan şey, bu servisin 30 MB bellek ile çalışmasıydı
  • Ruby’nin Rust’tan yavaş olduğunu düşünen birinin, Python’dan hızlı olmasına neden şaşırması gerektiğini anlamıyorum. Bunun birbiriyle ne ilgisi var?

• Kışkırtıcı bir şey söyleyeceğim ama çevredeki halka 900+ IQ gösterisi yapmak için iyi olabilir; yine de zeki ve yetenekli geliştiricilerin çoğu Rust’ı pek sevmiyor. Hatta bazıları, tek satır Rust yazmaktansa kendi programlama dilini ve derleyicisini yapmayı tercih ediyor
  Jonathan Blow’un Jai’si ve Ginger Bill’in Odin’i akla geliyor
  Yaratıcılığı ve derinliği kanıtlanmış, yaygın kullanılan güzel kütüphaneler ve framework’ler inşa etmiş daha pek çok kişi var ama burada yer harcamak istemiyorum
  Yine de Rust’ın havalı bir maço kulübü ve sıkı bir kardeşliği var

  • Rust topluluğu “maço kulübü” olmaktan olabildiğince uzak

• Claude, Rails uygulamalarında gerçekten çok iyi çalışıyor. Bu yazının yazarı da belirttiği gibi Ruby az kodla çok iş yaptırıyor ve Rails configuration yerine convention kullandığı için Rails uygulamaları daha da özlü oluyor
  Claude’un Rails uygulamalarını iyi yazmasının bir hipotezi token verimliliği
  Bir zamanlar projeler arasında token verimliliğini ölçüp karşılaştırmaya çalışan şu projeyi görmüştüm; Rails oldukça iyi sonuç veriyordu
  https://felipemrvieira.github.io/SyntaxTax/dashboard/

• Bazen proje boyutlarına bakınca şaşırıyorum. 30 bin satırlık bir kod tabanı küçük mü sayılıyor? Tavanın daha yüksek olduğunu biliyorum ama 30 bin satır çok büyük miktarda bilgi ve davranışsal incelik barındırabilir
  Belki de bu, benim daha çok Go kullanan backend/ağ tarafına odaklı geçmişimden kaynaklanıyordur. 10 bin ila 15 bin satırı aştıktan sonra, genelde tüm kod tabanının modelini kafamda tutmak zorlaşıyor ve bu epey yorucu oluyordu

  • Ne inşa ettiğinize çok bağlı. Birden fazla frontend’i olan bir SaaS uygulaması 30 bin satıra kolayca ulaşabilir