Claude Code, Rust ile yeniden yazılan Bun kullanıyor

 (simonwillison.net)
2 puan yazan GN⁺ 1 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Claude Code v2.1.181'den itibaren Rust'a taşınmış Bun'u gömülü olarak kullanıyor; bu sayede Linux açılış hızı %10 arttı, ancak çoğu kullanıcı değişikliği neredeyse fark etmedi
  • Çalıştırılabilir dosyadaki string'ler incelendiğinde, henüz resmi etiketi bulunmayan Bun v1.4.0 ve Rust kaynak dosyası yolları görülebiliyor
  • ~/.local/bin/claude içinde src/runtime/bake/dev_server/mod.rs gibi yollar da dahil 563 adet .rs dosya adı bulundu
  • 1.4.0 gömülü sürümü, BUN_OPTIONS ile bir TypeScript dosyası önceden yüklenip Bun.version yazdırılarak da doğrulanabiliyor
  • Rust sürümü Bun canary olarak dağıtıldı ve Claude Code aracılığıyla halihazırda milyonlarca cihazda prodüksiyonda çalışıyor

Claude Code'a gömülü Rust tabanlı Bun

  • Rewriting Bun in Rust yazısına göre, 17 Haziran'da çıkan Claude Code v2.1.181'den itibaren Rust portu kullanılıyor
    • Linux açılış hızı %10 iyileşti
    • Bunun dışındaki farkları kullanıcılar neredeyse hiç fark etmedi; Jarred Sumner bunu “Boring is good” diye değerlendirdi
    • Claude Code aracılığıyla şimdiden milyonlarca cihazda prodüksiyonda çalışıyor
  • Claude çalıştırılabilir dosyasındaki string'ler üzerinden gömülü Bun sürümü bulunabiliyor
strings ~/.local/bin/claude | grep -m1 'Bun v1'
  • macOS arm64 ortamında Bun v1.4.0 (macOS arm64) çıktısı alınıyor
  • O sırada GitHub'daki en güncel resmi sürüm, 12 Mayıs tarihli Bun v1.3.14 olduğundan, Claude Code'un içinde henüz resmi olarak yayımlanmamış bir v1.4.0 önizlemesi bulunuyor
  • Rust sürümü Bun canary olarak yayımlandı ve bun upgrade --canary ile kurulabiliyor

Rust kaynakları ve sürüm doğrulaması

  • Çalıştırılabilir dosyadan Rust kaynak yolları çıkarıldığında 563 dosya adı görülebiliyor
strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'
  • Listede şu yollar da yer alıyor
src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs
  • Ajan Raj'ın paylaştığı yöntemde, bir TypeScript dosyası BUN_OPTIONS ile önceden yüklenerek Claude Code'a gömülü Bun.version değeri doğrudan yazdırılıyor
cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version
  • Bu komutta da 1.4.0 çıktısı alınıyor
  • 17 Mayıs tarihli commit'te package.json sürümü 1.4.0 olarak değiştirildikten sonra aynı kaldı; henüz canary dışındaki etiketli sürümlere dahil edilmiş değil

İlgili okumalar

1 yorum

 
GN⁺ 1 일 전
Hacker News yorumları

  • Bir TUI'nin neden JavaScript üzerinden terminal için React'te çalışması gerektiğini anlamak zor. Anthropic'in TUI'yi iyileştirmek için çalışma zamanını bile satın almış olması, mühendislik kalitesi konusunda daha da fazla şüphe uyandırıyor. Yeniden yazım bu kadar kolaysa, Claude Code'u yerel bir dile taşımak çok daha ucuz olurdu

    • Zaten iyi çalışan ve çok büyük gelir üreten bir iş olduğu için, “neden bu teknoloji?” sorusu teknikten çok iş tercihine yakın. Başta seçilen teknoloji görevini yerine getiriyorsa, mükemmel bir mimari olmasa bile değiştirmek için az neden vardır
      Yeniden yazım Bun için bile kolay değil; API sözleşmeleri ve testleri net olan UI dışı geliştirme araçları, işlevi belirsiz ve testleri yetersiz UI araçlarına göre yeniden yazımdan sonra daha güvenilir olur
    • Claude, OpenCode ve Ghostty'yi birlikte kullanınca etkileşimli terminal programları CPU ve bataryayı ciddi biçimde tüketiyor; gece boyunca uyku modunda kalmış dizüstü bilgisayar bile ısınıyor. curses/ncurses, Emacs, Vim, MS-DOS dahil 40 yılı aşkın emsal varken neden web teknolojilerinin zorla araya sokulduğunu merak ediyorum
    • Ünlü bir Haskell şirketinin, LLM destekli yinelemeli geliştirme hızı nedeniyle Python'a geçtiğini anlatan bir yazı görmüştüm. React için öğrenme verisi çok fazla ve TypeScript derleme süreleri de Rust vb. dillere göre daha kısa
      Kullanıcıya dönük kod ve hızla değişen UX katmanı, hızlı yinelemeli geliştirme yapabilen dinamik sistemlere; altyapı katmanı ise Rust gibi güvenli sistem ortamlarına kayma eğiliminde. Java/C# orta bölgede duruyor ama gelecekte UX için TypeScript/Python yeterli, sistem işleri içinse Rust daha uygun olduğundan konumları daralabilir
      https://avi.press/posts/2026-07-10-after-7-years-in-producti...
    • Anthropic'in Claude Code'u yapay zekayla yazdığını varsayarsak, JavaScript de kötü bir seçim değil. Eğitim verisi bol ve diğer yüksek performanslı dillerde yapay zekayı şaşırtabilecek çoklu iş parçacığı ve bellek yönetimi sorunlarından da kaçınıyor; bu yüzden yapay zekayla hızlı yazılım üretmeye uygun
    • OpenAI yaklaşık bir yıl önce Codex'i Rust ile yeniden yazmaya karar verdi. Yeniden yazım gerçekten bu kadar kolaysa, neden Bun'a ihtiyaç olduğu ve neden tüm JavaScript kodunun Rust'a taşınmadığı da sorulmalı
      https://github.com/openai/codex/discussions/1174

  • Jarred'in orijinal yazısına bakınca, Zig'de elle yapılan bazı işlerin Rust'ta otomatikleşmesinin geçiş nedeni olduğu açık görünüyor. Hem insanlar hem ajanlar deterministik olmadığından, Zig'in bellek ömrünü ve açık serbest bırakmaları elle takip etmek, atlanan hataların uzun süre birikmesine yol açabiliyor; Rust ise bu hata sınıfını ortadan kaldırarak mühendislik yönetimi açısından iyi bir ödünleşim sağlıyor
    Özellikle derleyici hataları, kodlama ajanları için gerekli deterministik emniyet mekanizmasıdır; Claude'a doğruluğu sınayacak bir yöntem ve “derlenecek hale getir” hedefi verildiğinde iyi çalışıyor. Olasılıksal çıktıları deterministik testlerle sağlam güvencelere çeviren genelleştirilmiş yaklaşım https://michael.roth.rocks/blog/verification-surface/ içinde özetlenmiş

    • Zig ve C, ömürleri birbirinden bağımsız çok sayıda küçük tahsis üretildiğinde pek uygun değil. Sağlam kullanmak için tahsisleri arena içinde gruplamak ya da sabit tamponlar kullanmak gibi yollarla ömürleri doğrudan yönetmek gerekiyor
      Böyle yapılırsa Zig de Rust kadar sağlam olabilir, ama LLM'nin tercih ettiği yönetilen dil tarzı tahsis desenlerini istiyorsanız Zig uygun değil
    • Bunu otomatik yapan şey çöp toplayıcılı dillerdir. Rust'ta da bellek ömürlerini düşünmek ve izlemek gerekir; ancak borrow checker yanlış işlemleri engeller ve anında düzeltme geri bildirimi verir, bu da LLM'nin yazmasını kolaylaştırır. Varsayılan değişmez referans parametreleri de büyük performans sorunlarını önler
    • Şu anda Bun içinde çok fazla unsafe Rust varken, hata sınıflarının otomatik kaldırıldığını söylemenin mümkün olup olmadığı şüpheli: https://news.ycombinator.com/item?id=48967630
    • Benim deneyimimde LLM'ler bellek hatalarını oldukça kolay yakalıyor. Bu olay daha çok Anthropic'in başarılı bir pazarlama etkinliği gibi görünüyor
    • Bu Rust yeniden yazımının tamamen unsafe olduğunu hatırlıyorum; dolayısıyla söz konusu sorunu otomatik olarak ortadan kaldırmıyor olabilir

  • Jarred ya da Simon Willison'ın değerlendirmelerinden bağımsız olarak, bu olaya oldukça olumsuz bakıyorum. Anthropic'in Bun'ı satın alması veya yapay zekayla yeniden yazımdan daha büyük sorun, “sadece benim branch'im ve aşırı tepki veriyorsunuz” tavrıyla başlayıp 1 milyondan fazla satırlık bir PR'ın bir aydan kısa sürede birleştirilmesi gibi olgunlaşmamış bir ilerleme tarzıydı
    İletişimi çok kötü yöneterek güveni zedelediler ve ayrışmayı büyüttüler; TypeScript ekibinin 7.0'da izlediği yaklaşımı benimsemek gerçekten bu kadar zor muydu diye düşünüyorum

    • Sonuçta Claude Code kullanıcılarının çoğu bunu fark etmemiş ya da umursamamış olabilir; sorun eden taraf çok küçük bir azınlıksa pratikte önemli olmayabilir
    • TS7 de mimariyi ciddi biçimde gözden geçirmekten çok başka bir dile satır satır taşınmış tipik bir örnek

  • Claude içinde yer alan Bun v1.4.0, henüz yayımlanmamış bir önizleme sürümü gibi görünüyor. Eğer öyleyse, FOSS projesi Bun sessizce başka bir şeye dönüşmüş gibi; araştırmayı sadece TODO'ya yazıp benimsememiş olmama sevindim
    Bun'ın yönetişim belgelerini bulamıyorum; artık fiilen Anthropic'in hem yapılan işi hem de neyin birleştirileceğini belirlediği bir yapı mı var diye merak ediyorum

    • Rust'a geçmenin projenin öldüğü anlamına geldiği sonucunu anlamakta zorlanıyorum
    • PR herkese açık; isteyen herkes derleyip kullanabilir ve Anthropic ekibi sadece önce kullanmayı seçmiş durumda
    • Bildiğim kadarıyla yapı fiilen Jarred'in o hafta kabul etmeye istekli olup olmamasına bağlı. Claude Code değişiklik kayıtlarında Bun 1.4.0 sürüm değişikliği neredeyse bir aydır yazıyordu ama kayıtlar yapay zeka tarafından yazıldığı için çoğu kişinin okumamış olması da şaşırtıcı değil
    • Ben de Bun kullanımını araştırmış ama istikrarsızlık nedeniyle kullanmamaya karar vermiştim; bu olay da bunun doğru karar olduğunu düşündürüyor

  • Bunun neden Bun etrafında bu kadar dolaylı biçimde ele alındığını anlamıyorum. Eğer ajan Zig'i Rust'a taşıyabiliyorsa, Claude Code da JavaScript'ten doğrudan Rust'a yeniden yazılarak çalışma zamanı bağımlılığı kaldırılabilir ve performans artırılabilirdi

    • Bun'ın Rust'a yeniden yazılmasının Anthropic'in ürün stratejisiyle fiilen hiçbir ilgisi olmadığını düşünürseniz, kafa karıştırıcı bir tarafı kalmaz
    • Yalnızca Claude Code açısından bakarsak Rust'a doğrudan yeniden yazım daha iyi olurdu, ama o zaman Bun/oven.sh satın alımının değeri ciddi biçimde azalırdı
      Bun'ın Claude Code dışında da hem dışarıda hem Anthropic içinde kullanıcıları olacaktır; ayrıca kodlama modellerinin tercih edebileceği bir JavaScript çalışma zamanı ve araç ekosistemi kazandırır. İleride Anthropic bu tür uygulamaların çalıştırılması ve yönetimine özel bir bulut bile sunabilir; yalnızca geliştirici topluluğunu kazanması bile Claude Code'u tek başına Rust'a taşımaktan çok daha büyük etki yaratır
    • Claude Code'un gerçekten performans darboğazı yaşayıp yaşamadığı da şüpheli. JavaScript çalışma zamanının araç ekosistemi büyük ve eklenti geliştirmek kolay, bu yüzden fazlasıyla uygun

  • Tahminleri ve duyguları bir kenara bırakırsak, asıl merak ettiğim gerçek çalışma kalitesi. Sadece açılış hızı değil, RAM ve CPU kullanımı ile sonsuz döngü ya da deadlock olup olmadığı da görülmeli; öncekiyle aynı ya da daha iyiyse oldukça etkileyici
    Bir geliştirici olarak yapay zekanın işleri elimizden alma ihtimalinden hoşlanmıyorum, ama herkes yalnızca basit isteklerle istediği yazılımı üretebilirse dünya iyileşebilir. Microsoft'un veri toplamasını sevmiyorsanız işletim sisteminizi, Google'ın dinlemesini sevmiyorsanız telefonunuzu yapay zekaya yaptırabileceğiniz bir teknolojik öz yeterlilik mümkün olabilir; bunun yanında bireysel iş güvencesi önemsiz kalır
    Bu yüzden teknolojinin açık kaynak kalması daha da önemli; aksi halde mevcut tekelleşme yapıları tekrar ederken işleri de kaybederiz

    • Yazılım geliştirmedeki en zor kısım net gereksinimler elde etmektir. Kusursuz bir AGI olsa bile insanlar ne istediklerini açıkça ifade edemediği için herkesin tam istediği yazılımı ürettiği bir dünya gelmeyecek
    • İyi araçlar bile ancak usta ellerde mükemmel sonuç verir. İyi geliştiriciler doğru soruları sorar, güvenlik önlemleri kurar ve gereken yerde çıktıyı bizzat ayarlayabilir
    • Şu anda sübvansiyon alan ücretli duvarların arkasındaki kapalı modeller için buna teknolojinin demokratikleşmesi demek fazla safça. Bun'ın Rust portunu ağırlıkla pazarlama amacıyla kullanan strateji belli ki işe yaramış

  • Kısa süre önce Kitty sekmesi içinde Claude Code kullanırken segmentation fault yaşadım ve ardından sekmenin tamamı girdiye tepki vermemeye başladı. Bir bildirim bağlantısı çıkıyor ama tıklanamıyor ve kodlanmış olduğu için hangi bilgilerin gönderildiği de görülemiyor

    • Bun fikir ve özellikler açısından diğer JavaScript çalışma zamanlarından ezici biçimde daha iyi, ama kararlılığı berbat ve Node'a kıyasla yaklaşık 20 kat daha fazla segmentation fault yaşattı. Bu sayı New Relic telemetri verilerine dayanıyor
    • Kabukta Segmentation fault yazmadıysa bunun segmentation fault değil donma olması daha olası. Gerçekten öyle bir hata ise kabuğa döndükten sonra ekranda görünmese bile reset yazarak sekmeyi kurtarabilirsiniz
    • İş için kullandığım MacBook'ta Ghostty ve Claude Code kullanıyorum ama bu sorunu henüz yaşamadım. Eskiden kontrolden çıkan bir bellek sızıntısı yüzünden sistem donup yeniden başlatmak zorunda kalıyordum; son birkaç haftadır bu kayboldu. Kesin konuşmak için erken ama Rust portunun bellek sızıntısını azaltmış olması mümkün
    • Ghostty'de Claude'un etkileşimli soru arayüzünü kullanırken benzer şekilde donuyor; kaydırma dışında seçim veya iptal dahil hiçbir girdiyi kabul etmiyor. Yine de bunun Bun'la ilgili olduğunu düşünmüyorum
    • Zig sürümünde de segmentation fault vardı; bunu unsafe Rust ile satır satır taşıdılarsa soruna yol açan kod da aynen kalmıştır. Ancak bunu deyimsel ve bellek güvenli Rust ile yeniden düzenleyene kadar çözülmez

  • Bunlar, sorunu iyi tarif edip token bütçesi sınırsız olan, büyük başarı kazanmış ama kötü mühendisler gibi görünüyor. Token maliyetini kendileri ödüyor olsalardı yazılım verimliliğini artırmak için mali teşvikleri olurdu
    Yapay zeka veri merkezlerinin gizli gerçeği, GPU kümesi verimliliği sadece %40-60 olsa bile bunu daha fazla donanım satın alarak telafi etmeleridir. Çinli rakiplerden korkmalarının nedeni, onlar gibi savurgan davranacak paya sahip olmamaları olabilir

  • Bu iş aslında bir transpile ve kalite de iyi değil. Üretilen kod deyimsel Rust'tan çok uzak; ucube denebilecek kadar kötü

    • Yine de düzgün çalışıyor gibi görünüyor. Bu kez temelde satır satır mekanik bir ilk taşıma yapıldı; sonraki aşamada deyimsel Rust'a dönüştürülecek, bu yüzden bu yeniden yazıma karşı sürekli ters yönde iddiaya girmek pek mantıklı görünmüyor
    • Kararlılık, verimlilik ve maliyet düşünülürse, özgün yapıyı mümkün olduğunca koruyan bir kaynaklar arası dönüştürücü kullanmak ya da yazmak çok daha mantıklı olurdu
      Normalde yeniden yazımlarda mevcut kod tabanından çıkarılan dersler yansıtılır, ama ajanla dosya dosya port edilirse bu avantaj olmaz. Her iki durumda da ortaya deyimsel olmayan bir çeviri çıkar, fakat LLM kullanınca buna bir de belirlenimsizlik ve devasa maliyet eklenir
    • Ucube denilen Rust koduna dair somut örnekler gerekli
    • Neden doğrudan LLVM IR'a transpile edilmediğini merak ediyorum
    • Proje bellek güvenliği hedefini tutturursa, kodun deyimsel olup olmamasının gerçekten ne kadar önemli olduğu tartışılır

  • Son zamanlarda Claude Code eskisine göre çok daha kararsız ve TUI render hataları yüzünden konuşma geçmişi sık sık bozuluyor

    • Şubattan beri isteksizce Claude kullanıyorum; en başından beri render kusurları, klavye giriş hataları gibi şimdiye kadar kullandığım TUI'lar arasında en kötüsüydü. Buna rağmen son bir haftada daha da kötüleşti ve yazdığım bazı karakterlerin görünmemesi gibi sorunlarla terminal oturumlarını bile bozmaya başladı
      Arka plana alıp reset çalıştırdıktan sonra tekrar ön plana getirince düzeliyor. Claude'dan teşhis istedim; kendisinde böyle bir hata olmadığını ve başka bir programın suçu olduğunu söyledi, ama yalnızca tmux ile Claude çalışıyordu. Yakın zamanda Rust sürümü devreye alındıysa kalite düşüşünün zamanlaması kabaca örtüşüyor
    • Windows'ta pencere boyutunu her değiştirdiğimde çıktı tamamen bozuluyor ve az önceki yanıtı yeniden istemek zorunda kalıyorum. Yeni bir sorun değil ama son zamanlarda daha da kötüleşmiş gibi
    • Yapay zekanın kendisine karşı değilim, ama Anthropic işi fazla ileri götürüp yapay zekanın ürettiği düşük kaliteli kodu yayımlıyor. Gerçek mühendislerin araca yön vermek için sürece dahil olmaya devam etmesi gerekirken, Anthropic sanki kodun %100'ünü yapay zekaya bırakmak istiyor gibi