Bun’ın Rust ile yeniden yazımı PR’ı merge edildi

• PR #30412, Bun’ın Rust ile yeniden yazılması değişikliğini içeriyor ve 14 Mayıs 2026’da claude/phase-a-port dalından maine merge edildi
• Değişikliğin boyutu 6.755 commit, 2.188 dosya ve +1,009,257/-4,024 satır olarak görünüyor
• Jarred-Sumner, ayrıntıları içeren bir blog yazısının yakında geleceğini belirtti
• Bu değişikliğin, Bun’ın mevcut test suite’ini tüm platformlarda geçtiği ve çeşitli bellek sızıntılarıyla kararsız testleri düzelttiği açıklandı
• İkili dosya boyutunun 3MB~8MB azaldığı ve benchmark sonuçlarının nötr ya da daha hızlı tarafta olduğu belirtildi
• En önemli gerekçe olarak, ekibin yıllardır büyük geliştirme ve hata ayıklama zamanı harcadığı bellek hatalarını derleyici destekli araçlarla yakalayıp önleyebilir hale gelmesi gösterildi
• Kod tabanının büyük ölçüde aynı kaldığı, mimari ve veri yapılarının da korunduğu ifade edildi
• Bun’ın hâlâ az sayıda üçüncü taraf kütüphane kullandığı ve async Rust kullanmadığı özellikle belirtildi
• Kullanıcılar bu değişikliği bun upgrade --canary ile deneyebilir
• Jarred-Sumner, sorun çıkarsa issue açılmasını istedi ve başlık aşırı hararetlenirse kilitlenebileceğini söyledi
• Canary olmayan sürüme girmeden önce hâlâ optimizasyon çalışmaları kaldığı belirtildi
• Temizlik çalışmalarının da henüz tamamlanmadığı ve bunun takip eden PR serileriyle sürdürüleceği ifade edildi

[xguru]

Vay be, milyon satırlık PR merge edilmiş. Zig’den Rust’a tek seferde geçiyorlar resmen.
"Bunun merge edilip edilmeyeceğini bilmiyorum~~" diyordu, ama bir hafta içinde gayet iyi çalışan kodun dilini tek hamlede değiştirmişler haha
Yapay zeka destekli kodlama yüzünden anıtsal bir şey oluyormuş gibi hissettiriyor.

[heycalmdown]

Gerçekten de sadece test ettiklerini ve muhtemelen kullanmayacaklarını söylemişlerdi.

[freedomzero]

Zig'de yapmayınca doğrudan Rust'a geçme cüretleri bayağı iyiymiş lol

[GN⁺]

Hacker News yorumları

• Duyuruda yeniden yazımın 1 hafta sürdüğü söyleniyorsa, Zig deyimlerini Rust deyimlerine eşleyen bu son derece ayrıntılı kılavuz dosyasını hazırlamanın ne kadar sürdüğünü merak ediyorum: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
  Ayrıca Pointers & ownership ve Collections bölümlerine bakınca, Bun kod tabanı zaten Rust karşılıklarıyla bire bir eşlenecek şekilde dahili akıllı işaretçi türleri kullanacak biçimde hazırlanmış gibi görünüyor ve bun_collections Rust crate'i de zaten mevcut
  Bu yeniden yazım uzun zamandır hazırlanıyordu ve Bun ekibi bunu Anthropic satın alma görüşmeleri sırasında önermiş gibi görünüyor

  • LLM ile ilgili şeyler okurken neyin doğru olduğunu bilemiyorum, burada Hacker News yorumları için de aynı şey geçerli
    Ortada dönen para o kadar büyük ki topluluğa pazarlama figüranları yerleştirmek için açık bir teşvik var ve bazıları da sadece kampçılığa kapılmış durumda
    Anthropic artık Bun'ın sahibi olduğuna göre, bu işi gerçekte olduğundan daha kolay göstermeleri için de yeterince teşvik var
  • Ortaya çıkan Rust kodunun kaliteli olup olmadığı, satır sayısının makul olup olmadığı ya da kod tabanının baştan bu işe ne kadar hazır olduğu gibi unsurları bir kenara koyarsak, yaklaşık 1 milyon satır çıktının tutarlılığını veya kalitesini artırabilecek bir ön üretim çıktısı olarak 622 satırlık bir belge görece küçük bir maliyet sayılmaz mı diye düşünüyorum
    Çıktının ölçeği o kadar büyük ki burada çarpan etkisi var gibi görünüyor
    Yine de bu kuralları oluşturmak için ne kadar örtük bilgi gerektiğini ve bu dosyanın kaç kez yinelemeli olarak iyileştirildiğini merak ediyorum
    Örneğin bu kuralların ne kadarı çeviri tekrarları sırasında karşılaşılan başarısız örneklerden çıktı, bunu bilmek isterdim
  • using internal smart pointer types that map 1-to-1 to Rust equivalents denmiş ama akıllı işaretçiler Rust'ın icadı değil
    İşaretçisi olan başka bir dilde kod yazıyorsanız aynı türleri zaten zihninizde modelliyorsunuzdur
    Ve bun_collections Rust crate'inin zaten var olduğu da yanlış
    Bu sadece kod tabanındaki PR'ın bir parçası, önceden var olan bir şey değil
  • Bu, Anthropic'in gcc demosu ile de aynı
    Şüpheyi azaltmak ve IPO havasını daha da yükseltmek çok kolay olurdu: yapay zekayı bu noktaya getirmek için gerekli gizli çalışmayı ayrı bir depo olarak yayımlayıp herkesin sonucu yeniden üretmesini sağlamak yeterli
    Sonuçta müşterilerin elde etmek istediği şey de “7 günde” kullanılabilir 1 milyon satır kod değil mi
    Herkes bunu kendi iş akışında yeniden üretmeye çalışırken Anthropic kullanım metrikleri de yükselirdi
    Gerçekten harika bir sonuç olsaydı, önce bağlantılar ve talimatlar içeren bir blog yazısı yayımlanırdı diye düşünüyorum
    Gerçi tam şu anda bir blog yazısı hazırlanıyor olabilir ve benim haksız olduğum ortaya çıkabilir
  • Bun'ın Zig sürümünde mevcut Rust işaretçi türlerine temiz biçimde eşlenen 3 işaretçi türü var gibiydi, kalan 7-8 tür içinse yeni türler oluşturmak gerekmiş gibi görünüyor
    Komplo teorisinin özü bu mu
    bun_collections da portlama kılavuzundan çok daha eski görünmüyor

• [phone] ne demek, Bun artık 1 milyon satır Rust kodunu geçmiş durumda
  Boyut olarak Rust derleyicisinin kendisine yaklaşmaya başlıyor
  Ama BunJS büyük ölçüde bir JavaScript yorumlayıcısı sarmalayıcısı ve NodeJS kütüphanelerinin yeniden uygulaması, yani Rust standart kütüphanesi sarmalayıcısına daha yakın
  BunJS, LLM çağında yazılım karmaşıklığını yönetme konusunda bir kanarya hâline geliyor gibi görünüyor

  • mostly a JavaScript interpreter wrapper ifadesi doğru değil
    Bun; pilleri içinde gelen bir JavaScript ve CSS transpiler'ı (parser), küçültücü, bundler, npm benzeri paket yöneticisi, Jest benzeri test çalıştırıcısı ve yerleşik Postgres, MySQL, Redis istemcileri gibi çalışma zamanı API'leri de içeriyor
    Doğal olarak çok fazla kod olması kaçınılmaz
  • Bun bir JavaScript yorumlayıcısı değil, daha çok NodeJS kütüphanesi ve çeşitli diğer kütüphanelerin yeniden uygulanması
    Bun, JS motoru olarak JavaScriptCore kullandığından Bun'ın kendisi JavaScript ayrıştırma, yorumlama ve JIT yapmaz ya da en azından yapmaması gerekir
    Düzeltme: yanlış okumuşum. “JavaScript interpreter wrapper” denmiş, yani doğru bir ifade
  • iOS'ta telefon numarası olarak algılanmasının baştaki + işaretinden mi kaynaklandığını yoksa başka etkenler de olup olmadığını bilmiyorum ama mobilde satır sayısı değişimi altı çizili görünüyor ve dokununca arama yapabiliyorsunuz
    Diff boyutundan dolayı oluyorsa epey komik
  • Bun kod tabanı yeniden yazımdan önce de benzer sayıda kod satırına sahipti
    Yeniden yazım sonucunun benzer LOC ile çıkması garip değil
  • Bir JavaScriptCore sarmalayıcısının 1 milyon satır olması, ajanların neler yapabildiğini gösteren mükemmel bir örnek

• $ rg 'unsafe [{]' src/ | wc -l sonucunun 10428, $ rg 'unsafe [{]' src/ -l | wc -l sonucunun ise 736 olduğu söyleniyor
  Dillere göre dağılım da şöyle: Rust 1443 dosya 929213 satır, Zig 1298 dosya 711112 satır, TypeScript 2604 dosya 654684 satır, JavaScript 4370 dosya 364928 satır, C 111 dosya 305123 satır, C++ 586 dosya 262475 satır, C Header 779 dosya 100979 satır

  • Rust'ta potansiyel olarak güvensiz kodu böyle özel olarak arayabilmek güzel
    Zig'de güvensiz kodu nasıl arıyorsunuz
    Yoksa sadece her yerde olduğunu mu varsaymak gerekiyor
  • Dosyaların yarısında unsafe anahtar sözcüğü geçiyorsa bu iyi bir yeniden yazım gibi görünmüyor
    Kodun neredeyse yarısı hâlâ unsafe ise Rust'a yeniden yazmanın anlamı ne
  • Mythos'un iddia ettikleri gibi dünyanın en iyisi olmasını umuyorum. Artık gerçekten ihtiyaçları olacak
  • Evde bellek güvenliği var!
    Evdeki şey: 10428

• Bununla ilgili blog yazısını hâlâ yazıyoruz ve daha fazla ayrıntı paylaşacağız
  Arka planı merak ediyorsanız Bun v1.3.14 ve ondan önceki sürüm notlarındaki hata düzeltmeleri listesine göz atabilirsiniz
  Rust bunların hepsini çözmüyor. Referansları çok uzun süre tutmaktan kaynaklanan sızıntılar ya da JS sınırını aşarak yeniden girişten doğan sorunların tümü hâlâ bizim sorumluluğumuzda
  Ama o listedekilerin önemli bir kısmı use-after-free, double-free ve hata yollarında serbest bırakmayı unutma gibi sorunlar; bunlar ya derleme hatasına dönüşüyor ya da otomatik temizlemeyle çözülüyor

  • 9 gün önce şöyle demişti[0]:
    I work on Bun and this is my branch
This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
    Belki de bu kadar da aşırı tepki değildi?
    [0]: https://news.ycombinator.com/item?id=48019226
  • Blog yazısını merakla bekliyorum
    Hataları yakalamak için Zig ve Rust ikililerini geniş çaplı gerçek uygulamalarda yan yana çalıştırmayı ya da mümkünse üretimde shadow run yapmayı planlıyor musunuz, merak ediyorum
  • Ücretli müşteri olsaydım bu işin ne kadara mal olduğunu merak ederdim
    Kabaca bir tahmin verebilir misiniz
  • İki ikiliyi karşılaştıran bir tür uçtan uca fuzz testi uyguladınız mı ya da uygulamayı planlıyor musunuz, bunu merak ediyorum
    Bu sürümü kullanıcı iş akışlarını bozmadan yayımlamak için somut planın ne olduğunu da bilmek isterim
  • Bunun Bun Workers API kararlılık sorunlarını düzeltme ihtimali var mı? https://bun.com/docs/runtime/workers

• Yaklaşık 9 gün önce Jarred bunun birleştirilmesinin hiç de kesin olmadığını ve verilen tepkinin aşırı olduğunu yazmıştı
  İronik

  • Açık kaynak liderliği için örnek uygulama gibi
    Linus'un Linux çekirdeğini yeniden yazmayacağını söyleyip sonra bir gün uyanıp tamamını makine destekli bir Rust yeniden yazımı olarak birleştirdiğini düşünün; nasıl bir kaos çıkardı
  • Artık şirkete sahip olmadığınızda, söyledikleriniz güvenle görmezden gelinebilir
    Harcanan token maliyetini bir şekilde haklı çıkarmaları gerekiyordu zaten
  • Bu yine de birleştirilmeyeceği anlamına gelmiyor

• Vay canına, bunu izlemek eğlenceli olacak
  Bu kodun incelenmiş olma ihtimali sıfır ama belki de artık modellerin kod yazıp gözden geçirmesine güvenebileceğimiz bir post-human çağa girmişizdir
  Bu Gastown gibi ama çok daha ünlü bir projede yaşandı
  Bu projenin bundan sonra yeni özellikleri nasıl ekleyebileceği, hatta ekleyip ekleyemeyeceği ilgimi çekiyor
  Anthropic'in Bun'ı tam olarak nasıl kullandığını bilen var mı
  Claude Code'un bir parçası mı
  Bundan sonra Bun kullanmak konusunda epey endişeliyim ama bu endişenin Claude kullanımına ne kadar yansıması gerektiğinden emin değilim

  • Modellerin kod yazıp gözden geçirmesine güvenebileceğimiz kesinlikle söylenemez
  • Tüm testler geçti
    Otomatik dil çevirisini yakalayacak test paketine güvenemiyorsanız, o test paketine zaten hiç güvenmemeniz gerekir :)
  • Anthropic'in Bun'ı nasıl kullandığını bilmiyorum ama tartışmanın çerçevesini, milyonlarca satırı gelişigüzel birleştirmenin kabul edilebilir olduğu yöne taşımak için kullanıyor gibi görünüyor
  • Test paketi ne durumda

• Otomatik çeviriyi denemeleri aslında heyecan verici ama çok fazla geriye dönük uyumluluk sorunu çıkmasından endişe ediyorum
  Commit'e bakmaya başladım ve temelde “testler geçmiyor” sorununu testlerin kendisini değiştirerek çözüyorlar
  Hâlihazırda dağıtılmış programlarda bunun gerçekten düzgün çalışmasını sağlamak için gereken asıl iş daha yeni başlıyor
  Tek teselli, sunucu tarafı JS topluluğunun her nedense sık sık kırılmaya zaten alışkın olması

  • Kullandığım runtime içine tek bir kişinin bile bakmadığı kodun girecek olması beni rahatsız ediyor
    Ama bu gerçekten büyük bir sorun çıkarmadan çalışırsa oldukça etkileyici olur
  • Bu kararları LLM'in alıp almadığını bilmiyorum ama Claude'un doğru çözümü bulmaktan çok testleri değiştirerek sorunu çözmeye yönelik şüpheli davranışlara daha yatkın olduğunu hep hissettim
    GPT/Codex bu konuda daha dürüst
  • Bunun hemen kararlı sürüm olacağını sanmıyorum ama yanıldığım kanıtlanırsa memnun olurum
    Bu yeniden yazımın tamamına şüpheyle yaklaşıyorum ve Jarred Sumner'ın internette çok büyük bir takipçi kitlesi olduğu için bana biraz reklam gibi geliyor
  • “Testler geçmiyor” sorununu testlerin kendisini değiştirerek çözmeye örnek: https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...
    Harika! Teste rastgele bir sleep(1) eklemek yeterli. Merak etmeyin, her şey yoluna girecek!
  • Testlere göz gezdirip gerçekten önemli bir değişiklik var mı görmek istiyorum ama GitHub diff'i bile yükleyemiyor

• Bun kullandığım birkaç projeyi başka bir şeye taşıyacağım
  Böyle pervasız bir değişikliğe izin veren bir yönetişime güvenmiyorum

  • Deno harika ama yeterince sevilmediğini düşünüyorum
    Zaten baştan iyi yazıldığı için yeniden yazılmasına da gerek yok
  • Ben de sadece node kullanmaya devam edeceğim
    Öte yandan ateşten geçme sınavının nasıl sonuçlanacağını izlemek ilginç olacak ve uzun vadede sorunların eninde sonunda çözüleceğini düşünüyorum

• Eğitim amaçlı bakılabilecek bir başlık daha var. Bir hafta önce Jarred'ın yine birleştirme kararından uzak durduğu ve pek çok yayanın bunun yakında birleştirileceğini öngörenlere saldırdığı başlık:
  https://news.ycombinator.com/item?id=48073680
  Geriye dönüp bakınca pek iyi yaşlanmamış sözler, değil mi?

  • “Bu başlığın tamamı aşırı tepki. Çalışmayan kod hakkında 302 yorum var. Yeniden yazmaya karar vermedik. Bu kodun tamamının tamamen çöpe gitme ihtimali çok yüksek” noktasından, deneysel bir merak gibi görünen şey de dâhil olmak üzere 10 gün içinde tam birleştirmeye gelmek gerçekten çılgınca görünüyor
  • Dünyada hangi çizmeyi yaladığıyla pek ilgilenmeyen ne kadar çok güç takipçisi olduğunu görmek her seferinde şaşırtıyor

• Bu iş azıcık bile ters giderse, kendi malına bağımlı bir torbacı gibi alay edilmesi bitmek bilmeyecek ve çok karanlık olacak

  • Hiç ters gitmeme ihtimaline duygusal olarak hazır olmayan çok fazla insan var
  • Sızdırılan Claude Code kaynaklarını görmek bile tek başına zaten yeterince alay konusu değil miydi
  • Zaten kendi malına bağımlı durumda
    Mythos makalesini okudunuz mu? Aşırı derecede insanlaştırma var
    Belki sadece ucuz bir ilgi çekme taktiğidir ama gerçekten LLM'lerin bilinç sahibi olduğuna inanıyorsa... vay canına