5 puan yazan GN⁺ 2026-02-24 | 1 yorum | WhatsApp'ta paylaş
  • Ladybird tarayıcı projesi, C++’ın yerini alacak bellek güvenli bir dil olarak Rust’u benimsedi ve geçiş sürecinde yapay zeka araçlarından yararlanıyor
  • Daha önce Swift değerlendirildi, ancak C++ birlikte çalışabilirliği ve platform kısıtları nedeniyle sınırlı bulunarak yön Rust’a çevrildi
  • İlk port hedefi JavaScript motoru LibJS oldu; Claude Code ve Codex kullanılarak yüzlerce istemle elle yönlendirilen bir çeviri yapıldı
  • Yaklaşık 2 haftada 25 bin satır Rust kodu tamamlandı ve çıktının da performansın da C++ sürümüyle tamamen aynı olduğu doğrulandı
  • Proje, bir süre daha C++ ve Rust’ın birlikte geliştirildiği yapıyı sürdürecek ve uzun vadede güvenlik ile bakım kolaylığını güçlendirmeyi hedefliyor

Rust’un benimsenme gerekçesi

  • Ladybird, C++’ın yerini alacak bellek güvenli bir dil bulmak için birden fazla dili değerlendirdi
    • Swift, C++ ile birlikte çalışabilirliğinin yetersiz olması ve Apple ekosistemi dışındaki platform desteğinin sınırlı kalması nedeniyle elendi
  • Rust, sistem programlama ekosistemi olgunlaşmış ve çok sayıda katkıcının zaten aşina olduğu bir dil olarak değerlendirildi
  • 2024’te Rust’un C++ tarzı OOP’ye uygun olmaması nedeniyle benimsenmesi ertelenmişti; ancak daha sonra güvenlik ve ekosistem olgunluğu gerekçesiyle yeniden benimsenmesine karar verildi
  • Firefox ve Chromium’un Rust’u halihazırda kullanıyor olmasından hareketle, Ladybird için de uygun olduğuna karar verildi

LibJS port süreci

  • İlk dönüşüm hedefi Ladybird’ün JavaScript motoru LibJS oldu
    • lexer, parser, AST, bytecode generator gibi bağımsız bileşenleri ve test262 tabanlı test kapsamı, bunu iyi bir başlangıç noktası haline getirdi
  • Port işlemi için Claude Code ve OpenAI Codex kullanıldı
    • Bu, otomatik üretim değil, insan yönlendirmeli bir çeviriydi; port sırası ve kod yapısı doğrudan insanlar tarafından belirlendi
    • Yüzlerce istemle ayrıntılı yönlendirme yapıldı; ardından farklı modellerle kod doğrulama ve hata tespiti gerçekleştirildi

Sonuçlar ve doğrulama

  • Hedef, C++ ve Rust işlem hattı çıktılarının bayt düzeyinde aynı sonucu vermesiydi
  • Yaklaşık 25.000 satır Rust kodu 2 haftada tamamlandı; böylece aylar sürecek iş kısaltıldı
  • AST ve bytecode tamamen aynı kaldı ve testlerde ile JS benchmark’larında performans kaybı görülmedi
  • C++ ve Rust işlem hatlarını aynı anda çalıştıran lockstep testleri ile web gezinimi sırasında sonuçların eşleşip eşleşmediği doğrulandı
  • Mevcut kod, C++’tan çevrilmiş yapısını koruyor ve register allocation pattern’lerini bile birebir taklit ediyor
    • Bunun nedeni, C++ işlem hattıyla uyumluluğu korumanın en yüksek öncelik olması
    • İleride C++ işlem hattı kaldırıldığında Rust kodunun sadeleştirilmesi ve temizlenmesi planlanıyor

Gelecek planları

  • Rust’a geçiş, projenin ana geliştirme yönü değil, paralel bir çalışma olarak ilerliyor
  • C++ ve Rust kodu birlikte var olacak ve aralarında net birlikte çalışabilirlik sınırları korunacak
  • Port sırası ve kapsamı çekirdek ekip tarafından yönetilecek; dış katkıcıların önceden koordinasyon sağlaması gerekecek
  • Uzun vadede hedef, güvenliği ve bakım kolaylığını artıran kademeli bir geçiş yürütmek
  • Kararın tartışmalı olabileceği kabul edilse de, bunun Ladybird’ün geleceği için doğru seçim olduğu değerlendiriliyor

1 yorum

 
GN⁺ 2026-02-24
Hacker News yorumları
  • Bu projede bayt düzeyinde birebir aynı çıktı şartı koymaları en akıllıca kısım gibi görünüyor
    Bu sayede eski ve yeni pipeline’ı yan yana çalıştırıp diff karşılaştırması yapabiliyorlar ve çeviri sırasında oluşan hataları anında yakalayabiliyorlar
    Birçok yeniden yazımın başarısız olmasının sebebi, insanların port sırasında “iyileştirme” yapmaya çalışıp eski sürüm, yeni sürüm ya da basit davranış farklarından doğan hayalet bug’ların peşine düşmesi
    C++’tan Rust’a çevrilen sürüm ilk başta biraz tuhaf görünse de sorun değil. C++ tarafı tamamen emekliye ayrıldıktan sonra bunu zaman içinde daha idiomatic hale getirebilirler

    • Port etme birçok şeyi iyileştirmek için iyi bir zamandır ama yeni özellik eklemek için doğru zaman değildir
      Çıktı aynı kaldığı sürece refactor, verimlilik artırma, dokümantasyon yapılabilir
      Kodu okurken dokümante etmenin en iyi zamanlama olduğunu düşünüyorum. Ladybird gibi popüler projelerde dokümantasyon doğrudan geliştirme hızını artırır
    • Bu tarz saf port işlemlerinin daha fazla yapılmasını isterim
      Eskiden migrasyon maliyeti çok yüksekti, bu yüzden “madem yapıyoruz, biraz da iyileştirelim” diye gerekçelendiriliyordu ama sonuçta daha çok hayalet bug kovalanıyordu
    • Bu yaklaşımı gerçekten çok beğendim. Birkaç gün önce test ve doğrulama açısından yazılmış bir yazı okumuştum; bunun böyle karmaşık bir projeye uygulanmış olmasını görmek şaşırtıcı
    • Ben de web framework’lerini bu şekilde birkaç kez dönüştürdüm. HTTP çıktı string’lerini yeni kodda tamamen eşleştirdikten sonra eski sürümü tamamen sildim
    • İyi bir test suite varsa bu yaklaşım çok daha iyi çalışır. Ladybird’de de öyle olduğunu tahmin ediyorum
  • Claude Code ve Codex kullanarak C++ kodunu Rust’a çevirmişler
    Bu tamamen otomatik değildi; insanlar yön verdi ve yüzlerce küçük prompt ile süreci ayarladı
    İki pipeline’ın çıktısının bayt düzeyinde birebir aynı olması şartını en baştan koymuşlar ve sonuçta 2 haftada 25.000 satır Rust kodu tamamlanmış
    AST ve bytecode da birebir eşleşmiş, ayrıca 0 regression elde edilmiş
    Bana göre diller arası port işinde AI kullanmanın doğru yolu tam olarak bu

    • Ben de daha önce bozuk bir Perl script’ini Claude ile Rust’a taşımıştım
      80 dakika içinde Drupal yapısını analiz etti, orijinal tasarımı ve modül yapısını aynen geri kurdu, hatta custom plugin bile ekledi
      Şimdi o sitenin WordPress, ProcessWire, Node.js ve artık Next.js’e kadar taşındığı söyleniyor
    • AI şirketlerinin bu tür işbirlikçi kullanım biçimlerine odaklanmaması üzücü
      Ben “tek prompt ile tamamlanmış kod” değil, AI ile uzun oturumlar boyunca gidip gelerek insan zekasını artıran (IA) araçlar istiyorum
      Ama bu tür araçları büyük ihtimalle sadece geliştirme bilgisi olan insanlar kullanabildiği için pazar küçük olabilir
    • Ben de Rust öğrenirken Claude’a “teach” adlı bir beceri oluşturdum ve onu kullanıyorum
      Claude kodu doğrudan yazmıyor, sadece ipuçları veriyor ve review yapıyor
      Rust, dil özellikleri gereği doğaçlama yazması zor bir dil; bu yüzden bu yöntemden çok memnunum
    • Ben de Claude’u bu şekilde kullanıyorum. “AI her şeyi yapsın” diye değil, tasarım, review, test süreçlerinde birlikte çalışan bir partner olarak
    • Daha önce yazdığım karmaşık bir bash script’ini Claude ile golang’e taşıdım ve hızla kararlılık inanılmaz derecede arttı
      Artık tarayıcıda da çalışan bir wasm sürümü bile var
      Kriptoyla ilgili kısımları kendim yazmadım, o yüzden endişelenmeye gerek yok
  • Rust’a geçiş haberi ilginç ama Ladybird ekibinin eskiden “anti-Rust hype” eğilimi güçlü olduğu için şaşırtıcı
    Yine de Rust’a geçilirse benim katkı yapmam çok daha kolay olur gibi geliyor

    • Ben de Rust’ı seviyorum ama dile yönelik aşırı coşku bazen yorucu gelebiliyor
      Dil sadece bir araçtır ve belli bir dile kimlik bağlamanın gereksiz olduğunu düşünüyorum
    • Rust’ı sevmiyorum ama pratik açıdan en iyi seçenek olduğu zamanlar var
    • Ladybird’ün artık C++/Swift merkezli olmadığını söyleyen bir bağlantı var
    • Dil yönünün sık değişmesi biraz tedirgin edici. Projenin sürekliliği zarar görebilir
  • Andreas hem müthiş bir mühendis hem de girişimci sezgisi olan biri
    Hobi projesini endüstriyel bir projeye dönüştürmesi etkileyici
    Yine de bu kadar hızlı dil geçişleri biraz huzursuz hissettiriyor

    • Andreas sadece iş insanı değil, Serenity OS’u yıllarca tek başına geliştirmiş bir mühendis
      Bence bu projenin doğal şekilde büyümesinin bir sonucu
    • Swift kararının da farklı dilleri bizzat deneyip verdiği rasyonel bir karar olduğu söyleniyor
    • Ayrıca kendisi eskiden Apple Safari engine ekibinde çalışmıştı
    • Yine de bunun gerçekten yeni bir tarayıcıya dönüşüp dönüşmeyeceği hâlâ belirsiz
    • “Tedirgin edici” dedin ama tam olarak hangi açıdan tedirgin edici olduğunu merak ettim
  • “Anormal Rust kodu ama sonra toparlarız” sözü, sanki bir yeniden yazım daha gelecekmiş gibi hissettiriyor ve bu endişe verici
    Startup’ların dil değiştirmesi çoğu zaman tehlike işareti gibi görünür

    • Yine de C++ ve Rust’ın ikisi de çok paradigmalı diller, bu yüzden yapıyı benzer biçimde taşımak mümkün
    • Joel on Software’in anlattığı “yeniden yazım tuzağı” aklıma geliyor
      Yeni sürüm geliştirme ile mevcut özellik geliştirme paralel yürürse bir hız yarışı başlıyor ve yeni sürüm yetişemeyebiliyor
    • Ama Ladybird bir startup değil, açık bir proje; o yüzden birebir karşılaştırma doğru olmayabilir
      Linux, PHP ve musl libc de birkaç kez tam yeniden yazım süreçlerinden geçti
    • Ben olsam böyle bir durumda Firefox kullanmaya devam ederdim
    • LLM ile haftalarca port yapmak biraz garip bir tercih gibi görünüyor
  • AI artık yaygınlaştığı için “yeni bir dile tamamen yeniden yazım” hesabı tamamen değişti
    Özellikle bir test suite varsa risk ciddi biçimde azalıyor
    Testlerin önemi artık 10 kat artmış durumda

    • Ben de kişisel projelerde AI ile Python CLI kütüphaneleri yaptım
      Streamlit, Shiny, Dash gibi farklı UI’leri çok hızlı deneyebildiğim için prototipleme eğlenceli hale geliyor
    • Uzun vadede AI geliştikçe programlama dilinin kendisinin anlamı azalacak gibi geliyor
      Şimdiden bazı projelerde low-code + agent birleşimi yeterli oluyor
  • “Kod review’ü AI’ya bıraktık” kısmı kulağa tedirgin edici geliyor
    Modellerin mantıksal hataları yakalamada sınırları var

    • Yine de sonuçta 65 bin testte 0 regression + aynı çıktı sağlandıysa bunu tamamen görmezden gelmek de zor
      Ama asıl mesele, daha sonra sözü edilen “cleanup” gerçekten yapılacak mı
    • İnsan reviewer’lar da kusursuz değil. Farklı açılardan review yapılırsa AI da insan da farklı hata türlerini yakalayabilir
    • Bu tür şeyleri asıl doğrulaması gereken alan test suite tarafı
    • Ama AI’nin ürettiği standart dışı Rust kodu ile uğraşmak istemeyen insanlar da var
      AI koduna bağımlı oldukça AI bağımlılığı artan bir kısır döngüye dönüşebilir
  • Projenin C++ ve Rust’ı paralel geliştirmesi verimsiz görünüyor
    Keşke tek bir bellek güvenli dilde birleşseler diye düşünüyorum

    • Ama Firefox örneğinde olduğu gibi karma codebase gayet mümkün
      Her bileşen tek bir dille yazıldığı sürece sorun olmaz
    • Tam geçiş denemek büyük momentum kaybı yaratabilir ve proje durma noktasına gelebilir
    • C++’ın katı bir subset’i kullanılırsa bellek güvenliği de sağlanabilir
  • Andreas’ın 2024’te Swift’i benimserken Rust hakkında attığı tweet’ler var
    Rust’ın kısa ömürlü çalışan programlar için harika olduğunu ama karmaşık nesne grafikleri taşıyan uzun ömürlü programlarda rahatsız edici olduğunu söylemişti
    Ayrıca topluluğun toksik olduğunu da eklemişti
    İlgili tweet bağlantısı

    • Fikrini değiştirmiş olabilir mi? Belki de en baştan C++’ı değiştirmeye gerek yoktu
    • Rust topluluğundaki dışlayıcı atmosfer eleştirisine katılıyorum
    • Belki de sponsor baskısıyla AI destekli Rust dönüşümü yapılıyordur
  • Standart dışı Rust kodunun ileride teknik borç olarak kalıp kalmayacağını merak ediyorum

    • Risk en çok cleanup aşamasında. C++ tarzı pointer kalıpları Rust’ın ownership kurallarıyla çatışabilir
      Servo projesi de benzer sorunlar yaşadı ama süreç içinde potansiyel bug’ları da yakalayabildi
    • Sorun C++’ın kendisi değildi; Rust’a geçişin sebebi bellek güvenliği idi
    • Andreas daha önce de JS runtime’daki GC güvenliği sorunlarından söz edip daha güvenli bir dil istediğini söylemişti
      Rust’a geçiş bu felsefeyle uyumlu, olgun bir tercih gibi görünüyor