Bun’ın Rust’a yeniden yazımı hakkında düşüncelerim

 (en.liujiacai.net)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Bun’ın Rust’a yeniden yazımı, Zig ile oluşturulmuş mevcut mimariyi ve veri yapılarını koruyup daha ana akım bir teknoloji yığınına geçme kararı olarak görülebilir
  • Yeniden yazım PR’ı 6.755 commit büyüklüğündeydi; 8 Mayıs’ta açılıp 14 Mayıs’ta birleştirildi, bu da production düzeyindeki bir runtime değişikliği için inceleme derinliği konusunda soru işareti bırakıyor
  • Testlerin geçmesi yalnızca bilinen yolları doğrular; hata yolları, eşzamanlılık ve uç bellek koşulları gibi küresel değişmezleri garanti etmekte zorlanır
  • Asıl mesele Zig’in başarısızlığı değil, hızlı yayın yapmayı önceleyen Bun ekip kültürü ile manuel bellek yönetiminin maliyeti arasındaki yapısal uyumsuzluktur
  • Gerçek bahis Zig ve Rust arasında değil, yapay zekanın ürettiği ve yeterince incelenmemiş kodun uzun vadede bakımının yapılıp yapılamayacağı üzerinedir

Zig’in kurduğu Bun temeli

  • Bun’ın Rust’a yeniden yazım PR’ına bakmadan önce, Bun’ın bugünkü konumuna gelmesinde Zig’in rolü büyüktü
  • Jarred’in Zig’i seçme nedeni “havalı olması” değil, çöp toplayıcısız yüksek performanslı bir JS runtime’ını küçük bir ekiple hızlıca prototiplemeye uygun olmasıydı
  • Zig’in düşük sürtünmesi, doğrudan bellek manipülasyonu ve basit C birlikte çalışabilirliği, Bun’ın ilk performansını ve küçük ekip ölçeğini mümkün kıldı
  • Jarred’in “mimari değişmiyor, veri yapıları da değişmiyor” demesinden de anlaşıldığı gibi, Rust’a yeniden yazım Zig ile kurulmuş iskeleti devralan bir yapıya daha yakın
  • Zig ile temeli atıp, ürünü piyasaya sürüp, yatırım alıp ardından şirket satın alındıktan ve büyüdükten sonra daha ana akım bir teknoloji yığınına geçmek normal bir iş kararı olarak görülebilir
  • Ancak bunu Zig’in kendisinin yetersizliği gibi sunmak zor

6 günde birleştirilen devasa yeniden yazımın riski

  • Yeniden yazım PR’ı 6.755 commit, claude/phase-a-port dal adı ve 8 Mayıs’ta açılıp 14 Mayıs’ta birleştirilmesiyle dikkat çekiyor
  • Esas sorun, production düzeyindeki bir JS runtime’ının tam yeniden yazımının yalnızca 6 günde birleştirilmiş olması
  • Yazılım mühendisliğinin temel ilkelerinden biri, “anlaşılmayan kod production’da çalıştırılmamalıdır” ilkesidir
  • Bunun nedeni kodda mutlaka hata olması değil, hata çıktığında nereden başlanacağını bilememek; bu da bakım yapılabilirliğin taban çizgisini belirler
  • PR’ın reviewer listesinde coderabbitai[bot] ve claude[bot] vardı; tek insan reviewer olan alii ise “Awaiting requested review” durumundaydı
  • Claude’un yazıp Claude’un incelediği kapalı döngü, mantıksal olarak imkânsız olmasa da sonuç olarak tüm kod tabanının bir insan tarafından gerçekten baştan sona okunmadığı anlamına geliyor

Testlerin garanti edemediği şeyler

  • Test paketinin tüm platformlarda geçmesi bile yalnızca bilinen davranışların ve bilinen yolların doğruluğunu doğrular
  • Test paketi şu alanlarda yeterli güvence vermekte zorlanır
    • Hata yollarının doğru işlenip işlenmediği
    • Stres altındaki sınır koşullarında nasıl davranıldığı
    • Eşzamanlı durumlarda durum tutarlılığının korunup korunmadığı
    • Uç koşullarda bellek modelinin amaçla örtüşüp örtüşmediği
  • Jarred’in de JS sınırına yeniden girildiğinde ortaya çıkan bellek sorunlarını Rust derleyicisinin çözemeyeceğini ve burada hâlâ insana ihtiyaç olduğunu kabul ettiği aktarılıyor
  • Sorun, insana ihtiyaç duyulan o kısmın insan tarafından incelenmemiş olması
  • Yapay zekanın kod çevirisi, her fonksiyonun kaynakla izole biçimde aynı davranmasını hedefleyen yerel anlamsal eşdeğerliğe daha yakındır
  • Fonksiyonlar arasındaki küresel değişmezler ve testlere yazılmayıp yalnızca özgün yazarın zihninde bulunan tasarım kısıtları, yalnızca yapay zeka çevirisiyle güvence altına alınamaz
  • Bu tür kısıtlar mevcut testlerde görünmeyip 6 ay sonra belirli bir production yükü altında açıklaması zor çökme sorunları olarak ortaya çıkabilir
  • Bu yalnızca Claude’un sorunu değil; yeterli inceleme olmadan çeviri yapan tüm araçlar ve insan programcılar için de geçerli
  • 6.755 commit ölçeğinde bu risk ciddi biçimde büyür

Satın alma sonrası değişen risk taşıyıcısı

  • İlk Bun, Jarred’in kendisine bahis oynadığı bir projeydi; Zig kullanımı, hızlı iterasyon ve teknik borcun kabulü, riski bizzat üstlenen bir startup mantığı olarak görülebilir
  • Ancak Bun büyük bir şirket tarafından satın alındıktan ve gerçek production sistemlerinde kullanılan bir kullanıcı tabanına ulaştıktan sonra, yeniden yazımın riskini taşıyan taraf Jarred değil, production’da Bun çalıştıran mühendisler ve onların arkasındaki kullanıcılar oldu
  • Jarred, ilgili sürümün hâlâ canary aşamasında olduğunu ve resmi sürümden önce optimizasyon ile temizlik işlerinin kaldığını söylüyor
  • Canary bir savunma hattıdır ama insan incelemesinin yerine geçmez
  • Optimizasyon ve temizlik kod kalitesiyle ilgilidir; bakımcıların kodu anlayıp anlamadığı sorununu çözmez
  • Ekipte hiç kimsenin tamamını tam olarak okumadığı bir kod tabanı, testler kapsamlı olsa ya da canary süresi uzun sürse bile bakımcılar için iç durumu bir kara kutu olarak bırakır
  • Bu sorun, ileride ciddi hataların ayıklandığı sahada gerçek acı olarak ortaya çıkabilir

Zig teşhisindeki hata

  • Jarred’in daha önce sunduğu gerekçe, Zig kod tabanında çok sayıda use-after-free, double-free ve hata yollarında bellek sızıntısı bulunduğuydu
  • Bu teşhis kendi içinde doğru olabilir, ancak buradan “Zig işe yaramıyor” sonucuna varmak zor
  • Daha doğru teşhis, hızlı iterasyonu önceleyen ticari bir projede manuel bellek yönetiminin bilişsel maliyetinin ekibin bütçesini aşmış olmasıdır
  • Bu, Zig’in hatası değil; Zig’in tasarım hedefleri ile Bun’ın iş modeli arasındaki yapısal uyumsuzluk olarak görülebilir
  • Zig’in hedef kullanıcısı, ne yaptığını bilen ve nihai kontrol için bu bedeli ödemeye istekli sistem programcılarıdır
  • TigerBeetle, Zig ile neredeyse bellek hatasız bir veritabanı yazdı; bunun nedeni ekip kültürüyle projenin niteliğinin Zig felsefesiyle uyumlu olmasıydı
  • Bun ekip kültürü hızlı iterasyon, hızlı yayın ve hızlı hata düzeltmeye daha yakın; bu da Zig’in gerektirdiği sıkı bellek disipliniyle temelden gerilim içindedir
  • “Ekibimiz bu araçla sık sık hata yapıyor” ifadesini “bu araç uygun değil” diye yorumlamak bir atıf hatasına yakındır
  • Kullanılan benzetmeye göre, çekicin uymaması çekicin kendisinin suçlu olduğu anlamına gelmez

Kısa vadeli görünüm ve uzun vadeli risk

  • Kısa vadede yeniden yazılmış sürümün büyük ölçüde sorunsuz olması muhtemeldir
  • Ana yollar testlerle kapsanır, canary aşamasında bariz sorunlar görünür ve Rust derleyicisinin sağladığı güvenceler bellek hatalarının bir türünü ortadan kaldırır
  • Yüzeyde her şey normal görünebilir
  • Uzun vadede ise bir insanın baştan sona okumadığı 6.755 commit, yapısal bir risk olarak kalır
  • 6 ay sonra tuhaf bir eşzamanlılık hatası ortaya çıkarsa veya belirli bir yük altında sınır koşulları beklenmedik davranış üretirse, debug eden mühendis gerçekten kimsenin tam olarak anlamadığı bir sistemle karşı karşıya kalır
  • Burada “hiç anlaşılmamış sistem” ifadesi, hata olmadığı anlamına değil; hata çıktığında nedenini kimsenin bilmediği anlamına gelir
  • Bu yeniden yazımın gerçek teknik bahsi Zig ve Rust arasında değil, yapay zekanın ürettiği ve incelenmemiş kodun production ortamında uzun vadeli bakımının mümkün olup olmadığı üzerinedir
  • Bu soru, “tüm testler geçiyor” ifadesinden daha karmaşık ve “Rust’ın bellek güvenliği”nden daha derin bir meseledir
  • Sonuç, “temeli Zig attı, binayı Claude dikti, insan reviewer ise hâlâ yolda” benzetmesiyle özetleniyor
  • Bu binanın ne kadar süre yaşanabilir kalacağı, ilk sızıntı ortaya çıktığında birilerinin planları okuyup okuyamayacağına bağlı

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Lobste.rs yorumları

  • “Bun’ı Rust ile yeniden yazalım” meselesini tartışmadan önce, Bun’ın bugünkü noktaya gelmesinin Zig sayesinde olduğunu söylemek gerekir
    Bun’ın yaratıcısı Jarred de bunu söylüyor. Zig’in Bun’ı mümkün kıldığını ve Oakland’daki kötü kokulu bir odada bir yıl boyunca tek başına kodlanan projenin JavaScript ekosistemindeki en yaygın kullanılan araçlardan birine dönüşmesinde Zig’in payının büyük olduğunu söylüyor
    Ayrıca Zig’in harika bir dil olduğunu ve Bun’ın başarısının ona çok şey borçlu olduğunu, ancak Ghostty ya da Tigerbeetle gibi diğer projelerin Bun’ın yaşadığı kararlılık sorunlarını yaşamadığını da söylüyor

    • “Ghostty ya da Tigerbeetle gibi diğer projeler Bun’ın yaşadığı kararlılık sorunlarını yaşamadıysa”, nedenini sormak gerekir
      Çünkü genelde veritabanları, dil runtime’larına göre çok daha büyük kararlılık zorlukları taşır

  • Bu yazı ciddi biçimde LLM tarafından yazılmış gibi kokuyor

  • Eğer Zig’in hedef kitlesi “ne yaptığını bilen ve en üst düzey kontrol için bedel ödemeye hazır sistem programcıları” ise, Rust ve Swift’ten sonra ortaya çıkan diller bağlamında yeniden sahneye çıkan bir tür C/C++ tarzı aşırı özgüven gibi görünüyor
    Jarred taşınma gerekçesi olarak “Zig kod tabanında use-after-free, double free ve hata yollarında bellek sızıntısı çok fazlaydı” dediyse, bu da LLM’e bellek güvenliği hatalarını hevesle aratmanın bellek güvenli olmayan bir dili fiilen güvenli kılıp kılamayacağı konusunda bir veri noktası olur
    Burada LLM şirketlerinin kendisi bile o yolu seçmedi

  • “Kod Claude tarafından yazıldı, Claude tarafından incelendi; yani kapalı döngü mantıksal olarak imkânsız değil ama bu, hiçbir insanın bu kod tabanının tamamını gerçekten okumadığı anlamına geliyor” sözü açıkça doğru görünmüyor
    İnsan tarafından yazılmış bir Zig kod tabanı Rust’a mekanik olarak çevrildiyse, orijinal kodu anlayan biri yeni kodu da anlayabilir. Sonuçta APL’ye taşınmıyor; ikisi de C sözdizimi geleneğinden gelen prosedürel diller
    LLM’leri gözetimsiz çalıştırmanın ileride kodu giderek insan sezgisinden uzaklaştırabileceği argümanı açık, ama şu andaki kod tabanı milyon satırlık bir JavaScript runtime’ı ve tek ikili dosyalı çok amaçlı bir araç için hâlâ anlaşılabilir görünüyor
    “AI sadece fonksiyon düzeyinde yerel anlamsal eşdeğerliği tutturur, fonksiyonlar arası küresel invariant’ları anlayamaz” cümlesi hem LLM lehine hem de LLM aleyhine tuhaf
    LLM’ler her fonksiyonun kaynakla aynı davrandığını garanti edecek kadar deterministik değil. Böyle bir garanti için c2rust gibi araçlar gerekir. LLM’ler kaynağa benzeyen kod üretebilir, ama ((abc & 45) << 3) == 360 ifadesini ((abc & 45) << 30) == 360 yapmasını engelleyen şey derleyici, test paketi ve belki LLM tabanlı code review’un olasılıksal tespitidir
    Tersine, c2rust gibi her fonksiyonun eşdeğerliğini garanti ederken LLM gibi yorumları ve yapıyı da koruyan bir çevirmen olsaydı, bu kusursuz bir çevirmen olurdu ve milyon satırlık kod tabanları otomatik taşınabilirdi. Derleyiciler de bu tür özel durumların bir örneği sayılabilir; Clang hatasız olmasa da insanların güveneceği kadar yaklaşmıştır. Eğer LLM’ler Zig ya da C++’ı Rust’a Clang düzeyinde güvenilirlikle çevirebilseydi, Chrome bu ayın sonunda saf Rust olurdu
    Ayrıca fonksiyonlar arası invariant’ları kodlamak zaten tip sisteminin özüdür. Bun’ı Rust ile yeniden yazma nedenlerinden biri de Rust’ın tip sisteminin karmaşık invariant’ları daha iyi ifade edebilmesidir. Anthropic her şeyi assembly’ye derleyip sonra kaynak kodu yakmış da değil

    • “İnsan tarafından yazılmış bir Zig kod tabanı Rust’a mekanik olarak çevrildiyse, orijinal kodu anlayan kişi yeni kodu da anlayabilir” cümlesi release fast modunda toptan optimize edilip yok olur gibi :^)
      Bun, Rust portundan çok önce de vibe coding ile geliştiriliyordu. AI’ı oldukça erken benimsedi ve Anthropic satın alımından sonra neredeyse tüm commit’ler botlar tarafından yazılmaya başladı. Jarred da hafta sonu boyunca AI’a özellik yazdırıp bir sürü özellik eklediğini tweet’lemişti
    • Bun’ın uzun zamandır insan yazımı bir kod tabanı olmadığına dair Kristoff’un işareti ayrı bir nokta, ama burada Claude portunun mekanik bir çeviri olduğu varsayılıyor gibi; gerçekte öyle görünmüyor
      HTML Parsers in Portland, Python HTML parser’ının çeşitli portlarını incelerken çekirdek algoritmalardan birinin her portta çok farklı şekilde uygulandığını gösteriyor. Her durumda mekanik port mümkündü, ama pratikte öyle yapılmadı
      Elbette bu yılın başındaki bir örnek ve süreç de farklıydı, ama port sonrası Bun kod tabanında gördüğüm bazı parçalar da benzer sorunlar yaşıyor gibi duruyor
    • “İnsan tarafından yazılmış bir Zig kod tabanı Rust’a mekanik olarak çevrildiyse, orijinal kodu anlayan kişi yeni kodu da anlayabilir” ifadesi kendi başına doğru
      Ama “LLM’ler her fonksiyonun kaynakla aynı davrandığını garanti edecek kadar deterministik değil” noktası, sonunda insanların kod tabanının tamamını gerçekten okumadığı sonucuna götürüyor

  • “Tüm testler geçiyor” ifadesine bir örnek: https://github.com/oven-sh/bun/…

    • O commit’teki değişiklik nihai diff’in içinde değil ve bunu doğrudan bakarak da kolayca görmek mümkün
      Başka forumlarda da birkaç kişinin aynı commit’e link verdiğini görünce, belli ki bir yerlerde bu bağlantıyı görüp beklentilerine uyduğunu düşünmüşler ama gerçekten ilgili olup olmadığını kontrol etmemişler. Kendimize daha yüksek bir standart uygulamamız gerektiğini düşünüyorum
    • İyi ya da kötü, o commit insan tarafından yazılmış daha önceki bir commit’i kısmen geri alan insan yazımı bir commit
      İlk commit: “await process exit / JSON-parse-retry instead of fixed sleeps”
      Geri alma: “test: revert proc.exited change in spawn.test.ts, keep isDebug iteration count”

  • Son zamanlarda “anlamadığın kodu production’da çalıştırmamalısın” ilkesini çok düşünüyorum
    Kariyerimde epey ilerledim ama bilerek yöneticiliğe geçmedim ve programlama kariyerim de giderek stack’in daha alt katmanlarına inmeye yöneldi. Çünkü programın kendisini derinlemesine anlamayı seviyorum. Özellik çıkarmak ve kullanıcıların hayatını iyileştirmek elbette çok önemli, ama programlamadaki büyük içsel ödüllerden biri de gerçek sistemler hakkında doğru şeyler öğreniyormuş hissi
    Benim gibi biri için bir insanın bir programın her satırını anlaması gerektiği neredeyse aksiyom gibi geliyor. Ama organizasyon şemasında benim yöneticim, benim bakımını yaptığım programlardan sorumlu. Harika bir yönetici ve mikroyönetim yapmıyor, bu yüzden ekibin çıkardığı yazılımın her satırını doğal olarak anlamıyor. Hatta kodu neredeyse hiç okuyup okumadığını bile bilmiyorum. O zaman bu ilkeyi ihlal ediyor sayılır
    “Astımın yazdığı ve benim anlamadığım kod” ile “AI’ımın yazdığı ve benim anlamadığım kod” arasında anlamlı bir fark olup olmadığını düşünüyorum
    1 numara kabul edilebilir geliyor ama 2 numara rahatsız edici. Fark sadece o kod için sorumluluk alan bir insanın varlığı mı? Yani suçlayabileceğin birinin olması mı? Bunun bende yarattığı güçlü ahlaki hissi meşrulaştırmaya yetip yetmediğinden hâlâ emin değilim
    Bu güçlü duygunun iyi mühendislik için zorunlu olmaktan çok kişisel estetik meselesi olmasından endişe ediyorum. Herkesin zevki olabilir, ama mesele sadece buysa işin bu yönünün gelecekte daha az keyif vereceğini kabullenmem gerekecek. Sonunda yöneticiliğe itilmiş oluyorum, tek fark şu ki astlarım botlar

  • “Zig, küçük bir ekibin garbage collector ve ağır bir runtime olmadan yüksek performanslı bir JS runtime’ını hızlıca prototiplemesine olanak verdi” deniyor, ama diğer büyük runtime’lar olan Node ve Deno da aynı şeyi yapıyor
    İkisi de JS motorunu garbage collector’sız diller olan C++ ve Rust ile sarıyor. V8 ya da JSC’nin kendisinin gerçekten garbage collector ile dağıtılıp dağıtılmadığını bilmiyorum, ama bu ana mesele değil

  • Bun deposunun tamamı distopik hissettiriyor. Botlar birbiriyle konuşup saçma PR’lar üretiyor
    Örnek: https://github.com/oven-sh/bun/issues/30766

  • Bunun “tamamlandı” sayılacak hızda ilerlemesi gerçekten epey sarsıcı, ama yazının sağlam kanıt olmadan anlattığı gibi hareket halindeki bir tren kazası gibi de görünmüyor
    “6 ay sonra garip concurrency bug’ları ortaya çıkarsa ve belli yüklerde bir sınır durum anormal davranışı tetiklerse, debug eden mühendisler kimsenin gerçekten anlamadığı bir sistemle karşı karşıya kalacak” sözü tamamen spekülasyon; ortada sunulmuş bir olgu yok
    Dil portları LLM’lere uygun bir alan ve alttaki kod da birçok insan tarafından zaten anlaşılıyordu. Basit bir dil portunun neden bir anda teşhis edilebilirliği geri döndürülemez biçimde mahvedeceğini anlamıyorum