Bun (JS çalışma zamanı) Zig'den Rust'a vibe port ediliyor

 (github.com/oven-sh)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Bun'ın kurucusu Jarred Sumner, Zig → Rust port rehberini (PORTING.md) claude/phase-a-port dalına commit ederek, yapay zeka ajanlarıyla gerçekleştirilen büyük ölçekli bir dil dönüşümü denemesini kamuya açtı
  • Port süreci Phase A (dosya bazında yalnızca mantığın ilk çevirisi, derleme gerekmiyor) ve Phase B (crate bazında derlemeden geçme) olarak ayrılıyor; LLM'lere yaklaşık 300 tip ve deyim eşleme kuralı veriliyor
  • Sumner, Hacker News'te "yeniden yazımın kesinleşmediğini ve bu kodun tamamının büyük olasılıkla çöpe gidebileceğini" bizzat belirterek, şu aşamada bunun deneysel bir keşif süreci olduğunu söyledi
  • Toplulukta, Anthropic satın alımı sonrası Zig'in yapay zeka katkı yasağı politikası ile yaşanan gerilim, Bun'ın hâlihazırda Zig'i fork edip işletmesi ve Rust ekosisteminin güvenlik avantajları bu sürecin arka planı olarak anılıyor
  • PR'lerin çoğu @robobun (AI botu) tarafından otomatik oluşturuluyor ve CodeRabbitAI ile Claude tarafından inceleniyor; bu da yapay zeka odaklı büyük ölçekli kod göçlerinin pratikteki imkânlarını ve sınırlarını gösteren bir örnek sunuyor

Port rehberinin (PORTING.md) temel yapısı

  • Port hedefi, tek bir Zig dosyasını aynı dizinde bir .rs dosyasına dönüştürmek; Phase A'da amaç mantığın sadık biçimde yeniden üretilmesi, derlenip derlenmemesi ise önemsiz
  • tokio, rayon, hyper, async-trait, std::fs, std::net gibi harici asenkron ve I/O crate'lerinin kullanımı yasak — çünkü Bun kendi event loop'unu ve syscall'larını kendisi yönetiyor
  • async fn yasak; tüm asenkron işlemler Zig'dekiyle aynı şekilde callback + state machine yaklaşımıyla korunuyor
  • Emin olunmayan bölümler // TODO(port):, performansla ilgili Zig deyimleri ise // PERF(port): ile işaretlenip Phase B'de ele alınıyor

Tip ve deyim eşleme kuralları

  • []const u8 → &[u8] (asla &str değil), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error> gibi 50'den fazla tip eşleme tablosu sağlanıyor
  • defer x.deinit() → silinip yerine impl Drop, errdefer → scopeguard, comptime → const generic, const fn, macro_rules! dönüşümü
  • String'lerde ilke bayt tabanlı işleme: Bun WTF-8 ve keyfi baytlarla çalıştığı için std::string::String ya da &str kullanımı yasak, bunun yerine &[u8] / Vec<u8> kullanılıyor
  • @intCast → T::try_from(x).unwrap() (daima kontrol edilir), @truncate → x as T (bilinçli wrapping), @bitCast → transmute gibi Zig yerleşik fonksiyonlarının Rust karşılıkları tanımlanıyor

Crate haritası ve sahiplik modeli

  • @import("bun").X gibi Zig namespace'leri bun_str, bun_sys, bun_jsc, bun_alloc gibi yaklaşık 30 Rust crate'ine bire bir eşleniyor
  • AST/parser crate'leri bumpalo::Bump arena yapısını koruyor; diğer crate'lerde ise allocator parametreleri kaldırılıp global mimalloc allocator kullanılıyor
  • bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T> gibi pointer sahipliği eşlemeleri bulunuyor

Topluluk tepkileri (Lobsters · HN)

  • "Gerçekten Rust'a mı geçiliyor, yoksa bu Anthropic LLM'leri için bir vitrin mi?" sorusunu soran çok sayıda yorum var
  • Zig'in yapay zeka katkı yasağı politikası ile Anthropic'in yapay zeka merkezli geliştirme iş akışı arasında bir çatışma olabileceği yönünde tahminler yapılıyor; ancak bunun komplo teorisi düzeyinde kaldığını söyleyenler de var
  • Yaklaşık 300 kuralın LLM tarafından ne kadar sadakatle uygulanabileceğine dair şüpheler mevcut — buna karşılık "~16k token, alt ajanlar için makul bir boyut" diyen olumlu görüşler de var
  • "Phase A'da önce derlenmeyen kod üretme" yaklaşımının mevcut kodlama ajanı kullanım biçimlerinin tam tersi olduğu yönünde ilginç bir gözlem öne çıkıyor
  • Bun'ın Zig fork'unu sürdürme maliyeti, Zig'deki sık breaking change'ler ve henüz beta aşamasındaki bir dile çekirdek ürünü bağımlı kılmanın riski de geçiş motivasyonları arasında sayılıyor

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Lobste.rs görüşleri

  • Bu arada Jarred Sumner’ın bu konuda HN’de söyledikleri şöyleymiş: Kendisi Bun geliştiricisi, bu onun kendi branch’i ve bu başlık çalışmayan koda verilmiş aşırı bir tepki niteliğinde.
    Henüz yeniden yazılmasına karar verilmiş değil, hatta bu kodun tamamının çöpe gitme ihtimali de çok yüksekmiş.
    Çalışan bir sürümün nasıl görüneceğini, performansının nasıl olacağını, Bun test paketini geçip geçemeyeceğini ve bakımının ne kadar zor olacağını görmek; ayrıca uygulanabilir bir Rust sürümü ile Zig sürümünü yan yana karşılaştırmak istediğini söylüyor.

    • “Yalan, gerçek ayakkabılarını giymeden dünyayı yarım tur dolaşır” sözü aklıma geldi.
      Popüler kültür tarzı teknoloji yorumları çoğu zaman anlık tepki üzerine kurulu oluyor.

  • Bun’un sıradan pull request’leri bile epey kaotik: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
    Çoğunu @robobun otonom olarak açıyor, GitHub Actions ile tekrar olup olmadığı kontrol ediliyor (Claude tabanlı) ve @coderabbitai ile @claude inceleme yapıyor.
    Bu sırada CI bozuk durumda ve @robobun da kendi açtığı başka PR’larla çakıştığı gerekçesiyle bazı PR’larını sonunda kapatıyor.
    main’e birleştirme işini hâlâ insanlar yapıyor.

    • Bunu beklemiyordum.
      Bun’un, Jarred’ın performans takıntısı sayesinde övüldüğünü hatırlıyorum ama kod tabanında LLM’lerin bu kadar ortalığı karıştırmasına izin vereceklerini düşünmemiştim.

  • Bu saçmalık.
    “İdiom eşleme”ye bakınca her yer unsafe dolu ve büyük miktarda Rust’a benzemeyen kod çıkacak gibi görünüyor.
    Özellikle @fieldParentPtr("field", ptr) eşlemesi çok kaba duruyor.
    Ama galiba “phase A” fiilen satır satır çeviri ve sonrasında prompt’larla bunu daha idiomatik, daha bakımı yapılabilir Rust’a dönüştürmeyi planlıyorlar.
    Sorun şu ki dil tasarımı uygulamanın yönünü güçlü biçimde etkileyebilir ve etkiler de; bu yüzden sonradan çözmesi zor düğümler oluşma ihtimali yüksek.
    Sonuçta eski usul elle yeniden yazım daha iyi yol olurdu gibi geliyor.

    • İdiomatik ve güvenli koda dönüştürme işini sonraki aşamada LLM yapabilir gibi duruyor.
      Özellikle Anthropic seviyesinde bütçeyle, yapay zekanın rahat tarafı aynı kodu tekrar tekrar refactor etmekten yorulmaması.

  • Migrasyonun kendisinden bağımsız olarak, seçtikleri yöntem özellikle ilginç.
    Bağlantısı verilen docs/PORTING.md içinde yaklaşık 300 portlama kuralı var ve herhangi bir LLM’in bunların hepsini “hatırlayıp” sadakatle uygulaması için bu sayı fazla gibi görünüyor.
    Anthropic Bun’un sahibi olduğuna göre bu portlama işi için fiilen sonsuz bir token bütçesi vardır; belki de dosya sayısı * kural sayısı kadar ajan çalıştırıp hepsine uyulduğunu “garanti” etmeye çalışıyorlardır.
    Ayrıca portlamayı iki aşamaya bölmüşler: A, her dosyayı izole halde kaba biçimde portluyor ve derlemenin bozulması bekleniyor; B ise hepsini birbirine bağlayıp derlenebilir hale getiriyor.
    Phase A’da ajana kodun “derlenmek zorunda olmadığını” söylüyorlar ve her portlanan dosyayı çıktı kalitesine göre düşük/orta/yüksek diye puanlatıyorlar.
    Düşük, mantığın yanlış olduğu; orta, mantığın doğru ama kodun derlenmediği; yüksek ise hem mantığın doğru olduğu hem de derlenebilir göründüğü anlamına geliyor.
    Bu, benim anlayıp kullandığım kodlama ajanı yaklaşımının tam tersi; o yüzden sonucu merak ediyorum.
    Bana kalırsa derlenmesi gerekmeyen bir işe net bir “bitiş hedefi” verilmezse sonuçlar çok öngörülemez olur ve phase B’de güvenilmez kod dağlarını gözden geçirmek gerekebilir.
    Hızlıca grep’leyince bu çıktı kalitesi puanlarından 1279 tanesinin yaklaşık %3’ünün düşük, %80’inin orta, %17’sinin yüksek olduğunu gördüm.

    • Mayıs 2026 itibarıyla 300 kural gayet makul görünüyor.
      PORTING.md yaklaşık 16k token ve ana işe odaklanmış.
      Yeni alt ajanlar için kötü değil, hatta muhtemelen ideal bile olabilir.

  • Acaba gerçekten Rust’a geçmek mi istiyorlar, yoksa bu Anthropic LLM testi mi?

  • Oldukça ilginç görünüyor.
    Tek seferde ele alınması gereken kural kümeleri, devasa kod inceleme döngülerinden geçmeden doğrulanamaz gibi duruyor.
    Token çok olabilir ama böyle bir dönüşümden sonra kodu fiilen doğrulamak çok zorlaşacak gibi.
    Testlerin de aynı süreçten geçmesi gerekiyorsa sonunda hakikatin ölçütü olarak ne kaldığı belirsiz.
    Yine de deney olarak etkileyici.

  • Node.js katillerinin ne yaptığına bakınca, Deno izin sistemi ya da varsayılan TypeScript desteği gibi ufak iyileştirmeler sundu ama dünyayı yerinden oynatamadı; üstelik bu özellikler de Node.js’e geri taşınıyor.
    Kendi kullanımımda geliştirici deneyimi anlamlı biçimde daha iyi gelmedi, hatta pnpm gibi harika araçlar yüzünden bazı durumlarda daha kötüydü.
    Daha hızlı olabilir ama son 5-6 yılda kendi kullanım alanımda Node.js performans sorunlarını pek hissetmedim.
    JSR de dünyayı sarsmadı, topluluk onun yerine daha iyi deneyim sunan now npmx’i yaptı.
    Buna karşılık Deno’nun standart kütüphanesi, örneğin @std/collections, oldukça iyi ve kullanıyorum.
    Bun, kapsamı fazla geniş olduğu için en baştan beri birçok risk işareti taşıyordu ama Jarred’ın birkaç yıl sürse bile en iyi genel amaçlı JS runtime’ını yapmaya çalıştığını düşünüp temkinli biçimde iyimserdim.
    Ancak Anthropic tarafından satın alınması, Jarred’ın artık epey fazla ~~vibe coding~~ ajan tarzı geliştirme yapıyor görünmesi ve şimdi de bu vibe porting haberi, deneysel bir branch olsa bile bunun benim kullanacağım bir proje olmadığı yönündeki kanaatimi pekiştirdi.
    Bu yüzden Node.js hâlâ hüküm sürüyor.
    Ciddi konuşmak gerekirse yerleşik TypeScript özellikleri ve SQLite etkileyici.
    Tam anlamıyla yapay zeka karşıtı değilim; çok belirli bir sorunu çözmek için küçük Python script’leri ya da web uygulamalarını vibe coding ile üretmek eğlenceli ve faydalı olabilir.
    Ama çok sayıda hareketli parçası ve kullanıcısı olan karmaşık projelerde büyük ölçekli “ajan tarzı geliştirme”, özellik geliştirmeyi geçici olarak hızlandırsa bile sonunda projeyi istikrarsızlaştıran ve şişiren bir net zarar gibi geliyor; buna dair kanaatim tekrar tekrar güçleniyor.
    VSCode, Cursor, mise, Perplexity web arayüzü gibi örnekler aklıma geliyor.
    Kaydırırken takılmayan tek bir JS dropdown yapmak bu kadar mı zor?
    Dayandığım daha fazla büyük araç, kütüphane ve projenin bunu fark edip daha katı yapay zeka karşıtı politikalar benimsemesini umuyorum.

  • Bu düpedüz yanlış yön.
    Orta ölçekli, yani yüz binlerce satır ve üzeri Rust projesi bakımını yapan ve büyük kod tabanlarında ölçeklenebilirlikten memnun olan tek bir Rust bakımcısı bile görmedim.

    • Tanıştığımıza memnun oldum.
      Bence Rust büyük kod tabanları için özellikle harika:
      https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
      https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
      Tabii verimli kullanmak için ne yaptığını belli ölçüde bilmek gerekiyor:
      https://matklad.github.io/2021/09/05/Rust100k.html
      Bu bağlamda Zig’in Rust’a kıyasla nasıl olduğunu pek bilmiyorum.
      TigerBeetle’ın tasarım yaklaşımı oldukça özel.
    • Arka plan olarak, 10k ile 100k satır arasında yaklaşık 6 Rust kod tabanının bakımını yaptım ama 100k’yı aşan olmadı.
      Ayrıca 20k satırlık bir Rust programının 300k satırlık bir Go programının temel işlevlerini gerçekleştirdiği birkaç örnek de biliyorum.
      Yani tam olarak belirtilen koşullara uymuyorum.
      Ama 10k-100k satır aralığında bir bakımcı olarak Rust’tan çok memnunum.
      Bu ölçek, programın yeterince odaklı kalacak kadar küçük ama tek bir temel fikri hakkıyla hayata geçirecek kadar büyük olduğu bir nokta.
      Bu büyüklükte hem dilin kendisi hem de araçlar büyük avantaj oldu; en azından benim kişisel deneyimimde durum böyleydi.
    • cargo-nextest şu anda yorumlar ve boş satırlar hariç 84k satır Rust kodu ve tek bakımcı olarak bunu kendi kalite standartlarıma göre başka bir dilde yazmanın mümkün olmadığını düşünüyorum.

  • Muhtemelen sebep bu olabilir: https://github.com/oven-sh/bun/issues/28001

    • Rust’ın bunu tam olarak nasıl yakalayacağını açıklamanızı isterdim.
      Bu bir zamansal bellek güvenliği sorunu değil.