Bun'ın deneysel Rust yeniden yazımı, Linux x64 glibc üzerinde test uyumluluğunda %99,8'e ulaştı

• Bun'ın Rust ile yeniden yazılan sürümü, Linux x64 glibc ortamında mevcut test paketinin %99,8'ini geçti
• Kod tabanı "temelde aynı kod tabanı" ve Rust'a geçişle birlikte derleyici tip yaşam döngüsünü zorunlu kılıyor ve gerektiğinde yıkıcıların kullanılmasını mümkün kılıyor
• Güvensiz kısımlar Rust'ta unsafe ile daha açık hale geliyor ve bu da yeniden düzenlemeyi teşvik eden bir etki yaratıyor
• Yeniden yazımın nedeni, bellek sızıntıları, çökme ve kararlılık sorunları konusunda endişelenip bunları düzeltmeye çok fazla zaman harcamaktan bıkılmış olması ve dilin bunları engelleyecek daha güçlü araçlar sunmasının istenmesi
• Toplam ölçek 960.000 LOC'lik bir yeniden yazım olarak ifade edildi; Linux'ta test paketi geçiliyor ve yakında diğer platformlar da hedeflenecek

---

Rust yeniden yazımının durumu

• Bun'ın Rust ile yeniden yazılan sürümü, Linux x64 glibc ortamında mevcut test paketinin %99,8'ini geçti
• Kod tabanı "temelde aynı kod tabanı" ve Rust'a geçişle birlikte derleyici tiplerin yaşam döngüsünü zorunlu kılıyor ve gerektiğinde yıkıcıların kullanılmasını mümkün kılıyor
• Güvensiz kısımlar Rust'ta unsafe olarak daha net görünür hale geliyor ve bu da yeniden düzenlemeyi teşvik eden bir etki yaratıyor
• Yeniden yazımın arka planında, bellek sızıntıları, çökme ve kararlılık sorunları hakkında endişelenip bunları düzeltmeye çok fazla zaman harcamaktan bıkılması ve dilin bu tür sorunları önleyecek daha güçlü araçlar sunmasının istenmesi yer alıyor
• Toplam ölçek 960.000 LOC'lik bir yeniden yazım olarak ifade edildi; kod gerçekten çalışıyor, Linux'ta test paketini geçiyor ve yakında diğer platformlar da hedeflenecek

Gelecekte paylaşılacak içerikler ve derleme ile ilgili yanıtlar

• Bunun Bun için ne anlama geldiği, benchmark'lar, bellek kullanımı, gelecekteki bakım kolaylığı ve gerçek yeniden yazım süreci ayrı bir blog yazısında ele alınacak
• Yeniden yazım süreci basitçe "claude, rewrite bun in rust. make no mistakes" demekten ibaret değildi; sona kadar çalışan bir duruma ulaşmak için çalışmalar 6 gün önce başladı
• Bunun tamamen elle yapılmış olması halinde devasa bir iş yükü olacağı ifade edildi
• Derleme süresi, daha hızlı Zig derleyicisini kullanan mevcut Zig sürümüyle temelde benzer; upstream Zig derleyicisi kullanılmış olsaydı Rust portunun daha hızlı derleneceği belirtiliyor
• Performans ayrı bir blog yazısında ele alınacak
• libc'nin kendisini Rust sürümü olan frankenlibc ile değiştirme yönündeki bir sonraki adım hakkında ise, ondan önce libc'yi kendisinin yazacağı söylendi

[GN⁺]

Hacker News yorumları

• 4 gün önce de bununla ilgili bir şey vardı: https://news.ycombinator.com/item?id=48019226
  Bir Bun geliştiricisi bunun kendi branch'i olduğunu, o zamanki başlığın çalışmayan kod için aşırı tepki olduğunu, yeniden yazımın henüz kesinleşmediğini ve kodun tamamen çöpe gitme ihtimalinin yüksek olduğunu söylemişti
  Çalışan sürümün nasıl göründüğünü, performansın ve bakım yapılabilirliğin nasıl olduğunu, Bun test paketini geçmenin ne kadar zor olduğunu görmek ve Rust sürümüyle Zig sürümünü yan yana karşılaştırmak istediklerini söylemişti

  • Bu mesajı yazdığında cargo check 16.000'den fazla derleyici hatası veriyordu ve ne sürüm numarasını yazdırabiliyor ne de JavaScript çalıştırabiliyordu
    Bu kadar hızlı çalışır hale geleceğini de, performansın bu kadar rekabetçi olacağını da beklemiyormuş; ayrıntılar için bir blog yazısı gelecekmiş
  • Bakım yapılabilirlik, performans ve test paketi kontrollerine bakıp karar vermiş gibiler
  • Öyleyse şu ana kadar deney olarak çok başarılı demektir
  • Birkaç gün önce ayrıca “açık kaynak muhtemelen ters yöne gidecek. İnsan katkısı yasak. Slop, 2025~2026'nın nostaljik bir kalıntısı olacak” da demişti
    Anthropic tarafından satın alındıktan sonra bunu beklemek gerekirdi ama yine de hayal kırıklığı yaratıyor. Büyük dil modeli teknolojisinin kendisine karşı değilim ama bu “AI” şirketlerinin yazılım sektörünü ve genel olarak toplumu yiyip bitirerek güç kazanma biçimi iğrenç ve çok sağlıksız bir bağımlılık yaratıyor
    Birkaç hamle sonrasını düşünüp slop'suz yazılım yığını ve topluluklar hazırlamak gerekiyor. Buna Zig ve ekosistemi de dahil. Biz ve gelecek nesiller slop olmadan tamamen yaşayamasa bile, özgürlük olarak özgürlüğe sahip sürdürülebilir bir bilişim kültürünü güvence altına almak her zamankinden daha önemli

• Bunu bu kadar hızlı yapmış olmaları çok etkileyici. Benzer şekilde TypeScript'i Rust'a port etme projesi üzerinde 5 aydır çalışıyorum ama Mythos'a ve sınırsız token erişimine sahip değilim
  Yine de neredeyse %100 geçiş oranına ulaştı ve yazı yazıldığı sırada %99,6'daydı: https://tsz.dev
  Rust, büyük dil modelleriyle kod yazmak için çok uygun. Katı tip sistemi sayesinde başka dillerde kabul edilebilecek çok aptalca hataları daha az yapıyorsunuz
  Ama büyük dil modelleriyle kod yazıyor olmak, proje oluştururken gereken tasarım vizyonunu ve trade-off değerlendirmesini ortadan kaldırmıyor. Bu yüzden Jarred ve ekip, büyük dil modelleriyle muazzam miktarda kodu etkili biçimde kullanabilecek doğru insanlar

  • Rust'ın derleme zamanında değişmezleri zorlaması, büyük dil modellerinin hızlı geri bildirim alıp geri dönebilmesini sağladığı için çalışan kod üretmeye yardımcı oluyor
    Öte yandan Rust karmaşık bir dil; küçük bir değişiklik uzak yerlerdeki kodu refactor etmeye zorlayan bir refactoring çığına kolayca yol açabiliyor. İlk mimari kötü ya da yetersizse, büyük dil modellerinin genelde yaptığı gibi kod tabanını kademeli büyüttükçe spagettiye dönme riski çok yüksek
    Sonunda derlenen ve çalışan ama insanların okuyamadığı ya da bakımını yapamadığı bir programa dönüşmesinden endişe ediyorum
  • Benzer şekilde çok iş parçacıklı Postgres üzerinde de çalışıyorum. 1 ayda pg regresyon testlerinin %96'sını geçti ve 823K LOC'ye ulaştı
    Mythos olmadan, aylık 200 dolarlık 8 Codex hesabının sağlayabildiği kadarına sahiptim
    Rust'ın avantajlarını burada da gördüm ve Postgres deneyimime dayanarak insanların uzun zamandır pg'de zorlandığı çeşitli alanlarda iyi tasarım kararları verebileceğimi düşünüyorum. AI sayesinde geçmişte pratik olmayan karmaşık yazılım iyileştirmelerinin daha mümkün hale gelmesi heyecan verici
    [0] https://github.com/malisper/pgrust
    [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • Microsoft bunu Go ile yeniden yazdığında, liderlerden biri Rust yerine Go seçmelerinin gerekçesi olarak paradigma benzerliğini göstermişti. Çöp toplayıcı vb. şeylerin benzer olduğunu, Rust'ın daha zor olacağını ve daha çok dolambaç gerektireceğini söylemişti; bizzat yapmış biri olarak senin deneyimin nasıl merak ediyorum
  • Rust harika ama büyük bir projede büyük dil modelleriyle Rust yazılımı üretmeye kalkınca istediğiniz çalışma biçimi çöküyor
    Temiz sınırları korumak ya da kurmak bile akış halinden çıkıp acı verici bir review işine dönüşüyor ve sonunda erteleme moduna düşüyorsunuz
  • Opus'un Rust deyimlerini görmezden gelip olabilecek en tuhaf Rust'ı yazmamasını sağlamakta zorlandım. Bununla ilgili bir ipucun var mı?

• Güçlü bir gerekçem yok ama artık Bun'la ilişkim olsun istemiyorum. Daha çok içgüdüsel bir şey ama güven de duyamıyorum destek de veremiyorum
  LLM yeniden yazımından yararlanmak için Zig'i fork ettiler ve Zig ekibinin açıkça istemediği deterministik olmayan derleme gibi şeyler yaptılar
  Şimdi de sızlanır gibi Rust ile LLM yeniden yazımı yapıyorlar. Belki de Zig'in tasarım felsefesi zor ama isabetli kararları zorladığı için bugüne geldiler ve Rust yeniden yazımı gerçekten çöküşün başlangıcı olabilir
  Bu teknikten çok siyasete yakın bir değerlendirme ama Bun tamamen Claude tarafından taşınıyormuş gibi görünüyor. Anthropic'in bir sonraki pazarlama sloganı “Claude Mythos, önde gelen 950K LOC JS runtime'ını Rust ile yeniden yazdı” olsa şaşırmam

  • Kendi deposuna kod yazan geliştirici mi sızlanan bebek, yoksa Hacker News'te bundan şikâyet eden kişi mi, emin değilim
  • Jarred'ın sızlandığını görmedim; sanki duygular yanlış hedefe yönelmiş
    Bağlantısı verilen Twitter flood'u açık teknik gerekçeler sunuyor
  • Bun'a kişisel olarak o kadar yatırım yapmış değilim ama bunun neden önemli olduğunu anlamıyorum. Diğer bağımlılıkları da bu kadar inceliyor musunuz merak ediyorum
    JS/NPM ekosisteminde çalışmak zaten doğrulanmamış bağımlılıklara büyük ölçüde saf inançla dayanmak demek ve LLM yeniden yazımı öncesiyle sonrası arasında bir fark görmüyorum. Asıl hedefi ve API sözleşmesini karşılıyorsa fark eder mi? Mevcut kaynak kodu zaten gerçekten dikkatle okunuyor muydu, ondan da emin değilim
  • Katılıyorum. Bun'ın tasarım felsefesi en başından beri açıktı. Runtime, bundler, test paketi, paket yöneticisi; istediği her şeyi yapıyor ve her hafta kırılan patch'ler yayımlıyordu
    Her seferinde mevcut rakipleri daha iyi, daha hızlı, daha güçlü biçimde ezeceği havası vardı ama Keep It Simple Stupid yaklaşımını asla benimsemeyeceği çok belliydi
    Yakın gelecekte bunu gerçek üretim ortamında göreceğimiz yerlerin, gaz verilmiş gibi tek tek yanan YC girişimleri olacağı da belliydi. Artık geri dönüşsüz noktayı geçmiş gibi görünüyor
  • Bun fiilen öldü
    Anthropic, kendi “performans” sorunlarını çözmeye yönelik biraz aptalca bir girişimle Bun'ı satın aldı. Sorunun en başta kötü kod olması olduğunu anlamamış gibiler
    Yine de gerçekten yetenekli geliştiricileri bünyelerine kattılar; bu bir ölçüde yardımcı olmuş olabilir
    Ama bu süreçte Bun açık bir projeden çok Anthropic'in iç aracına dönüştü ve şimdi AI parasıyla aşırı korunurken odağını da epey kaybetti
    Balon patladığında, en azından Bun'a harcanan emeğin bir kısmı kurtarılabilir umarım. Anthropic'in bunu uzun vadede sürdüreceğini sanmıyorum. Onlar runtime desteği satan bir şirket değil, bir runtime'ı yandan yaşatacak Google ölçeğinde de değiller

• AI kısmını bir anlığına dışarıda bırakırsak bunun iyi bir değişiklik olduğunu düşünüyorum
  Bun, Zig kullanırken çökme ve bellek hataları açısından aşırı sorunluydu; Rust tabanlı Deno öyle değildi
  Elbette Bun'ın Rust portunda çok fazla unsafe varsa her şey sihirli şekilde çözülmeyecek ama yine de daha iyi olacaktır

  • Bun'da çökme ve bellek hatalarının aşırı fazla olduğuna dair bir istatistik ya da kaynak var mı merak ediyorum. Yanlış olduğunu düşündüğümden değil
    Çirkin kısımların unsafe ile daha görünür hale gelmesinin refactoring'i teşvik etmesi, bunun sadece dil meselesi değil, Bun'ın kısmen kendi kendine açtığı bir sorun da olabileceğini düşündürüyor
  • Buradaki iddia, Zig kullanınca “çökme ve bellek hatalarının aşırı arttığı” mı?
    Öyleyse böyle bir araçla yüksek kaliteli yazılım üretmek fiilen imkânsız olurdu, değil mi? C/C++ ile de çok kaliteli şeyler üretildi; Zig tam olarak neyi yanlış yapıyor diye merak ediyorum
  • unsafe ile açıkça işaretlendiği için bulması daha kolay ve çözülmesi gereken sorunların doğal bir listesi oluşuyor

• Bunun yapılması 6 gün sürdü. Sonunda anlamlı bir sonuca dönüşmese bile, token ile iş miktarının bugün ve gelecekte nasıl bağlanacağını gösteriyor
  Daha fazla hesaplama kaynağına sahip bireyler ya da şirketlerle rekabet etmek zorlaşacak. Onlar benim yapamayacağım şeyleri basitçe yapabilecek

  • İyi bir test paketi olan bir projeyi bir dilden diğerine çevirmek, büyük dil modellerinin iyi olduğu klasik örneklerden biri olarak biliniyor
    Tamamlanmış bir kod tabanını örnek olarak kullanıp test paketiyle doğrulayabiliyorsanız, istenen hedefe doğru yineleme yapmak çok daha kolay. Model hem hedefin ne olduğunu hem de bir kez nasıl uygulandığını zaten görebildiği için, spesifikasyondan başlamaktan çok daha kolay bir problem bu
  • Aynı şey buhar gücü ya da elektrik için de söylenebilirdi. Bu sadece yüzeysel bir benzetme de değil. Bunların sihri genel amaçlı bilgi motorları olmalarında yatıyor
    Sermaye koyup iyi anlaşılmış, ölçeklenebilir bir teknikle inşa ediyorsunuz; fişe takınca değer üretiyor
    Demek istediğim, modern dünyada elektrikte olduğu gibi, burada da “sahip olanlar ve olmayanlar” diye kalıcı bir ayrım oluşmayabilir
  • Emin değilim. Gerçekten iyi ürünler genelde birçok şeyi yapmakla değil, bir ya da iki şeyi çok iyi yapmakla ortaya çıkıyor
    Şu ana kadar gördüğüm şey daha çok “vay, artık ben 10x mühendisim!” diyerek daha fazla kod üretmek ama net bir yön ya da zevk sahibi olmamak. Bugünkü büyük dil modeli tabanlı işlerin çoğu bana sadece gürültü gibi geliyor
  • Hayır. Bu ajanları yerelde çalıştırmak giderek kolaylaşıyor
    Qwen 3.6 27b denedin mi bilmiyorum ama boyutuna göre yapabildikleri çılgınca. Bağlamı iyi yönetirsen küçük projelerde %100 vibe coding bile mümkün
    Bu modeller de hesaplama gibi sonunda fiyat rekabetiyle aşağı inecek
  • Anthropic'in standart ücretlendirmesiyle ödenmiş olsaydı bunun dolar olarak maliyeti ne olurdu acaba? Kabaca hesaplayabilecek biri var mı?

• Birçok kişi bunu olduğu gibi kabul ediyor ama bunun önemli bir kısmı, daha önce oluşturulmuş alışılmışın üstünde kapsamlı ve kuşatıcı bir test paketi sayesinde mümkün oldu

  • Yine de en yetkin mühendisin bile çok daha uzun sürede elde edeceği bir sonuç olduğu için etkileyici
    İleride bunun pazarlaması yapılırken, bu hızı mümkün kılan test paketini tasarlamak ve kürasyonunu yapmak için ne kadar insan emeği harcandığının da yazılmasını isterim
    Test paketleri mevcut nesil büyük dil modelleri için neredeyse ideal bir ortam gibi çalışıyor. Yeterince kapsamlı bir test paketi, ajanın istediği şekilde uygulayabileceği bir spesifikasyona dönüşüyor; burada hedef Rust'tı
    Bun gibi bir projede testler bu kadar iyi hazırlanmışsa, bazı durumlarda gerçek kaynak kodun tamamını atıp yalnızca testlere erişim vererek bile her şeyi sıfırdan yeniden uygulamak mümkün olabilir gibi geliyor
  • Eğer bu, diğer projelerle karşılaştırıldığında işi mümkün kılan tek şey olacak kadar “alışılmışın üstünde” bir test paketi ise, o zaman Bun'ın diğer Zig programlarına göre özellikle daha kararsız olduğu ve bu yüzden yeniden yazılması gerektiği iddiasıyla bu nasıl bağdaşıyor merak ediyorum
    Sorumluluğun bir kısmı test paketindeyse, bunun Rust portu için ne anlama geldiğini de merak ediyorum
  • Yani sadece 6 günde bunu yapabildiklerine mi bakalım
    Bunu mümkün kılan orijinal mimariye ve test paketine harcanmış yüz binlerce saatlik emeği yok mu sayalım?

• Bunu AI ile yapılan Rust portları için bir uyarı örneği olarak görmek mümkün
  https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

  • Testleri geçmek, çalıştığı anlamına gelmez
    Claude code C derleyicisi gcc testlerinin %100'ünü geçti ama hello world bile çalıştıramadı
  • O örneklerden çıkarılacak ders biraz farklı. Büyük dil modelleri kendilerine verilen geri bildirim döngüsüne göre üretim yapıyor
    Yalnızca mantık testleri verirsen hız hiç dikkate alınmaz. Hızı ölçen testleri de dahil eder ve performansı tutturmasını istersen, onu da yapar
    Bu, büyük dil modellerinin diğer hatalarıyla aynı türden bir sorun. İnsanların önemli bulduğu şeylere dair sağduyusal bağlamları yok. Sınırları zorlamazsan onları görmezden geliyorlar
  • İlgilenenler için burada tartışılmıştı: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - Mart 2026, 422 yorum

• Yaşadığımız dönem gerçekten inanılmaz
  Sektörün ve mesleğin temel dinamikleri çok kısa sürede, adeta bir gecede değişti
  Bazı günler şu an yapabileceklerimin bu kadar artmış olması beni heyecanlandırıyor. İstediğim neredeyse her şeyi hemen yapabiliyorum ve yazılımla hayal ettiğim şeylerin %100'ü gerçeğe dönüşebilir gibi geliyor
  Bazı günler ise iş piyasasına ne olacağından korkuyorum
  Bir anda çok az şeyle çok büyük sonuçlar elde edebilir hale geldik ve dünyanın ihtiyaç duyduğu yazılım miktarının da bir sınırı var
  Yazılım satmayı temel iş modeli yapan bütün şirketler batacak mı?
  Ya en iyi modellere sadece belli şirketler veya devletler erişebilirse?

  • Biletleme sistemi gibi bir yazılım işini düşünelim
    1 milyar token'a sahip 100 şirket, 100 milyar token'a sahip uzman bir satıcıdan daha iyi ürün yapabilir mi?
    “Logo üretici” gibi yazılım satıcıları ve SaaS'ların öldüğü doğru ama, yeni nesil büyük dil modellerinin içine biletleme sistemi gömülmediği sürece biletleme sistemi satıcıları iyi durumda olur. İnsan sayısı azalabilir ama bundan emin değilim
  • Dot-com çöküşü civarında da yazılım sektörünün “aşırı doymuş” olduğuna ve öğrenciyle iş arayanların bu alana girmemesi gerektiğine dair çok konuşma vardı
    Gelen insan sayısına kıyasla paylaşılacak iş azdı ve çöküş bu anlatıyı güçlendirmişti
    Ama o zamanlar öğrenci olsanız bile yazılımın kapsamının fiilen sonsuz olduğunu görebilirdiniz. Elle yaptığımız neredeyse her bilişsel işi yazılımla yapabiliriz. Bir keresinde bunları listelemeye çalışmıştım ama yapılacak işin ne kadar fazla olduğunu çok çabuk fark etmiştim
    Üstelik işleri yeni yollarla yaptıkça, hiç beklenmeyen daha fazla iş de ortaya çıkıyor. Olasılıklar saymakla bitmiyordu ve “doygunluk” anlatısının, yazılımın ne olduğuna dair hayal gücü ve anlayış eksikliğinden kaynaklandığı açıktı
    Bu yüzden alanın asla doymayacağını biliyordum. Çünkü yazılımla inşa edilecek şeylerin tükeneceği fikri mümkün değildi
    Ama bugünlerde farklı hissediyorum. Yeni yazılımlar elbette yapılmaya devam edecek ama artık, yazılımı kullanma hızımızın yeni işler hayal etme hızımızı geçip geçmeyeceğini düşünüyorum
  • Şirketler ve devletler, halkın erişebildiğinden daha iyi modellere erişecek. Nitekim Mythos zaten bunun bir örneği
    Halk da en ileri seviyenin gerisindeki modellerle kendine yine yardımcı olabilir

• En azından böyle bir denemenin ilerleyişini izlemek ilginç
  İlk merak ettiğim şey, en başta test paketinin kapsayıcılığı ve kalitesinin ne düzeyde olduğu. Kusur aramak için söylemiyorum ama tüm platformlarda %100 çıksa bile, Bun ekibinin geçiş konusunda ne kadar emin hissedeceğini merak ediyorum

• Geçen haftaki Ubuntu coreutils işi yüzünden %99,8 test uyumlu Rust yeniden yazımı ifadesine karşı gerçekten kötü bir izlenim oluştu
  Burada bağlantısı verilen tweet'e tıklayınca içim ürperdi ve artık böyle şeyleri görünce tam tersi bir duygu hissediyorum. Neredeyse çıkış kapısını arayacak hale geldim