Bun 1.4: Zig'den Rust'a — Pratikte Ne Değişti?

Bun 1.4, çekirdek kod tabanının Zig'den Rust'a taşınmasıyla gelen ilk sürüm — ve bu, son yıllardaki en büyük JavaScript runtime yeniden yazımlarından biri. Ekip duyuruda bunu doğrudan "And it rewrites Bun from Zig to Rust." cümlesiyle özetliyor. Bu yazıda Bun 1.4 yenilikleri Rust geçişinin kapsamını, Node.js uyumluluk rakamlarını, yeni Bun.WebView ve Bun.cron() gibi API'leri, ölçülen performans kazanımlarını ve hangi işte Bun'ı tercih etmen gerektiğini kaynaklı biçimde inceliyoruz.

💡 Pro Tip: Production'a geçmeden önce bun --version ile pinlenmiş bir sürümü kilitle; 1.4.x hattı hâlâ sık patch alıyor, canary derlemesini asla prod'a alma.

İçindekiler

• Bun'ın kendi cümlesi: "Zig'den Rust'a" — kapsam ve sınır
• Sürüm zaman çizelgesi
• Node.js uyumluluğu rakamlarla
• Bun.WebView: Playwright'ın yerini alır mı
• Bun.Image / Bun.markdown / Bun.Terminal
• Bun.cron() ile zamanlanmış iş katmanı
• Idle CPU, RAM ve başlangıç süresi kazanımları
• Hangi işte Bun, hangi işte Node
• SSS
• Bun 1.4'te neler değişti?
• Bun gerçekten Rust ile mi yazıldı?
• Bun 1.4 Node.js 26 ile uyumlu mu?
• Bun'ın cron ve markdown API'leri production'a hazır mı?
• Bun.WebView, Puppeteer ve Playwright'ın tamamen yerini alıyor mu?
• Mevcut bir Node.js projesini Bun 1.4'e nasıl taşımalıyım?
• Sonuç
• Kaynaklar

Bun'ın kendi cümlesi: "Zig'den Rust'a" — kapsam ve sınır

Bun'ın resmi duyurusu (bun.com/blog/bun-v1.4) geçişi tek cümlede tanımlıyor; taşımanın teknik arka planı ise ayrı bir yazıda, bun.com/blog/bun-in-rust'ta anlatılıyor. Claude Code v2.1.181 (17 Haziran 2026) ve sonrası bu Rust portunu kullanıyor. Aynı yazıya göre taşıma, yorum satırları hariç 535.496 satır Zig kodunu kapsıyor — bu kesin rakam Bun'ın kendi ölçümü.

Burada dikkatli olunması gereken bir nokta var: "tüm runtime artık Rust" gibi bir genelleme, kaynağın kendi cümlesini aşıyor.

Bun'ın kendi ifadesi "Zig'den Rust'a taşıma" — yani belirli bir kapsam. FFI sınırlarında ve bazı düşük seviye katmanlarda hâlâ unsafe Rust bloklarına ve C++ bağlantılarına ihtiyaç var; Bun'ın kendi ölçümüne göre Rust kodunun yaklaşık %4'ü bir unsafe bloğunun içinde (~780.000 satırlık kod tabanında ~27.000 satır) ve bu blokların %78'i tek satırlık — C++'tan gelen bir pointer ya da bir C kütüphanesine tek çağrı. Varsayılan binary konusunda ise belirsizlik yok: Bun v1.4.0, Rust ile yazılan ilk Bun sürümü. Pratik sonuç: geçişi tamamlanmış ama hâlâ olgunlaşan bir taşıma olarak oku ve npm dist-tags.latest üzerinden sürüm sürüm takip et.

Süreç tarafındaki rakamlar Bun'ın kendi yazısında birinci ağızdan duruyor: taşıma 11 gün sürdü, derleyici hatalarının düzeltildiği aşamada iş 64 Claude arasında bölüştürüldü ve merge öncesi maliyet API fiyatlandırmasıyla yaklaşık 165.000 dolar oldu. Aynı yazı rewrite'ın 19 bilinen regresyon doğurduğunu ve bunların her birinin düzeltildiğini söylüyor.

Sürüm zaman çizelgesi

Rewrite'ın "ne zaman, hangi sürümle geldiği" sorusunun cevabı GitHub Releases API ve npm registry üzerinden birebir doğrulanabilir:

v1.3.14 ile v1.4.0 arasındaki 99 günlük boşluk — iki sürümün GitHub Releases tarihinden doğrudan hesaplanıyor — rewrite'ın kapsamının küçük bir iş olmadığının dolaylı bir kanıtı. Kendi ortamında hangi sürümün şu anda "stabil" sayıldığını doğrulamak için npm registry'yi doğrudan sorgulayabilirsin:

1# npm dist-tags — latest ve canary etiketlerini ayır
2curl -s https://registry.npmjs.org/-/package/bun/dist-tags

Node.js uyumluluğu rakamlarla

Bun 1.4, Node.js v26.3.0'ın kendi test paketine karşı çalıştırılıyor ve +1.517 yeni testi geçmeye başladı — bu, Bun 1.0'dan bu yana tek sürümde görülen en büyük sıçrama. Sürüm döngüsü boyunca (1.3 → 1.4) toplam 2.900'den fazla issue kapatıldı. Bunu Rust rewrite'ının kendisinin düzelttiği 128 bug ile karıştırma: 2.900+ rakamı sürüm duyurusunun genel issue kapatma sayısı, 128 ise "bun-in-rust" yazısının verdiği, v1.3.14'te birebir yeniden üretilebilen bug sayısı.

Modül bazında geçme oranları şöyle:

Bazı modüllerde Node'un kendi test setinin %97-100'ü geçiyor. Ama Bun kendisi de netleştiriyor: "Bun henüz %100 Node.js uyumlu değil." Bu sınır, yazının sonundaki "hangi işte Bun, hangi işte Node" tavsiyesinin temelini oluşturuyor — özellikle native addon'a bağımlı veya nadir kullanılan API yüzeylerine ihtiyaç duyan kod tabanları için hâlâ risk var.

Tablodaki node:tls satırı özellikle dikkat çekici: 191/224 ile en düşük geçme oranına sahip modül, yaklaşık %85. TLS/sertifika doğrulama gibi güvenlik-kritik bir katmanda bu oranın Node ile birebir eşleşmediği anlamına geliyor — yani mTLS veya özel sertifika zinciri kullanan bir servisi Bun'a taşımadan önce bu modülü özellikle test etmen gerekiyor. node:quic ve node:fs gibi modüller %97'nin üzerinde olduğu için günlük web servisi senaryolarında (dosya sistemi işlemleri, HTTP/3) risk daha düşük.

Bun.WebView: Playwright'ın yerini alır mı

v1.3.12'de tanıtılıp v1.4.0'da genişletilen Bun.WebView, resmi duyuruda "headless browser automation built into Bun, without Puppeteer or Playwright" ifadesiyle tanımlanıyor. Gerçek kullanıcı girdisiyle (tıklama, scroll) çalışıyor; macOS'ta sistem WebKit'i kullanıyor, üç platformda kurulu Chrome/Chromium/Edge'i CDP (Chrome DevTools Protocol) üzerinden sürebiliyor. İleri düzey senaryolar için bir .cdp() escape hatch'i de mevcut.

Peki bu, test altyapında Playwright'ın yerini alır mı? Kaynak burada net: aynı blog yazısı, Playwright'ın da ayrıca Bun üzerinde çalıştığını ayrı bir bölümde belirtiyor. Yani Bun.WebView, Playwright'ı "emekliye ayıran" bir zorunluluk değil — yerleşik, bağımlılıksız bir alternatif. Basit smoke-test veya scraping senaryolarında puppeteer/playwright bağımlılığını tamamen kaldırabilirsin; çoklu tarayıcı motoru (Firefox/WebKit) gerektiren kapsamlı E2E test matrislerinde Playwright hâlâ daha olgun seçenek. Tam API yüzeyi (metod imzaları, seçenek nesneleri) için resmi Bun dokümantasyonuna bakmanı öneririm.

Bun.Image / Bun.markdown / Bun.Terminal

1.4 döngüsünde art arda eklenen üç yerleşik API, bağımlılık listeni doğrudan küçültüyor:

Bun.markdown'daki sanitizasyon notu önemli: kullanıcıdan gelen Markdown'ı doğrudan Bun.markdown çıktısı olarak sayfaya basıyorsan, XSS'e karşı ayrı bir sanitizasyon katmanı (örneğin DOMPurify benzeri bir araç) eklemen gerekiyor — bu, aracın kendisinin sağlamadığı bir güvenlik katmanı.

Bu üç API'nin ortak paydası, CI pipeline'larındaki bir sınıf sorunu doğrudan ortadan kaldırması: sharp gibi native addon içeren paketler, farklı işletim sistemi/mimari kombinasyonlarında (özellikle Alpine tabanlı Docker imajlarında) derleme sorunlarıyla ünlüdür — glibc/musl uyumsuzluğu, prebuild eksikliği gibi klasik CI arızaları. Bun.Image bu paketi native addon derlemesi gerektirmeden sunduğu için, bu sınıf CI arızasının kaynağı ortadan kalkıyor. Aynı mantık node-pty (Bun.Terminal) ve node-cron (Bun.cron, aşağıda) için de geçerli: üçü de geleneksel olarak platform-spesifik derleme adımı gerektiren paketlerdi.

Bun.cron() ile zamanlanmış iş katmanı

Bun.cron(), zamanlanmış işleri işletim sistemi seviyesinde kaydediyor — yani arka planda Linux'ta crontab, macOS'ta launchd, Windows'ta Task Scheduler ile entegre çalışıyor. İmza tasarımı bilinçli bir tercih: Cloudflare Workers Cron Triggers'daki scheduled(controller) imzasıyla aynı şekilde çalışıyor, böylece Workers'tan gelen bir ekip için öğrenme eğrisi neredeyse yok. Kaynağa göre bu iki kullanım ayrı: aşağıdaki örnekteki gibi bir dosya verildiğinde iş işletim sistemine kaydediliyor; dosya yerine bir fonksiyon geçtiğinde ise iş, sistem cron'u devreye girmeden olay döngüsünde çalışıyor. Yine kaynağa göre işler asla çakışmıyor — bu hüküm her iki kullanım için de geçerli: bir önceki çalışma bitmeden aynı işin ikinci kopyası tetiklenmiyor.

1// Bun.cron() — Cloudflare Workers Cron Triggers ile aynı scheduled(controller) imzası
2export default {
3  async scheduled(controller: { cron: string }) {
4    if (controller.cron === "0 3 * * *") {
5      await runNightlyBackup();
6    }
7  },
8};

Bu, node-cron gibi ayrı bir npm bağımlılığını ortadan kaldırıyor — bağımlılık grafiğinde bir paket daha az demek, tedarik zinciri yüzeyinde bir risk daha az demek.

İşletim sistemi seviyesinde kayıt yapması, geleneksel node-cron yaklaşımından önemli bir farkı işaret ediyor: node-cron işlemin kendi process'i içinde çalışan bir zamanlayıcıdır — process çökerse veya yeniden başlatılırsa, o an tetiklenmesi gereken iş de kaybolabilir. Bun.cron() ise dosya verilen kullanımda kaydı process'in dışına, işletim sisteminin kendi zamanlayıcısına bırakıyor; fonksiyon geçilen kullanımda iş, yukarıda belirtildiği gibi process içinde olay döngüsünde kalır.

Idle CPU, RAM ve başlangıç süresi kazanımları

Rust rewrite'ının en somut vaadi performans. Aşağıdaki tablo Bun'ın resmi duyurusunda geçen rakamları topluyor — hepsi Bun'ın kendi ölçümü, yani birinci taraf kanıt; kendi iş yükünde aynı sonucu göreceğinin garantisi değil, bu yüzden planlamayı bu tabloya göre değil kendi ölçümüne göre yap.

Claude Code örneği önemli çünkü gerçek bir prodüksiyon iş yükü — ama yine de tek kaynaklı (Bun'ın kendisi). Kendi iş yükünde bu rakamları doğrulamak istiyorsan, hem eski hem yeni sürümle aynı senaryoyu kendi ortamında ölçmen gerekiyor; bu yazı sana hazır bir benchmark sonucu vermiyor, ölçüm için hangi komutu çalıştıracağını gösteriyor: aynı projede önce eski sürümle, sonra 1.4 ile time bun run start çalıştırıp iki başlangıç süresini kendi makinende kıyaslayabilirsin.

İki farklı rakamı birbirine karıştırmamak önemli: "5× idle CPU azalması" bir mikro-örnek ("hello world" seviyesinde minimal bir sunucu) için verilmiş, Claude Code'daki %24→%10 ve %5,8→%2,5 rakamları ise gerçek, karmaşık bir prodüksiyon uygulaması için. İkisi de aynı paragrafta geçse de farklı ölçüm koşullarını temsil ediyor — kendi servisin muhtemelen ikisinin arasında bir yerde davranacak, bu yüzden "5 kat hızlanacaksın" gibi bir beklentiyle production planlaması yapma; kendi trafiğinle staging'de ölçüm al.

Hangi işte Bun, hangi işte Node

Tooling tarafında 1.4 döngüsü boyunca 15 npm bağımlılığı Bun'a gömüldü: sharp, puppeteer, marked, node-cron, node-pty, concurrently, npm-run-all, serve-static, json5, fast-xml-parser, tar, string-width, slice-ansi, cli-truncate, wrap-ansi. Pratikte bu şu anlama geliyor: bun run --parallel komutu artık npm-run-all/concurrently'nin yerini tutuyor.

1# concurrently veya npm-run-all yerine
2bun run --parallel build:web build:api build:worker

bun:ffi, TinyCC yerine artık JSC-native çalışıyor ve resmi ölçümlere göre 3× daha hızlı. Native stream implementasyonları WPT (Web Platform Tests) setinin %100'ünü geçiyor; indirme senaryolarında Bun'ın kendi ölçümüne göre Node'a kıyasla ~7,5× throughput — bu son rakam da Bun'ın birinci taraf ölçümü, kendi trafiğinle doğrulamadan mutlak gerçek gibi aktarma.

Bu tooling kazanımlarının pratik anlamı, package.json'daki devDependencies listesinin küçülmesi ve node_modules kurulum süresinin kısalması — özellikle CI'da her build'de sıfırdan bağımlılık kurulumu yapan pipeline'lar için bu doğrudan build süresine yansır. Ama bu kazanımı elde etmek, mevcut kodun bu paketlere doğrudan API çağrısı yapan yerlerini Bun'ın yerleşik eşdeğerine taşımayı gerektiriyor — otomatik bir "drop-in replacement" değil, import satırlarında bilinçli bir değişiklik.

Bu tabloyu Node.js uyumluluk sınırıyla (yukarıdaki bölüm) birlikte oku:

SSS

Bun 1.4'te neler değişti?

Bun 1.4, Zig kod tabanının Rust'a taşınmasıyla geldi; Node.js v26.3.0 test paketinden +1.517 yeni testi geçmeye başladı ve sürüm döngüsü boyunca 2.900'den fazla issue kapatıldı. Bun.Image, Bun.WebView, Bun.markdown, Bun.cron() ve Bun.Terminal gibi yeni yerleşik API'ler eklendi. İdle CPU 5 kat azaldı; bellek kullanımı duyurunun genel özetinde %35'e kadar, HTTP sunucusu çalıştıran uygulamalarda %13-%48 aralığında düştü — bu rakamlar Bun'ın kendi ölçümü.

Bun gerçekten Rust ile mi yazıldı?

Evet — kaynağın kendi ifadesiyle: "And it rewrites Bun from Zig to Rust." 11 gün süren taşımayla 535.496 satır Zig kodu Rust'a çevrildi. Ortaya çıkan Rust kod tabanının yaklaşık %4'ü hâlâ unsafe blokların içinde (~780.000 satırda ~27.000 satır) ve FFI sınırlarında C++ bağlantıları duruyor; yani "her satırı güvenli Rust" genellemesi kaynağın kendi cümlesini aşan bir iddia olur.

Bun 1.4 Node.js 26 ile uyumlu mu?

Bun 1.4, Node.js v26.3.0'ın test paketine göre doğrulanıyor; node:sqlite gibi bazı modüllerde %100, node:http/node:fs gibi modüllerde %95 üzeri geçme oranı var. Ama Node.js 26, 23 Eylül 2026 itibarıyla hâlâ "Current" statüsünde; LTS'e geçişi ayrı bir takvime bağlı. Bu yüzden "LTS uyumlu" demek erken — "Node 26'nın Current test paketiyle uyumlu" ifadesi daha doğru.

Bun'ın cron ve markdown API'leri production'a hazır mı?

Bu API'ler 1.4 döngüsüyle yeni tanıtıldı, yani üretimde uzun bir kullanım geçmişleri henüz yok. Temkinli yol şu: önce staging'de, pinlenmiş bir sürümle test et, sonra prod'a al.

Bun.WebView, Puppeteer ve Playwright'ın tamamen yerini alıyor mu?

Hayır. Bun.WebView, bağımlılıksız ve yerleşik bir headless browser automation seçeneği sunuyor ama aynı kaynak Playwright'ın Bun üzerinde ayrıca çalışmaya devam ettiğini belirtiyor. Basit smoke-test senaryolarında bağımlılığı azaltmak için kullanılabilir; çok tarayıcılı kapsamlı E2E matrisleri için Playwright hâlâ daha olgun.

Mevcut bir Node.js projesini Bun 1.4'e nasıl taşımalıyım?

Sırayla ilerle: önce node:tls gibi düşük geçme oranına sahip modülleri kod tabanında kullanıp kullanmadığını tara, sonra sharp/puppeteer/node-cron/node-pty/concurrently gibi artık Bun'a gömülü paketleri bağımlılık listenden çıkarmayı değerlendir. Ardından CI'da hem mevcut Node hedefini hem yeni Bun hedefini paralel çalıştır, node:tls ve native addon kullanan kod yollarına özellikle dikkat et. Staging'de bir hafta pinlenmiş stabil sürümle bekle, sorun çıkmazsa aşamalı olarak prod trafiğini kaydır. Bu adımların hiçbiri tek seferde "hepsini değiştir" gerektirmiyor — Bun ve Node aynı package.json üzerinde bir süre yan yana test edilebilir.

Sonuç

Bun 1.4, "Zig'den Rust'a" geçişiyle birlikte Node.js uyumluluğunu somut rakamlarla ilerletiyor ve Bun.Image/Bun.WebView/Bun.markdown/Bun.cron()/Bun.Terminal gibi yerleşik API'lerle npm bağımlılık grafiğini küçültüyor. Ama iş bitmiş değil: Bun ekibi kendi ifadesiyle unsafe kullanımını azaltıp kodu idiomatik Rust'a yaklaştırmayı sürdürüyor, CPU/RAM rakamları birinci taraf ölçümü, bazı API'ler yeni ve olgunluğu kanıtlanmamış. Pratik yol: staging'de pinlenmiş sürümle test et, CI'da Bun+Node matrisini paralel tut, üretime aşamalı geç.

Node.js runtime tarafında benzer bir geçiş deneyimini zaten yaşadıysan, Next.js 16.3'te runtime='edge' bitti: Node'a dönüş yazısı runtime kararlarının nasıl geri alınabileceğini gösteriyor. Rust motoruna geçişin ORM tarafındaki karşılığı için Prisma 6'dan 7'ye geçiş: Rust motoru gitti, ne değişti? yazısını oku — aynı "hızlı ama kırılma riski var" örüntüsünü farklı bir katmanda görürsün. Derleyici tarafında paralel bir hikaye için TypeScript 7 çıktı: 10x hızlı ama ESLint kırılıyor faydalı. Build tooling'ini de gözden geçiriyorsan Webpack'ten Vite'a geçiş rehberi adım adım migrasyon planı veriyor; Next.js ekosisteminde güncel kalmak istiyorsan Next.js 16.3 Instant Navigations ve Cache Components rehberi de bu sürümün diğer büyük değişikliklerini kapsıyor.

Kaynaklar

• Bun v1.4 resmi duyuru — Zig'den Rust'a geçiş, Node uyumluluk rakamları, yeni API'ler
• Bun in Rust — teknik arka plan — rewrite'ın teknik detayları
• npm bun dist-tags — güncel latest/canary sürüm etiketleri
• InfoQ: Bun's AI-Assisted Rewrite from Zig to Rust — rewrite'ın bağımsız haber analizi
• Appwrite: Announcing Bun 1.4 — bağımsız entegrasyon duyurusu, API listesi teyidi
• Node.js v26.0.0 release blog — Node 26'nın "Current" statüsü