Bun’ın Rust ile yeniden yazımı: “Kod tabanı temel `miri` denetiminden geçemiyor ve safe Rust içinde UB’ye izin veriyor”

• Bu issue şu anda Open durumda; tartışma konu dışına çıktığı için kilitlenmiş ve collaborator’larla sınırlandırılmış durumda, ayrıca ilgili düzeltmeler olarak #30728 ve #30876 bağlanmış durumda
• Bildirimi yapan kişi, PathString::init ile oluşturulan bir değerde, kaynak Box drop edildikten sonra bile slice() çağrılabildiğini ve bu nedenle Miri’nin dangling reference temelli Undefined Behavior raporladığını ortaya koyuyor
• Yeniden üretim kodu, Box::new(*b"Hello World") ile oluşturulan tamponu PathString::init(&*test) içine verip ardından drop(test) sonrasında init.slice() çağırma şeklindeydi; Miri ise core::slice::from_raw_parts noktasında hata veriyordu
• robobun, sorunun yeniden üretildiğini doğrulayarak PathString::init fonksiyonunun safe bir fonksiyon olmasına rağmen slice lifetime bilgisini sildiğini ve böylece dangling &[u8] oluşturabildiğini özetledi
• Bağlı #30728, PathString::init ile dir_iterator::next() içindeki paralel açığı unsafe fn haline getirme ve yaklaşık 70 çağrı noktasına backing allocation’ı açıkça belirten SAFETY yorumları ekleme yönünde ilerliyor
• Aynı düzeltmenin, üç imzada unsafe anahtar sözcüğünün gerekli olmasını zorunlu kılan compile_fail doctest ile resolver’daki readdir-error fd leak düzeltmesini de içerdiği belirtiliyor
• AwesomeQubic ayrıca PathString::init fonksiyonunun provenance bilgisini de sildiğini ve MIRIFLAGS=-Zmiri-strict-provenance altında da başarısız olduğunu ekledi
• JavaDerg, init fonksiyonunun &[u8] için örtük bir lifetime aldığını, bunu unsafe işlemlerle sildiğini ve 'static gibi görünen bir Self döndürerek use-after-free ile invalid aliasing’e izin verdiğini açıkladı
• JavaDerg, Rust’un güvenlik modeli üzerinde UB’nin beklenmedik yerlerde sorun çıkarabileceğini, bu nedenle unsafe kullanımının genel olarak gözden geçirilmesi gerektiğini ve diğer dillerdeki bellek yönetimi yaklaşımını Rust’a 1:1 çevrmenin uygun olmadığını vurguladı
• robobun, ilgili commit’ler olarak PathString::init signature stays unsafe testini ve dir_iterator: make next() unsafe; audit call sites ekledi
• SimonReiff, depodaki Rust dosyalarında yorumlar hariç yapılan unsafe grep sonucunun 13255 satır olduğunu paylaşarak, bunun derhal geri alınması ve AI ile kod yazma politikasıyla süreçlerinin tartışılması gerektiğini savundu
• Jarred-Sumner, Rust portunun şu anda özgün Zig koduna olabildiğince yakın bir 1:1 mapping yaklaşımını başlangıç noktası olarak aldığını ve iyileştirmelerin sürdüğünü belirterek, Rust kodundaki hataların veya unsound davranışların yeni issue’larla bildirilmeye devam edilmesini istedi

[GN⁺]

Hacker News yorumları

• Bun’a ilk ilgim, Zig ile yazılmış olmasıydı; Zig’e de Andrew Kelley’nin kararlarına ve zevkine güvendiğim için çekilmiştim
  Sonrasında Bun’u daha ilgi çekici bulmamın nedenleri de sonuçta saygı duyabileceğim tercihler olmasıydı; Anthropic satın alımı sonrasında da temkinli biçimde iyimser kalmaya çalıştım
  Ama bu son hamle, güvenmesi zor bir karar gibi görünüyor; sorun Rust’ın kendisi değil, Anthropic Bun’ı böyle yönetecekse onu artık araç kutumun güvenilir bir parçası olarak görmek zor geliyor
  Sadece koda değil, arkasındaki düşünce tarzına da güvenmek gerekir; şu an ise Anthropic’in iç kullanımına özel bir araç gibi görünüyor

  • Bun gerçekten ilginç bir proje ama issue’larda görülen segmentation fault sayısı, onu ciddi üretim ortamlarında kullanmak için fazla kaygı vericiydi
    Bu yeni yönelim bunu düzeltmenin bir yolu olabilir, o yüzden izleyip görmek lazım
  • Bunu anlıyorum ama benim çıkış noktam epey farklı
    Eski bir Deno hayranı olarak Bun bana daha az iddialı bir Deno gibi görünüyordu ve Zig öğrenmek istemediğim için hobi olarak bile Bun’ın kendisine dokunma ihtimalim düşüktü
    Ama son birkaç yıldır runtime’a daha az bağlı şekilde oldukça büyük bir TypeScript kod tabanını sürdürmeye çalışırken Bun’a gittikçe daha sıcak bakmaya başladım; belli bir TypeScript runtime’ını gereksinim haline getirmek istemiyordum ama Bun, Deno gibi Postgres, SQLite, S3, websocket, yerel gizli bilgi saklama, bundling, derleme ve yüksek hız gibi nedenler sunmaya devam etti
    Şu anda birkaç API sunucusu ile frontend uygulama sunucusunu bun build --compile --bytecode tek bir çalıştırılabilir dosya olarak üretip neredeyse her yerde çalıştırıp dağıtıyorum
    Yine de bunun yaygın bir yaklaşım olduğunu düşünmüyorum ve bu LLM tabanlı port başarısız olursa Bun’la ilgili verdiğim bütün kararları pişmanlıkla anmak için tam uygun bir noktadayım
    Ama başarısız olmazsa ilginç. LLM’lerle nelerin mümkün olduğunu gösteren bir örnek olur ve bundan sonra Bun’ın Rust ile geliştirilecek olması benim açımdan bir artı
    Tersi durumda da bu bilgi olarak önemli. Bun, büyük TS/JS runtime’larından biri ve Anthropic’in devasa kaynakları, en yeni modellere erişimi ve fiilen sınırsız bütçesi var; onlar yapamıyorsa, bu şu aşamada gerçekten yapılamıyor demeye yakındır
  • Bun’ı Deno’dan daha çekici bulmanızın nedeni neydi, merak ediyorum

• Zig’i güvensiz Rust’a taşıyacaklardıysa neden bir çeviri aracı yazmadıklarını anlamıyorum
  Dil yapılarını bire bir eşleyip kod tabanındaki kalıpları hardcode ederek deterministik bir dönüşüm elde edebilirlerdi; bir arkadaşın dediği gibi “zig translate-c’yi c2rust’a bağlamak” gibi bir şey de mümkün olabilirdi
  Şu an ortaya çıkan sonuç, girdiden bile daha az güven veriyor. Girdi bellek güvenli değildi ama en azından insanlar tarafından yazılmıştı; çıktı ise hem bellek güvenli değil hem de vibe coding ile üretilmiş ve sanki bir insan tarafından düzgünce incelenmemiş gibi
  Böyle bir kullanım için ajan tarzı yapay zekayı bu kadar zorlamanın anlamını göremiyorum

  • c2rust çıktısını gördüyseniz bunu söylemek zor
    C’nin güvensiz pointer semantiğini, Rust’ın güvensiz fonksiyon kütüphanesiyle taklit ediyor; sonuç gerçekten korkunç oluyor
    Birkaç yıl önce OpenJPEG hatalarına bakarken birisi c2rust ile dönüştürmeyi denemişti ve ortaya çıkan güvensiz Rust kodu da C kodunun çöktüğü aynı yerde segmentation fault veriyordu
    Uyumlu olabilir ama güvenli değil
    Buradaki esas ders, string işleme işlerini C ya da güvensiz Rust ile yapmamak gerektiği. Bu iş için hiç uygun araçlar değiller
  • Yaptılar. Çok dinamik bir çeviri aracı
  • “zig translate-c’yi c2rust’a bağlamak yeterli olur” fikri sanıldığı gibi çalışmaz
    Bu tür araçlar çok hatalıdır ve kodu aşırı ayrıntılı, akıl yürütmesi zor bir hale getirir
    Küçük uygulamalarda iş görebilir ama tam bir yeniden yazım için uygun değildir
  • Ben de başka bir başlıkta neredeyse aynı şeyi söyledim ama yazılımı nasıl üretmek gerektiği konusunda biraz farklı düşünüyorum
    Zig’i Rust’a çevirmektense, statik Python ile bir JPEG ayrıştırıcısı yazıp sonra bunu her dilin kendi deyimlerine uygun yapılarla Zig ve Rust’a indirmek daha iyi olur diye düşünüyorum
    Bunun için böyle bir amaca uygun bir Python lehçesi ayrıştırıcısı yaptım ve çoğu Python koduyla uyumluluğu korurken çeviriyi kolaylaştıran bazı Rust/Zig özelliklerini de kabul etmeyi amaçlıyorum
    JPEG ayrıştırıcısı da örnek varlıklar arasında yer alıyor
    https://github.com/py2many/static-python-skill
    https://github.com/py2many/spy-ast
  • Bir kod tabanını başka bir dile port etmenin doğru yolu, sözdizim ağacını ayrıştırıp üzerine deterministik ve doğrulanmış dönüşümler uygulamaktır

• Bu issue yanlış anlamaya açık
  Sorun, miri’nin yakalayabildiği tanımsız davranışın varlığı değil; güvenli koddan tanımsız davranış üretilebilen API’lerin açığa çıkarılmış olması. miri de bunu ancak bunu kanıtlayan bir test yazıldığında yakalar
  Güvensiz bir dilden ilk port aşamasında bunun olması tümüyle mantıksız sayılmaz
  Görünüşe göre Bun ekibi de sonradan güvensiz kodu saran fonksiyonların doğru olup olmadığını kontrol etmeye devam ediyor
  Port aşamasında bazı güvensiz fonksiyonları geçici olarak yanlış biçimde güvenli işaretlemek tek başına çok büyük bir sorun değil ama bunu bu halde ana depoya birleştirmiş olmaları biraz tuhaf
  Asıl sorun, bu durumdaki kodun yayımlanması olur
  Hayal kırıklığı yaratan şey, testleri hemen miri ile çalıştıracak şekilde ayarlamamış olmaları. Çünkü LLM’ler iyi testlere iyi tepki veriyor
  Bunu bu GitHub issue’su yüzünden değil, başka bir testin [1] miri’nin yakalayacağı tanımsız davranışı gerçekten tetiklemesi nedeniyle söylüyorum. Ancak o testin hedeflediği kod hiçbir yerde kullanılmıyor gibi göründüğünden pratik etkisi büyük olmayabilir
  Portun başındalar; bunu sonra düzeltebilirler, hatta gerçekten gerekmeyen güvensiz kodları da kaldırabilirler
  [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - İlk mutable referanstan türetilen pointer’lar, aynı nesneye yeni mutable referanslar oluşturulunca geçersiz hale geliyor. C açısından bakarsanız “mutable referans”ı, “önemsiz değişikliklerin yapıldığı restrict referansı” gibi düşünebilirsiniz
  Doğru yapmak için tüm pointer’ları aynı mutable referanstan türetmek gerekirdi; sadece bunu yapmamışlar
  GitHub’a akın edip mesaj yağdırmak, insanların kamusal alanda çalışma ihtimalini azaltır. Umarım bu yapılmaz
  Ayrıca değerlendirme için yayımlanabilir hale gelene kadar beklemek daha iyi olur. Devam eden bir çalışmayı bu aşamada yargılamak ne adil ne de pek ilginç

  • Bir proje ilk kez 1.0 sürümüne ulaştığında birçok kişi main branch’inin her zaman çalışmasını bekler
    Sonuçta CI/CD, neredeyse her commit’in çalışır durumda olması varsayımına dayanır
    Tümden yeniden yazım gibi çalışmayan, sürmekte olan işler branch’lerde yapılmalı
    Böylece güvenlik düzeltmeleri gibi işler gerektiğinde de çalışan bir main korunabilir

• Bu sonuca şaşırmadım çünkü istenen şey neredeyse tamamen bire bir porttu
  Önce Bun’ı daha güçlü bir tip sistemine sahip bir dile taşıyıp, sonra o tip sistemini kaldıraç olarak kullanarak iyileştirmelere devam etmek daha iyi bir yol değil mi diye düşünülebilir
  İlk adımdan kusursuzluk beklemekten daha mantıklı görünüyor

  • Aslında yaptıkları şey tam da bu
    Gelen issue’ları tek tek ele alıyorlar
  • Prompt’a sadece “tanımsız davranış olmasın” diye eklemek yeterli olur
  • Artık miri benzeri araçlarla yeniden yazımı zorlayıp Claude Code’un otomatik iyileştirme yapmasını sağlayabilirler gibi görünüyor
  • Çoğu bire bir çevrilmiş, bir kısmı güvensiz Rust olan kodda tanımsız davranış çıkması şaşırtıcı değil
    Ama Rust kodunun API’lerinin unsafe olarak işaretlenmemesine rağmen tanımsız davranış üretebilmesi hayal kırıklığı yaratıyor
    Böyle bir çeviri yapacak olsaydım daha muhafazakâr davranıp ilk aşamada hepsini ya da çoğunu unsafe diye işaretlerdim
    Sonra parçaları tek tek güvenlik açısından doğrulamak mümkün olurdu

• Dürüst olmak gerekirse, bunu bir haftada tamamen çalışır hale getirdiklerini söylemeleri beni biraz şaşırttı
  Benim yan projem de benzer ölçüde iddialı bir şey olan https://tsz.dev ama başarılı olduğunu iddia edemem
  Sürekli test ekleyip davranışları doğruluyorum ve TypeScript’in kendi testlerinin tümünü geçtikten sonra bile beklendiği gibi hata bulmaya devam ediyorum
  tsc davranışıyla bire bir uyumlu olma çıtası gerçekten çok yüksek
  https://github.com/type-challenges/type-challenges
  LLM’lerle çok sayıda kod yazılmasına karşı değilim ama artık kodu bu hızda üretebiliyorken doğrulamanın 100 kat daha sağlam olması gerekiyor

  • “Deney” kapsamında bir haftada, muhtemelen neredeyse hiç review almamış milyon satırlık kodu merge etmeleri sarsıcı
    Ajan kullanımına karşı değilim ama bunu aceleye getirip topluluğu bir anda şaşırtmak çok amatörce görünüyor
    Daha çok hevesli bir junior mühendisten beklenecek türden bir hareket
  • https://tsz.dev/sound-mode/
    Bu harika. TypeScript’in buna daha çok ihtiyacı var ve yeterince tanınırsa belki Microsoft bile benimser
    Yalnız buna sound mode demek konusunda dikkatli olmak gerekir gibi geliyor
    “Matematiksel anlamda bir soundness ispatı değildir ve üçüncü taraf .d.ts dosyalarını doğru hale getirmez” cümlesinde tamamen farklı iki şey iç içe geçmiş
    Birincisi, soundness matematiksel bir kavramdır. Bir şey sound ise gerçekten sound’dur; yani ayrıntıları tek tek elle kontrol etmek zorunda kalmadan derleyiciye güvenebilirsiniz
    Uygulama hataları yüzünden yanlış davranabilir ama bunlar düzeltilebilir; soundness ise spesifikasyonun ya da tip sisteminin kendisinde teorik olarak yanlış olabilecek bir boşluk olmaması demektir
    İkincisi, gerçek dünyadaki bir dilde insanların doğru kullanacağı varsayılan, denetlenmeyen özelliklerin bulunması tamamen normal ve beklenebilir bir şeydir. Haskell’deki unsafeCoerce ya da Java’daki sun.misc.unsafe gibi
    Asıl sorun, böyle özellikler kullanılmadığı halde tip sisteminin yine de kırılmasıdır
  • Buna çalışıyor demek biraz abartı
    Koda sadece birkaç dakika baktım ama optimizasyonlar açıldığında ciddi biçimde bozulacak gibi duruyor
  • Muhtemelen bunu aylar boyunca planlayıp denediler
    Büyük mevcut test paketinin yanı sıra ajanları paralelleştiren araçlar ve fiilen sınırsız token bütçeleri de vardı; o yüzden fazla umutsuz olmaya gerek yok

• Dikkat ve medya hakkında düşüncelerimi ciddi şekilde değiştiren bir kitap vardı [0]
  Kitabın kendisi çok iyi değil ama burada ilgili olan noktayı iyi yakalıyor
  Büyük ve gösterişli bir duyurunun erişimiyle, örneğin “Bun birkaç hafta içinde bellek güvenli Rust ile yeniden yazıldı” mesajının erişimi arasında; bir de düzeltmelerin erişimi, örneğin eski bir makaledeki dipnot ya da bir GitHub issue’sunun erişimi arasında devasa bir asimetri var
  Bu asimetriyi marketing ve PR sektörü çok iyi anlıyor ve aktif biçimde kullanıyor
  [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

  • Bu başlıktaki havaya bakınca, koddaki her türlü eleştiriyi bulup olabildiğince büyütmeye çalışan çok kişi varmış gibi geliyor
    Şu an için bunların çoğu oldukça yüzeysel görünüyor
    Büyük bir LLM destekli portu merge etmek kesinlikle çok cüretkâr bir karar ama ortaya çıkan kod hakkında insanların işaret ettiği şeylerin çoğu, başka devam eden portlardan daha kötüymüş gibi gelmiyor
    Bulunan her issue aşırı büyütülüyor
  • Gerçekten bellek güvenli olduğunu iddia edip etmediklerinden bile emin değilim
    Bu konudaki her tartışmada, vibe coding ile yazılmış kod tabanının denetlenmemiş unsafe bloklarla patlamaya hazır olduğunu ve Rust’ı anlamayan insanların üstünkörü review yaptığını söyleyen onlarca yorum vardı
    Hatta sanki insanlar herhangi bir programlama dilini anlamak gerektiği fikrine bile öfkeleniyor gibiydi
  • “Yalan, gerçek daha ayakkabılarını giymeden dünyanın yarısını dolaşır” sözüyle anlatılan fikir bu mu acaba
  • Bunu sadece marketing ve PR değil, ana akım medya da yapıyor; önce saçmalığı yayıyor, sonra geri çekse bile kalıcı etkisinin sürdüğünü biliyor
    İnsanlar genelde ilk haberi ya da manşeti hatırlıyor, düzeltmeleri ise hiç görmüyor
  • Aslında tam ters yönde bir soruna değineceğinizi sanmıştım
    Port hâlâ sürüyor, yani ortada büyük ve gösterişli bir duyuru yok; henüz tamamlanmış ya da yayımlanmış da değil
    Benim gördüğüm gösterişli çıkışlar, devam eden koda yönelik vur-kaç tarzı alaylar ve sanki ekip bunu tamamlanmış ya da kusursuzmuş gibi sunmuş gibi bir ima yaratma çabaları
    Yeniden yazım, başlangıç noktası oluşturmak için yapılan bir kod çevirisiydi
    Bun ekibi kodun artık bellek güvenli olduğunu büyük laflarla duyurmadı; bunun bir başlangıç noktası olduğunu açıkça söyledi
    Yani anında kusursuz olmasını ve özgün Zig kodundaki tüm bellek sorunlarını çözmesini beklemek, Bun ekibinin gerçek açıklamalarıyla değil, hayali bir açıklamayla kavga etmek olur
    Bu bellek sorunlarının özgün kod tabanında da bulunup bulunmadığını eşleştiren biri oldu mu, onu da merak ediyorum

• Bu tür hatalar beklenebilirdi
  Kararlılık isteyenler için kararlı sürümü Zig olarak bıraktılar ve sonuçta bu hatalar düzeltilir diye düşünüyorum

  • Bu hatalar gayet önlenebilirdi
    Rust ekosisteminde bu tür hataları yakalayan iyi bilinen araçlar var ve unsafe bloklarındaki hatalardan doğan tüm tanımsız davranışları yakalamasa bile bunları çalıştırmak iyi bir pratik sayılıyor

• Beni en çok kaygılandıran şey meta tartışma
  Başta bu GitHub issue’sunu konu dışı diyerek kapatan maintainers’a eleştirel bakmıştım
  Ama GitHub arayüzü, bilgi değeri hiç olmayan mesaj yığınlarını otomatik olarak topluca daraltıyordu ve bu mesajlar sanki forumlardan ya da topluluk Discord’larından akın etmiş gibiydi
  Bu, herkesi kaybettiren bir duruma sürüklüyor
  İlgili toplulukların çoğunun önemseyeceği ciddi bir sorun keşfeden birinin, bunu mümkün olduğunca geniş duyurmak için yeterli nedeni vardır
  Bu, son değişikliklere ilişkin maddi bir taleptir; üsluba itiraz etmek meselenin olgusal niteliğini ortadan kaldırmaz
  Sorun şu ki, ek ilgi kelimenin tam anlamıyla tartışmayı öldürüyor
  Maintainer tarafında daha duygusal ya da AI psikozuna yakın kararlar veren kişilere de kalkan olabiliyor
  Eleştiriyi engelleyip görmezden gelen kuşatma psikolojisine sahip projeler çok hızlı raydan çıkabilir
  Öte yandan maintainers’ı AI kaynaklı kaygı ve patolojiden koruyamayan projelerde de maintainer tükenmişliği kaçınılmazdır

• Bu Bun yeniden yazımı bana Mythos pazarlaması için potansiyel bir etkinlik gibi geliyor

  • Şimdiye kadar ne Bun ekibinden ne de Anthropic’ten biri bunu, daha iyi derleyici güvencelerine sahip ve daha bellek güvenli bir dile geçiş olmasının ötesinde pazarlama malzemesi yapmadı
    Şu ana kadarki ilgi ve tanıtımın çoğu, esas olarak AI karşıtı insanların olumsuz tepkilerinden geldi
    Bence Anthropic’in son dönemdeki bazı kararları nedeniyle şirketin kendisine yönelik olumsuz algının büyümesi de bununla epey ilişkili
  • Bu bana doğrudan kurumsal bir rug pull gibi geliyor
    Sanki tek öncelik Anthropic’in ihtiyaçları ve geri kalanın pek önemi yokmuş gibi
  • Yeniden yazımı, sınırsız token’a ne kadar para harcandığını bilmeden çalıştırıyorlar
    Sonra “Claude Code, Bun ekibinin 1 milyondan fazla satır Zig kodunu Rust’a yeniden yazmasına yardım etti” diye ortalığı ayağa kaldırıp blog yazısı yayımlıyorlar; VC’lerin ağzı sulanıyor
    Temel kontrollerden geçemiyor
    Mythos’un kod tabanını paramparça etmesine izin veriyorlar ve yine ne kadar para harcandığını bilmiyoruz
    Ayrı bir blog yazısı daha geliyor
    Dolandırıcılar ve saf insanlar alkışlayıp bunu “hezeyanlı anti-AI kalabalığına” karşı savunuyor
    VC’ler daha da heyecanlanıyor
    Para kazanma yöntemi bu
    Sonra konu dönüp dolaşıp yazılım mühendislerini de ortadan kaldırmak gerektiğine geliyor

• İçinde bir de başka bir güvensiz dil bağlaması bulunan güvensiz bir dil kod tabanında, neden bunun daha ilk anda kusursuz görüneceğini varsaydığımızı anlamıyorum