Bun’ın Rust ile yeniden yazımı nasıl gidiyor?

• 11 günde tamamlanan bir çalışma olarak bilinse de, main ile birleştirildikten 6 hafta sonra, 27 Temmuz 2026 itibarıyla hâlâ bir sürüm etiketi yok ve ilgili çalışmalar sürüyor
• İlk yeniden yazım için 3–14 Mayıs 2026 arasında 165 bin dolar Anthropic API maliyeti oluştu; ancak Buildkite CI/CD ve sonraki çalışmaların maliyetleri buna dahil görünmüyor
• robobun’ın açık PR sayısı 9 Temmuz’da 1.277 iken 27 Temmuz’da 2.475’e çıktı; PR başına pipeline yaklaşık 40 dakika sürüyorsa hepsini işlemek için 86 gün boyunca kesintisiz çalıştırmak gerekir
• Claude kullanımı yeniden yazımın başlamasıyla hızla arttı; robobun ve Anthropic çalışanlarının Rust çalışmalarına katılımı da yükseldi. Bu yüzden tamamlanma zamanı ve gerçek toplam maliyetin 165 bin dolar olduğunu kesin söylemek zor
• Bun ekibi yeniden yazımın tamamlandığını veya toplam maliyeti doğrudan kesinleştirmiş değil; bu nedenle yapay zeka ile kodlama başarısını şirket değerlemesine dayanak yapmak için maliyet karşısındaki değeri ve süregelen insan müdahalesini de incelemek gerekir

---

Birleştirme sonrasında da süren yeniden yazım

• Jarred Sumner, Rewriting Bun in Rust yazısında 3–14 Mayıs 2026 arasındaki 11 günde Anthropic API çağrılarına 165 bin dolar harcadıklarını ve yeniden yazım sonucunu main ile birleştirdiklerini açıkladı
  • Bu, günde yaklaşık 15 bin dolar demek; birçok açık kaynak bakımcısının karşılaması zor bir ölçek
  • Kuruluşun Buildkite kümesinde çalışmaya devam ettiği anlaşılan CI/CD maliyetleri bu rakama dahil görünmüyor
• 27 Temmuz 2026 itibarıyla birleştirmeden bu yana 6 hafta geçmiş olsa da yeni bir sürüm etiketi yok; son etiket olan bun-v1.3.14 üzerinden ise 11 hafta geçti
  • Daha önce bir aydan uzun süre sürüm çıkmayan dönem, 26 Ekim 2022’deki v0.2.2 ile 7 Aralık’taki v0.3.0 arasında süren 6 haftalık boşluktu
• Claude Code’un oluşturduğu PR’lar için vekil gösterge olan robobun açık PR’ları, 9 Temmuz’da 1.277 iken 27 Temmuz’da 2.475’e yükseldi
  • Buildkite kontrolleri ve main ile birleştirme işlemlerinin genelde yaklaşık 40 dakika, bazen de 1 saat 30 dakikaya kadar sürdüğü gözlemleniyor
  • PR başına 40 dakika uygulanırsa 2.475 PR’ın tamamını birleştirmek için pipeline’ı 86 gün boyunca kesintisiz çalıştırmak gerekir
  • Bazı PR’lar Rust koduyla ilgili değil; tekil PR’lar arasında çok kapsamlı incelemeden geçmiş örnekler de var

Açıklanan maliyet ile gerçek emek arasındaki fark

• Yeniden yazımın başladığı dönemde Claude kullanımı ciddi ölçüde arttı; sonrasında Anthropic çalışanları ve robobun’ın Rust çalışmalarına katılımında da artış görüldü
  • Analizde, yeniden yazım döneminde Jarred Sumner’ın commit’lerinde Claude kullandığı varsayımı yer alıyor
  • Bazı PR’lar Anthropic çalışanları tarafından yazıldığı için yalnızca token maliyetini değil, çalışanların doğrudan müdahalesini de hesaba katmak gerekir
• Yeniden yazımın günde 10 bin dolara mal olmaya devam ettiği varsayılırsa kümülatif maliyet yaklaşık 800 bin dolara yaklaşır; ancak bu açıklanmış gerçek maliyet değil, varsayıma dayalı bir tahmindir
• Bun ekibi yeniden yazımın tamamen bittiğini veya toplam maliyetin yalnızca 165 bin dolar olduğunu iddia etmedi
  • Bu vaka tek başına, yapay zekanın açık kaynak bakımcılarının işini daha hızlı biçimde ikame ettiğini kabul etmek için yeterli değil
  • Anthropic kendi araçlarını içeride uyguluyor; otomasyon çalışmaları ve çalışan katılımı da devam ediyor
• Yapay zekanın kendisini reddetmekten ziyade mevcut aşırı beklentiler ve şirket değerlemelerine temkinli yaklaşmak; harcanan maliyete değip değmediğini ve söz konusu şirket değerinin haklı olup olmadığını sorgulamak gerekiyor
• Anthropic’in C compiler’ı ve Cursor’ın FastRender web tarayıcısı aylar boyunca commit almadı

[GN⁺]

Hacker News yorumları

• Bun’ın Rust ile yeniden yazılmış sürümü bir aydan uzun süredir Claude Code’da çalışıyor, ama neredeyse kimse fark etmedi ve genel olarak iyi çalışıyor
  Bun v1.4 videosunda vaat edildiği kadar Node.js uyumluluk testini geçmeden yayımlanmayacak; ilgili PR birleştirilirse gelecek salı civarında v1.4 yayımlanma ihtimali yüksek

  • Yazılım kalitesi için gerektiği kadar zaman harcanabilir. Bir ay boyunca sürüm çıkmaması büyük mesele değil; belirli bir özellik acilse doğrudan katkıda bulunabilir ya da kendiniz derleyebilirsiniz
    Node.js de güvenlik düzeltmeleri dışında her yıl aralık ayında 4-6 hafta boyunca anlamlı bir sürüm yayımlamaz; bu yüzden muhatabına önce sormadan öfkeli bir yazıyla başlayan bu eleştirinin dayanağı zayıf. Bunu bir Node.js bakımcısı olarak söylüyorum
  • Claude Code’un kendisinde de sık sık hatalar ve sürüm sonrası kesintiler yaşandığı için, kullanıcıların Rust tabanlı Bun’a geçişten kaynaklanan hatalar ile olağan hataları ayırt edememesi şaşırtıcı değil
  • Yazıda tahmin edilen maliyetler, özellikle Buildkite maliyetleri hakkında yanıt verilip verilemeyeceği merak konusu
  • Birçok vibe coding projesinin güçlü başlayıp Anthropic C gibi kaderine terk edilebilmesi nedeniyle Bun’ın geleceği konusunda endişelenilmesini anlamak mümkün. Bun hızlı ve kullanımı keyifli; GCC gibi uzun ömürlü olması umuluyor

• Büyük ölçekli refaktörlerden veya yeniden yazımlardan hemen sonra normal geliştirme hızına dönmek zaman alır; bu yüzden yalnızca commit sayısı ve sürüm döngüsüne bakarak fazla hüküm vermek zor
  Geliştiriciler yapıya aşina olsalar bile Rust kod tabanına yeniden uyum sağlamak zorunda; kullanıcı özelliklerinden çok unsafe kullanım noktalarını izlemek gibi işlere odaklanıyor olmaları muhtemel. Canary kanalında da büyük bir sorun ya da değişiklik neredeyse fark edilmediği için, aceleyle yayımlamak yerine biriken işleri ele almak için yeterli neden var
  Anthropic’in C derleyicisini ve Cursor’ın FastRender tarayıcısını sürekliliği olan projelerden ziyade yetenek denemeleri olarak gördüm; umarım şu anda kimse bunları doğrudan kullanmıyordur

  • Bir ay önce tüm Claude Code kullanıcıları yeni sürüme geçirildiğine göre, bir anlamda zaten canlı ortam sürümü yayımlanmış sayılır. Çok dikkat çektiği ve resmi sürümü aceleye getirmeye gerek olmadığı için süreci kademeli yürütüyor gibi görünüyorlar
  • CI/CD maliyeti bakışı ilginç. Genelde yapay zeka yatırım getirisini çürütürken kodun fazla olmasının değeri artırmadığı söylenir, ama her CI çalıştırması için ücret alınıyorsa gerçek gelir artar
    Özellikle yapay zekanın ürettiği tekrar eden işlerin kontrolden çıkmasını önlemek için CI ve ek testlerin kilit olması da bununla örtüşüyor
  • Yazıyı yazan kişi açısından da bu rakamlarla ne kadar hüküm verilebileceği kesin değil. Bir sonraki sürümden sonra Anthropic ya da Bun’ın toplam maliyeti açıklayan bir değerlendirme yayımlamasını umuyor

• LLM ile bir projeyi kısa sürede çevirmek ya da bir ofis ürünü kopyasını tek hamlede yapmak başlı başına şaşırtıcı; ancak yazılımın özü hızlı ilk üretim değil, özellik geliştirme ve uzun vadeli bakım
  Bir Word kopyasında da temel özellikler hızla yapılır, ama sayfa yapısı, tablolar, görseller, döndürme gibi ayrıntılı özelliklerden itibaren LLM zorlanmaya başlar. SQLite’ı C’den Rust’a taşıyıp tüm testlerden geçirmek mümkün olsa bile, mevcut uygulamanın yıllara yayılan optimizasyonları olmadığı için yavaş olma ihtimali yüksektir; ayrıca dil değişiminin getirdiği yeni hataları ve gelecekteki desteği de üstlenmek gerekir
  Reddit’te X, Y, Z’yi uyguladığını söyleyen projeler sürekli çıkıyor; ancak hata düzeltme, kullanıcılarla ilgilenme, güvenlik, değişen veri yapıları ve veritabanı işleri cazip olmadığından, bunlar da vibe coding kadar hızlı şekilde terk edilebiliyor
  Kendi yaptığınız yazılımı derinlemesine anlamıyorsanız sonunda patlar; X’i Y günde Z olarak yeniden yazdım ifadesi tek başına hiçbir şey ifade etmez. Başlangıcı öne çekmek ile taşınmış kodu anlayıp büyütmek ve sürdürmek tamamen farklı işlerdir; bakımı yapılan Zig sürümü yerine terk edilmiş Rust sürümü ve tanıtım amaçlı yazılar arama sonuçlarını kirletebilir

  • Bu süreci daha çok kişinin kayda geçirmesi isteniyor. Kişisel olarak LLM bağımlılığı yüksek bir proje geliştirirken öğreniyorum; karmaşık bir özellik hızla çalıştığında güçlü bir haz veriyor, ama entegrasyon, temizlik ve UI cilalama, başlangıç hızının tadını aldıktan sonra aksine daha acı verici hale geliyor
    Kod fazla geçici çözümlerle birbirine dolandığında, LLM’nin daha büyük bir karmaşa yaratmadan ilerleyemediği bir atalet noktasına ulaşılıyor; mimariyi düzeltmek, her şeyi atıp yeniden başlamak ya da son düzgün çalışan noktaya dönmek gerekiyor. Jetpack takıp geliştirme yapmak gibi: hedefe de hızla gidiyorsunuz, duvara da daha hızlı ve daha acı şekilde çarpıyorsunuz
    Yapay zekanın en iyi mi en kötü mü olduğu tartışmaları ve araç kullanım yöntemleri yarışı arasında, neyin işe yarayıp neyin başarısız olduğuna ve kullanım sırasında davranışın nasıl değiştirilmesi gerektiğine dair bilgi eksik kalıyor. Kendi kullanım deneyimimi yazmaya çalışıyorum ama yeni özellik yapmak veya UI kusurlarını düzeltmek daha eğlenceli geldiği için erteliyorum
  • GitHub’da LLM’lerden önce de terk edilmiş binlerce oyun motoru ve kurmaca diller için derleyici vardı. 2000’lerin başındaki işletim sistemi forumlarında da neredeyse herkes kendi OS’unu yapıyordu; bazıları Firefox’u bile çalıştırıyordu
    Her yazılımın faydalı olması için ticari ya da çok olgun olması gerekmez; yalnızca öğrenme amaçlı deneyler bile çok şey öğretmeye yeter
  • Teknik olarak derinleştikçe, ikame edilebilir görülmek kolaylaşabiliyor. Çünkü organizasyonlarda değeri kişinin kendisinin ya da ilişkilerinin değil, saf teknik yetkinliğin yarattığı varsayımı kabul ediliyor
    Ancak ağ etkileri, sahiplik, hesap verebilirlik gibi olumsal unsurların da önemli olduğu gerçeği kabul edilmeye başlanmış gibi. Yine de birçok teknik insanın, bu tür unsurlara eşlik eden kayırmacılık, keyfi değerlendirme ve teknik beceriden çok böbürlenmenin önemsendiği ortamlardan kaçıp teknik alana girmiş olması da bir paradoks
  • Özellik geliştirmeyi de durdurup büyük bir kod tabanını tamamen yeniden yazan bir startup’ta çalıştım; ama başka bir projeyle uğraştığım için sürecin tamamını kaçırdıktan sonra geri döndüğümde bile öğrenme eğrisi neredeyse yoktu. Çünkü dil değişmiş olsa da çekirdek mimari, veri yapıları ve kavramlar aynıydı
    Bun da baştan yeniden tasarlanmadı; önce yeni dile olduğu gibi taşındı. LLM öncesi deneyime bakıldığında da ekibi hızlı geçirmek için en doğru yol, olabildiğince basit ve hızlı şekilde başka bir dile taşımaktır; yeniden yazım süresi X günü en aza indirmek iyi bir hedeftir
  • Kendi yazdığı kodu derinlemesine anlamama tavrı aşırı kısa vadeciliktir. Bakımcılar, yapay zeka tarafından üretilen kod ile insanlar tarafından sürdürülebilir kod arasındaki sınırı zor yoldan öğrenecek

• Birinin orijinal Zig uygulamasını modernleştirip en iyi uygulamaları uygulayarak hataları düzelttiği ve 1 saniyenin altında artımlı derleme elde ettiği söyleniyor. Bu, yeniden yazmayı haklı çıkardığı söylenen sorunların aslında kendi yarattıkları şeyler olduğunu ve çözülebilir olduklarını ima ediyor.
  https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
  Zig sürümü de LLM kullandığı için bunun kültür savaşıyla ilgisi yok. Sorun alanını gerçekten anlayan biri, yüz binlerce dolarlık token gibi kaynakları sadece üstüne boca eden birinden her zaman daha iyi sonuçlar çıkarabilirdi.

  • Yeniden yazmayı haklı çıkaran asıl nokta derleme hızı değil, özellikle çöp toplama ile yönetilen JavaScript nesneleriyle etkileşim sırasında ortaya çıkan bellek hatalarıydı. Zig’de bunları genel olarak engelleyecek bir yol yok ve Buz’un bunu çözdüğüne dair bir iddia da görünmüyor.
  • Bu proje ciddi bir girişimden çok bir meme ya da şaka gibi görünüyor. Mevcut 600 bin satırı yapay zeka tarafından üretilmiş berbat kod diye nitelendiriyor ve alt sistemlerin çoğu yeniden yazılana kadar insanların yazdığı katkıları reddedeceğini söylüyor.
    LLM ile berbat kodu temizlerken insan katkılarını yasaklayan bir projeyi ciddiye almak zor.

• Bun’ın yeniden yazılması sayesinde kod portlama ve yeniden yazma ile dış bağımlılıkları vendoring konusunda çok daha cesur denemeler yapılabildi; upstream projelere uymasa bile iç ihtiyaçlara özel hâle getirilebildi.
  Kodlama modellerine daha iddialı işler verirken aynı zamanda test düzeneklerine ve dil sınırlarının dışındaki doğrulamaya çok daha fazla odaklanıldı. Yıllara yayılan büyük ölçekli yeniden yazımlarda da yer aldım; ancak testleri ve özellik eşdeğerliğini korurken iyileştirmeler de ekleyen Bun’ı muazzam bir mühendislik başarısı olarak görüyorum.

• Bun’ın yeniden yazılması etrafındaki tartışmalarda dramatik suçlamalar ve kişisel saldırılar çok fazla; herkes daha derin ideolojik kaygılarını yansıtıyor gibi. Bu yazı, yapay zekanın programcıların yerini ne kadar başarıyla alabileceği konusunda kuşkucu; Zig bakımcısının argümanı ise LLM çağında açık kaynak etiği ve geleceğine daha yakındı.
  Yapay zeka yeteneklerine iyimser bakanlar açısından, deneyimli bir geliştiricinin son teknoloji LLM’leri yönlendirerek tüm bir kütüphaneyi çevirebileceğinden şüphe etmek için pek neden yok. Daha önemli takip sorusu mevcut maliyet ve ileride yapay zekayı tamamen benimseyenlerle benimsemeyenler olarak ayrışıp ayrışmayacağımız.

  • Ekipte Rust deneyimi olan hiç kimse yoktu.
  • Bun’ın Zig→Rust portu; Zig, Rust, dil portlama ve LLM kullanımı hakkında genellenebilir çok az ders veriyor. Öncesi ve sonrası kod tabanlarında nicelleştirilmesi zor çok fazla özellik var; ayrıca dil, portlama yöntemi ve LLM ile kodlama konusundaki tercihler de işin içine giriyor.
    Aynı sonuç elde edilemezse ya da token maliyeti daha yüksek çıkarsa aracın yanlış kullanıldığı söylenebiliyor; sonuç hayal kırıklığı yaratırsa bunun yalnızca bir kavram kanıtı olduğu ve son 6 ayda modellerin geliştiği için karşılaştırılamayacağı denilerek kaçış yolu bulunabiliyor. Bu yüzden doğrulanabilir sonuçlara ulaşmak zor.
  • LLM’ler makul görünen ama yanlış sonuçlar üretmekte çok başarılı olduğundan kuşkucu olmak için çok neden var. Bu çalışma, sonucun doğru olup olmamasından bağımsız olarak açıkça bir pazarlama etkinliği; Anthropic’in abartılı ya da gerçeğe aykırı duyurular yapmış geçmişi olduğundan daha sıkı doğrulama gerekiyor.

• Zafer ilan eden duyurunun ve dürüst görünen derinlemesine analizin bile biraz aceleci olduğundan şüphelenmiştim.
  LLM çılgınlığının temel riski, yazmaktan ve elle düşünmekten yorulmuş deneyimli geliştiricilere anlık başarı hissi verirken, onlarca yıllık yazılım deneyimini teminat olarak kullandırması. Gerçek maliyet faturası çok daha sonra geliyor.

  • Yazmak, yazılım mühendisliğinde ikincil bir konu; ancak gerçekten yazmanın darboğaz olduğu durumlarda LLM değerli olabilir. Ne var ki bu tür durumlar nadirdir.

• Rust tabanlı Bun’ın 17 Haziran’dan beri Claude Code’da üretimde çalıştığı ve main’e girdikten sonra canary sürüm olarak da sunulduğu bilgisi yazıya yansıtılırsa güvenilirliği artar. Bu ölçekte bir yeniden yazım için uzun bir canary dönemi gayet haklı görülebilir.

  • Yazıda Anthropic’in içeride gerçek kullanımını zaten ele almıştı.

• Anthropic sonraki sürümü herkese açık olarak yayımlamaya pek ilgi duymuyor olabilir. Rust sürümü bir aydan uzun süredir milyonlarca kişinin kullandığı Claude Code’da çalışıyor ve Bun’ı satın alma amaçları da muhtemelen Claude Code’du.
  Açık kaynak projenin kendisi onlar için o kadar önemli olmayabilir.

  • Gerçekten önemli olan sadece Claude Code olsaydı, TypeScript runtime’ının dilini değiştirmek yerine Claude Code’un kendisini Rust ile yeniden yazmak çok daha verimli olurdu. Yaklaşık 800 bin dolarlık maliyet, büyük bir tanıtım etkisi hedefleyen Anthropic’in pazarlama bütçesinden çıkmış olabilir.
  • Daha geniş topluluktan vazgeçmeleri pek olası değil; başka kullanıcılar ne kadar çoksa Anthropic de o kadar fayda sağlar. Bu sürümde sorun çıkarsa sert eleştiri alabilir ve topluluk güveni zedelenebilir, bu yüzden normalden daha temkinli davranıyor gibi görünüyorlar.
  • Bun, web ekosisteminin önemli bir bileşeni olduğundan Anthropic’in bunu yapay zeka ile geliştirmesi başlı başına devasa bir tanıtım etkisi yaratıyor.
  • Claude Code herhangi bir JavaScript runtime’ında çalışabilir gibi görünüyor; neden Bun’a ihtiyaç duyduklarını merak ediyorum.
  • Sonuçta Claude tabanlı kod yeniden yazımının reklamı için bir pazarlama etkinliği gibi görünüyor. Rahatsız edici bir kod tabanından kurtulmak istiyorsanız Anthropic’e yüklü para harcayın mesajı başarıyla verilmiş.
    Amaç Claude Code olsaydı önce onu yeniden yazarlardı; artık doğrudan kod yazmadıklarını vurgulayıp duruyorlarsa uygulama dili de önemli olmamalıydı.

• Yazılım yeniden yazmış olan herkes şu anki aşamayı anlayabilir. Çoğu şey çalışıyor ama regresyon olmaması için sürekli düzeltmek gerekiyor; yayınlama baskısı da çok büyük.
  Yeniden yazma kararının doğru olduğunu düşünüyorum ama bunu en baştan üretim ortamına dağıtmak istemezdim. Jarred doğrudan kararlı sürüm çıkarmak yerine önce sürüm adayı sunarsa yükü azaltabilir.