Bun konusunda endişeliyim

 (wwj.dev)
4 puan yazan GN⁺ 7 시간 전 | 3 yorum | WhatsApp'ta paylaş
  • Bun, hızlı bir JavaScript runtime'ı ve TypeScript çalışmalarını kolaylaştıran bir araç; ancak Anthropic'in Aralık 2025'teki satın alımından sonra ürün politikası ve işletim tarzından etkilenebileceğine dair endişeler büyüyor
  • Satın alma duyurusunda Bun'ın açık kaynak ve MIT lisansını koruyacağı, aynı ekibin geliştirmeyi sürdüreceği belirtildi; ayrıca Claude Code'un Bun çalıştırılabilir dosyası olarak dağıtılması nedeniyle Anthropic'in Bun'ı istikrarlı tutmak için doğrudan bir motivasyona sahip olduğu söylendi
  • Nisan 2026'dan sonra Claude Code için kalite düşüşü, kısıtlayıcı davranışlar, üçüncü taraf harness kısıtlamaları, faturalandırma karmaşası ve yavaş iletişim sorunları gündeme geldi; Anthropic'in engineering postmortem yazısı bunun nedenini varsayılan muhakeme eforu değerinin düşürülmesi ve prompt değişiklikleri gibi ürün katmanı sorunları olarak gösterdi
  • TechCrunch ve Gigazine haberlerine göre Claude Code, OpenClaw gibi üçüncü taraf harness desteği için ek ücret isteyebiliyor veya git geçmişinde yalnızca OpenClaw ifadesinin geçmesi bile isteğin reddedilmesine ya da ek ücretlendirme davranışının tetiklenmesine yol açabiliyor; bu da beklenmedik davranışları ortaya koyuyor
  • Kaygıyı yaratan şey Bun'ın kendisi ya da Bun ekibinin kalite sorunu değil; Anthropic'in politikalarının Bun'a sızma ihtimali. Bu yüzden bazı projeler paket yönetimi için pnpm'e geçiyor ve yeni JavaScript·TypeScript projelerinde de pnpm önerilmeye başlanıyor

Bun hakkındaki kaygının büyümesinin arka planı

  • Bun, küçük script'ler, uygulamalar, testler ve araçlarda TypeScript ile çalışmayı kolaylaştıran hızlı ve pratik bir JavaScript runtime'ı
  • Hızlı kurulum, hızlı testler, daha iyi bundling ve daha hafif araç zinciri yükü nedeniyle Node.js alternatifi olarak başarılı olması beklenen bir araç
  • Endişenin odağı Bun'ın kendi kalitesi değil; Bun'ın Anthropic bünyesine girdikten sonra ürün politikası ve işletim tarzından etkilenebilir olması

Anthropic satın alımı ve ilk beklentiler

  • Anthropic, Aralık 2025'te Bun'ı satın aldı
  • Duyuruya göre Bun, açık kaynak ve MIT lisansı olarak kalacak; aynı ekip geliştirmeyi sürdürecek ve yol haritası da yüksek performanslı JavaScript araçları ile Node.js uyumluluğuna odaklanacak
  • Duyuruda şu cümle yer alıyordu: “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”
  • O dönemde Claude Code Bun üzerinde çalıştığı için, Anthropic'in Bun'ı hızlı ve istikrarlı tutmak konusunda doğrudan bir motivasyona sahip olduğu düşünülebiliyordu
  • Bu mantık hâlâ geçerli, ancak Anthropic'in yazılım ürünlerini işletme biçiminde çatlaklar görünmeye başlamış olabileceğine dair bir kaygı oluştu

Claude Code'a dair değerlendirmenin değişmesi

  • Asıl kaygı, Anthropic'in model kalitesinin kendisi değil
  • Claude Opus 4.6 olduğu tahmin edilen model ailesi, kodlama, yazma, muhakeme ve genel geliştirme işleri için hâlâ güçlü bir model grubu olarak değerlendiriliyor
  • Sorun, modelin etrafındaki ürün katmanı; asıl nokta da Claude Code'un kullanım deneyiminin ciddi biçimde kötüleşmiş olması
  • Yaklaşık bir yıl önce Claude Code; projeyi okuyabilen, odaklı değişiklikler yapabilen, komut çalıştırabilen, hatalarını düzeltebilen ve ilerlemeye devam edebilen bir araç gibi hissettiriyordu
  • O dönemde Claude Code, geliştirici iş akışının otomatik tamamlama merkezli yapıdan ajan merkezli yapıya kayabileceğine güven veren ilk yapay zeka kodlama araçlarından biriydi
  • Aralık 2025'te bile Claude Code zaten kötüleşmeye başlamıştı, ama yine de kullanılabiliyordu; Bun satın alımı da Anthropic'in kodlama araçlarının geleceğini inşa ettiği perspektifinden bakınca makul görünüyordu

Nisan 2026'dan sonra Claude Code sorunları

  • Nisan 2026'da geliştiriciler Claude Code'un kalite sorunlarını, kısıtlayıcı davranışlarını, üçüncü taraf harness kısıtlamalarını, kafa karıştırıcı ücretlendirmesini ve yavaş iletişimini eleştirmeye başladı
  • Anthropic, engineering postmortem yayımladı ve neden olarak varsayılan muhakeme eforu değerinin düşürülmesi, eski oturum hataları ve kodlama kalitesine zarar veren prompt değişiklikleri gibi ürün katmanı sorunlarını gösterdi
  • Bu sonradan yapılan analiz, hiçbir şey olmamış gibi davranmaktan daha iyiydi ve Anthropic'in kendi sorumluluğunu kabul ettiği nadir örneklerden biri olarak görüldü
  • TechCrunch haberine göre Anthropic, Claude Code abonelerine OpenClaw ve diğer üçüncü taraf harness desteği için ek ücret ödemeleri gerektiğini bildirdi
  • Gigazine haberine göre git geçmişinde yalnızca OpenClaw ifadesinin yer alması bile Claude Code'un isteği reddetmesine ya da ek ücretlendirmeyi tetiklemesine neden olabiliyor
  • Haberde Theo'nun sözlerine de yer veriliyor; buna göre JSON blob içindeki son commit'lerde OpenClaw'dan bahsedilmesi bile boş bir depoda claude -p "hi" komutunun doğrudan çağrılması sırasında davranışı tetikleyebiliyordu
  • İlgili sahne video klibinde de görülebiliyor
  • Bu tür davranışlar, gerçek kod düzeyindeki kullanım deneyimi içeride yeterince test edilmeden değişiklikleri yayına alan bir ürünü andırıyor
  • Dışarıdan bakıldığında Claude Code, daha fazla kısıtlama, garip ücretlendirme ve commit metnine göre değişen beklenmedik davranışlarla yanlış yöne gidiyor gibi görünüyor
  • Bu gidişat enshittification olarak tanımlanıyor

Bun'a sıçrayan kaygı

  • Bun, Claude Code'un içine derin biçimde entegre olmuş durumda ve Claude Code kötüye gidiyor gibi göründüğü için Bun'ın da aynı yöne gidebileceğine dair bir kaygı doğuyor
  • Bu, Bun'ın kötü olduğu ya da Bun ekibinin ilgisini kaybettiği anlamına gelmiyor
  • Sorun şu ki Bun ve Bun ekibi Anthropic'e daha fazla entegre oldukça, Anthropic'in politikaları da beraberinde gelebilir
  • Claude Code'u bozmuş gibi görünen politikalar Bun'ı da etkilerse, Bun'da da ekibin kendi ürününü gerçekte kullanmıyormuş gibi görünen sorunlar ortaya çıkabilir
  • Sadece bu ihtimal bile bazı projelerde Bun kullanmaya devam edip etmeme konusunda emin olmayı zorlaştırıyor

Şimdilik pnpm'e geçiş

  • Bun, pnpm'den daha fazla işlevi tek bir araç içinde sunuyor
  • Bun, ayrı bir build aşaması olmadan TypeScript desteği veriyor, Vite yerine bir bundler sağlıyor ve vitest yerine test özellikleri sunuyor
  • Bu özellikleri tek bir araç zincirinde bir araya getirmesi gerçekten büyük bir avantaj
  • pnpm, ne Node.js alternatifi ne de Bun alternatifi; sadece bir paket yöneticisi
  • Ancak günlük işlerde Bun'ı en sık kullandığınız alan paket yönetimiyse, hızlı kurulum, iyi monorepo desteği ve makul disk kullanımı hem Bun hem de pnpm tarafından sunuluyor
  • Bu nedenle şu anda Bun kullanan bazı projeler Bun'dan çıkıp pnpm'e geçme kararı alıyor
  • Bugün JavaScript ya da TypeScript projelerinde ne önerildiği sorulursa, cevap pnpm oluyor

Bun'ı bırakma çağrısı değil

  • Bazı projeler Bun'dan taşınıyor olsa da bunun genel geçer doğru cevap olarak alınması gerekmiyor
  • Yeni projelerde pnpm mantıklı olabilir
  • Mevcut projelerde ise ayrılmak için yeterince güçlü bir neden doğana kadar Bun ile devam etmeyi seçmek de mümkün

Kalan olasılıklar ve sonuç

  • Beklenti, Bun'ın harika durumda kalmaya devam etmesi, Bun ekibinin iyi işler çıkarmayı sürdürmesi ve Anthropic'in JavaScript ekosistemine uygun kararlar verebilmeleri için onlara özerklik tanıması yönünde
  • Anthropic'in parası, dağıtım gücü ve Bun'ın performansı ile istikrarını önemsemesi için somut nedenleri var
  • Bun, yaşanan bu süreçten geçerken hâlâ daha da güçlenebilir
  • Ancak Aralık 2025'e kıyasla mevcut duruma duyulan güven daha düşük
  • Eskinin Claude Code'u, Anthropic'in geliştirici araçlarını anladığının bir kanıtı gibi görünüyordu; bugün ise Anthropic'in bir ürünü uzun vadede sürdürmek ve iyileştirmek için gerekenleri bilmiyor olabileceğine dair bir uyarı gibi görünüyor
  • Bun hâlâ harika, ancak bundan sonra nereye gideceğini kestirmek zor
  • Bir yıl sonra durum tamamen farklı olabilir; bu yüzden bu öngörünün doğru çıkıp çıkmadığını yeniden kontrol etme planı var

İlgili okumalar

3 yorum

 
click 3 시간 전

Bun sayesinde Node’un da çok değiştiğini kabul ediyorum ama repoda yapay zekaların PR’larla kendi kendine davul zurna çaldığını görünce, çalışan şeyleri bozacak regresyon mayınlarına basmaktan korkuyorum.
Anthropic satın alımından önce Bun’ı ana araç olarak kullanıyordum ama şimdi tekrar Node’a döndüm.
sfx özelliğinin hâlâ killer bir özellik olduğunu düşünüyorum ama ona ihtiyacınız yoksa şu anda Bun kullanmak için çok güçlü bir neden göremiyorum.
 
GN⁺ 7 시간 전
Hacker News yorumları

  • Genel öncüle katılmıyorum: satın alma öncesinde de Bun’ın bir gün para kazanmanın bir yolunu bulması gerekiyordu
    Ana şirketin Claude Code gibi başka bir yazılımda kötü uygulamalar sergilemesi, bunun otomatik olarak Bun’ı daha kötü yapacağı anlamına gelmez. Endişeyi anlıyorum ama Bun konusunda hâlâ iyimserim
    Claude Code, Anthropic’in çekirdek ürünü ve son derece hızlı büyüyor; küçük değişiklikler bile faturalandırma sorunlarına yol açabilir. Buna karşılık Bun bir JavaScript runtime’ı ve en iyi runtime olmaya odaklanabilir; Anthropic’in gelirini ya da kârlılığını doğrudan etkilemediği için de Claude Code’daki gibi kötüye kullanım yüzünden acele yamalar çıkarması daha az gerekir
    Önümüzdeki birkaç yılda ne olacağı hâlâ belirsiz ama satın almanın hemen ardından şu anda çok büyük bir endişe duymuyorum

    • İnsanların kötüye kullanım açıklamasını bu kadar hızlı kabul etmesi ilginç. Büyük yapay zeka laboratuvarlarının, aboneliği yoğun kullanan kullanıcılardan para kazanamadığını uzun zamandır biliyoruz; bunun hangi ajanı ya da yürütme aracını kullandıklarıyla ilgisi yok. Kârlı ve adil fiyatlandırma, kullanıma dayalı token ücretlendirmesidir
      Bu laboratuvarlar, üçüncü taraf yürütme araçlarının temel büyük dil modellerini metalaştırma riski taşıdığını görüyor; bu yüzden o rekabeti öldürmeye çalışırken aynı zamanda birbirlerine karşı ne kadar süre zararına gidebilecekleri konusunda bir tavuk oyununa da giriyorlar
      Sonunda ürünlerini doğru fiyatlandırmaları gerekecek ve o noktaya gelene kadar tüm rekabeti öldürmüş olmayı ummaktan başka çareleri yok. Ama o oyunu zaten kaybediyor gibiler. Yararlı modeller her yıl küçülüyor ve çalıştırma maliyetleri düşüyor; bu yüzden üçüncü taraf yürütme araçlarının, abone kullanıcı tabanı olmadan da geliştirilmeye devam edebileceği eşiği çoktan geçtik
      Temel bahisleri olan “yararlı yapay zeka aşırı pahalı donanım gerektirir” zaten başarısız oldu; kullanıcıları ekosisteme kilitleyip sonra para kazanma şeklindeki ikinci bahisleri de başarısız olacak. Sonunda sadece ürünün kendi kalitesiyle rekabet etmek zorunda kalacaklar ve bu çok daha az kârlı
    • “Satın alma öncesinde de Bun’ın bir gün para kazanmanın bir yolunu bulması gerekiyordu” durumu başlı başına saçma geliyor. İnsanların zaten bir gün para kazanmak zorunda olan bir JavaScript runtime’ına bağımlı hale gelmiş olması garip; üstelik sektörün en büyük zarar yazan alanındaki en tipik zarar eden şirketlerden biri tarafından satın alınmasına rağmen hâlâ umutlu olunması da tuhaf
    • Şirketin politikalarının ve kültürünün ürün üzerindeki etkisini küçümsüyormuşsunuz gibi geliyor
      Bazı ekipler artık her şeyi AI’a bağlamış durumda ve kodu insanlar hiç görmesin gibi hareket ediyor. Bunu gerçekten gördüm ve sonuçlar da tahmin edilebilir düzeydeydi. Bir yere kadar işliyor ama özellikle ekiplerin teknik terimleri ve anlayışları farklı olduğunda karmaşıklık birikiyor, hatalar üst üste geliyor ve sonunda yazılımın gerçekte nasıl çalıştığını bilen kimse ya da ekip kalmıyor
      İnsan testine ya da kalite güvencesine başvurmadan, unit test ve integration testlerin üstüne AI’ın tarayıcıyı ya da araçları kontrol ettiği bir akım da var. Anthropic’in kültürü, Bun ekibinin çalışma biçimini ve düşünce yapısını değiştirebilir
      Bu kültür ve düşünce tarzı standart hale gelirse ya modeller çok daha iyi olacak ya da yazılım kalitesi düşecek
      Matt Pocock’un iyi bir sunumu var: https://youtu.be/v4F1gFy-hqg
      “Kod ucuz değil. Kötü kod, şimdiye kadar olduğundan daha pahalı. Çünkü değiştirmesi zor bir kod tabanınız varsa AI’ın sunabileceği bolluktan yararlanamazsınız. İyi bir kod tabanında ise AI gerçekten, gerçekten çok iyi iş çıkarır.”
      Kötü kod kendi kendine birikmeye başladığında içinden çıkmak çok zorlaşıyor
    • Aynı mantıkla, satın alma öncesinde GitHub da bir gün para kazanmanın yolunu bulmak zorundaydı. Ana şirket Microsoft’un Embrace, Extend, Extinguish ya da MS Windows’ta kötü pratikler göstermiş olmasının GitHub’ı da kötüleştireceğini söylemenin abartı olduğu; dolayısıyla endişeyi anladığını ama GitHub konusunda iyimser olduğunu söylemekten farkı yok
    • Anthropic, Bun’ı tüm JavaScript topluluğu için değil, Claude Code’a yaptığı yatırımı korumak ve büyütmek için satın aldı. Bu bariz gibi görünse de söylenmesi gerek. Uzun vadede sonuçları teşvikler belirleyecek

  • İnsanların neden Node yerine Deno ya da Bun kullandığını anlamıyorum. JavaScript runtime rekabetinin olması iyi ama Node’dan geçince ne kazandırdığını pek göremiyorum
    Bun’da REPL yok ve JavaScript motoru da daha kötü; Deno ise kısıtlayıcı ve sinir bozucu izin sistemi eklenmiş bir Node gibi geliyor, bir de sqlite yok sanıyordum. İkisinin de hızlı olduğu söyleniyor ama bu sadece seçilmiş benchmark’larda geçerli gibi; yaklaşık bir yıl önce kendi denediğim iş yüklerinde ikisi de Node’dan daha yavaştı
    Yine de eskiden küçük bir ERP aracı teslim ederken projeyi *.exe içine sarmak için en sağlam araç Bun tarafındaydı, bu yüzden Bun kullanmıştım. Bağımlılıksız JavaScript ile tümünü Node’da yapıp sadece dağıtımı Bun ile gerçekleştirmiştim; o deneyim kesinlikle Node’dan daha iyiydi

    • Deno’da da sqlite var: https://docs.deno.com/examples/sqlite/
    • Bun’ın geliştirici deneyimi Node’dan çok daha iyi, özellikle de TypeScript projelerinde
    • Deno’nun güzel yanı, kullanıcının ayrı bir kurulum adımı olmadan sadece çalıştırabilmesi

  • Bun zaten en başından beri pek düzgün yönetilen bir şey değildi. Hemen her özelliğinde bug ve boşluklar vardı; her sürümde birkaç şey düzelirken başka şeyler bozuluyordu
    Son patch sürümlerinden biri, çoğu yazılımın iki major sürüm boyunca yaşadığı kadar önemli özellik ve breaking change içeriyordu
    Temelde sadece script çalıştırıcı ve npm paket yöneticisi olarak kullansam bile “iyi” bir sürümü bulmak için gereken çaba şaşırtıcıydı. Patch sürümlerde kurulum sırasında aniden takıldığı birkaç kez oldu; bu yüzden bir süre yükseltme de yapamadım
    İki minor sürüm kadar önce, trustedDependencies ile birlikte postinstall scriptlerini tamamen bozmuş gibiydiler. Release notlarında tek kelime yoktu ve GitHub issue’larında da kimse raporlamamış gibiydi. 1.1 civarında Bun’a postinstall sırasında trustedDependency build’lerini yaptırabiliyordunuz ama sonrasında yapılamaz hale geldi ve aylardır bozuk

    • Kurulum sırasında takılma sorunuyla ilgili bir GitHub issue’su var. Güvenlik tarayıcısı tüm dependency listesini komut satırı argümanı olarak geçiriyor ve bu, Linux’taki büyük monorepo’larda ARG_MAX sınırını aşıyor
      spawn hata vermeden sessizce takılıyor ve tarayıcı postinstall’dan ayrı çalıştığı için --ignore-scripts de işe yaramıyor. En az 1.3.5’ten beri bozuk

  • Bun’da çalışıyorum ve bu yazı biraz kafa karıştırıcı. Hem ben hem de Bun ekibi her gün bizzat Bun kullanıyor ve onu geliştiriyoruz; geliştirme hızı ise aksine arttı. Anthropic’e katıldığımızdan beri Bun’ın kararlılığı da ciddi biçimde iyileşti
    Bir sonraki Bun sürümünde yer alacaklar arasında Windows x64 binary’sinin 17MB küçülmesi [0], Linux binary’sinin 8MB küçülmesi [1], geride kalan child process’leri recursive olarak sonlandıran --no-orphans CLI flag’i [3], Mongoose/MongoDB gibi veritabanı istemcilerinin bellek kullanımını ciddi şekilde azaltan client TCP ve Unix socket’leri için SSL context caching [4], fetch için deneysel HTTP/3 ve HTTP/2 client’ı [5], Bun.serve() için deneysel HTTP/3 desteği [6], yerleşik görüntü işleme kütüphanesi Bun.Image [7] var
    Buna ek olarak node:fs, Worker, BroadcastChannel ve MessagePort için güvenilirlik iyileştirmeleri de geliyor
    Anthropic satın alması sayesinde Bun’ın artık gelir üreten bir iş olması gerekmiyor. Claude Code, Bun’a bağımlı; çok sayıda yazılım mühendisi de Claude Code’a bağlı şekilde çalışıyor, dolayısıyla Bun’ı daha iyi hale getirmek için güçlü bir teşvik var
    [0]: https://github.com/oven-sh/bun/pull/30219
    [1]: https://github.com/oven-sh/bun/pull/30098
    [2]: https://github.com/oven-sh/WebKit/pull/211
    [3]: https://github.com/oven-sh/bun/pull/29930
    [4]: https://github.com/oven-sh/bun/pull/29932
    [5]: https://github.com/oven-sh/bun/pull/29863
    [6]: https://github.com/oven-sh/bun/pull/30032

    • Bu sektördeki satın almalar genelde az çok kaçınılmaz bir sona gider. Satın alınan yazılım, ilk ekip üyeleri ödüllerini alıp ayrıldıkça kötüleşir ve mevcut kültür yeni sahibin kültürüyle yer değiştirir
      Bun bunun istisnası olabilir ama endişelerin temelsiz olduğu söylenemez
      Anthropic CEO’su sık sık AI’ın insan programcıların yerini neredeyse alacağına dair abartılı tahminlerde bulundu ve Anthropic bu inancı Claude Code’a uygulayarak onu bakımı yapılamaz bir spagettiye dönüştürüyor
    • Bun’ın son dönemde sunduğu en iyi özellik taşınabilir binary oldu. Kullanıcılar sık sık eski Linux dağıtımları kullandığı için taşınabilirlik çok önemli. Node ve Deno daha yeni Linux, daha doğrusu daha yeni glibc istiyor
    • “Bun’da çalışıyorum” ifadesi inanılmaz bir küçümseme. Anthropic konusunda çekincelerim var ama işin başında Jarred olduğu sürece Bun’ın raydan çıkacağını sanmıyorum. Daha büyük bir organizasyonun istikrarını ve finansmanını iyi kullandıklarını düşünüyorum

  • Bıçak bileme web sitesi backend’ini Bun’dan Node’a taşımak için birkaç saat harcadım ve kilitlenme etkisinden kurtulmuş olmak iyi hissettirdi. Başta Bun konusunda epey hevesliydim ama zamanla güvenim azaldı
    Özleyeceğim özellikler, tagged template literal ile sqlite sorgulamak, Bun.password.verify içinde varsayılan olarak argon2 kullanılması, HTML import etme, JSX transform ve .env dosyalarının otomatik yüklenmesi
    https://burlyburr.com üzerinden https://backend.burlyburr.com çağrılıyor

    • Node da tagged template literal ile sqlite sorgulamayı destekliyor
      https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
    • Özlediğin özellikleri geri getiren küçük helper kütüphaneler kullanılamaz mı? Node’da en azından SQLite ve Argon2 zaten var; sorun arayüzse bunu düzeltmek kolay olur
    • Node da .env otomatik yükleme ve sqlite desteğine sahip

  • Bun’ın satın alma öncesinde de iyi çalıştığını düşünmüyorum. Küçük script’ler için kullanmaya devam ettim ama iş yerinde Bun ile servis deploy etmezdim
    Bellek sorunları ve düzelmeyen uyumsuzluklar yüzünden, Node.js’in geliştirilebilecek yönleri olduğunu gösteren hoş bir oyuncak gibi görüyordum
    Örneğin https://github.com/oven-sh/bun/issues/14102 issue’sunu izliyordum; sonunda kütüphaneler “Bun ise x yap” türü dallanmalar eklemeye başladı ki bu uyumluluğun tam tersi

    • Birkaç projede production’da kullanmayı denedim ama ikisinde de Bun’dan Node’a geri dönmek zorunda kaldık. Biri söylediğin gibi büyük bir bellek sızıntısı yüzündendi, diğeri ise TextDecoderStream gibi yerlerdeki API farkları nedeniyle hata veriyordu. Bun v2’den önce tekrar denememeye karar verdim

  • Claude Code ve Anthropic’in gidişatı, kullanıcıdan bir şeyleri zorla gizlemeye çalışan bir yöne gidiyor gibi görünüyor. xxx.yy okuma davranışının 1 dosya okumaktan 2 dosya okumaya dönmesiyle çıkan kargaşayı hatırlayanlar vardır
    Bu tür değişiklikler devam etti ve yapılandırması ya imkânsızdı ya da çok zordu. İş gerekçesini anlıyorum: olabildiğince çok AI kullandırmak, insanı döngüden çıkarmak, daha fazla eğitim verisi ve daha fazla token tüketimi elde etmek
    Ama sonuç olarak Claude Code’un çok daha kötü ve çok daha az güvenilir hale geldiğini düşünüyorum. Direksiyonu kullanıcıdan gizlice almaya çalışma gibi hissettiriyor. O mantığı sonuna kadar götürürseniz giderek daha fazla şey meşrulaştırılabiliyor
    Şu an için esas büyüyen şey güvensizlik oldu

  • Yazara katılıyorum ve bazı insanlara bunun hâlâ erken bir tepki gibi gelebileceğini de anlıyorum
    Eskisinden çok farklı bir dünyada yaşıyoruz ve insanlar etik kaygıların daha fazla farkında; geçmişteki hataları tekrarlamamak için direnme iradesi de daha güçlü
    Teknik ölçütlerle erken bir yargı olabilir ama etik kaygılar açısından mantıklı. Kötü davranışlar eskisi gibi kolayca geri alınamıyor; böyle kararların doğurduğu büyük etkilerden kaçınmak için önleyici adımlar gerekli

    • İnsanların eskisine göre etik kaygıların daha fazla farkında olduğuna dair dayanak nedir, merak ediyorum. Bana öyle görünmüyor. Örneğin BDS tarafında biraz artış görüyorum ama onun dışında pek değil
    • Firefox ve Safari’nin Chrome OS platform API’lerini benimsememesine dair şikâyetler ya da Chrome’un her yere dağıtılması gibi gerçekler düşünüldüğünde, insanların etik kaygılara bağlı kalarak direndiğini söylemek zor görünüyor

  • Yazar en sonda, Bun’da sevdiği ama pnpm’de olmayan şeyleri listeliyor. Liste kabaca native TS desteği, Vite tarzı bundler ve Vitest/Jest tarzı test runner’dan oluşuyor
    Bundler hariç bunların hepsi Node’da zaten var. Test runner sözdizimi farklı olabilir ama TypeScript varsayılan olarak “öylece çalışıyor” ve yerleşik test runner da gayet kullanılabilir. Bun için bu kadar yas tutmaya gerek var mı pek emin değilim

    • Adil olmak gerekirse Node’da bunlar, Deno ve Bun ortaya çıkıp meydan okuyana kadar yoktu. Deno tek başına nedense büyük değişimi tetikleyemedi ama Bun’ın varlığı Node Teknik Yönlendirme Komitesi üzerinde gerçek bir etki yarattı
      Jarred Sumner’ın akıllı sosyal medya pazarlamasının bugünkü ivmenin önemli bir bölümünü yarattığı da söylenebilir. İnsanları konuşturdu ve bunun sonucunda Node da daha iyi hale geldi
      Ayrıca Bun’ın olabildiğince çok Node API’sini destekleme ısrarı, Deno’yu da aynı uyumluluk seviyesine itti; artık çoğu kod pratikte runtime’a daha az bağlı. Production’da Bun kullanır mıyım emin değilim ama Bun’ın var olmuş olması bile JavaScript ekosistemini ciddi biçimde iyileştirdi, buna seviniyorum
    • Node native TypeScript desteğini ne zaman ekledi? Hiç bağımlılık olmadan node main.ts doğrudan çalıştırabiliyor musun?
    • TypeScript derleyicisinin yeniden yazımı da hesaba katılırsa Bun’ın ilgililik payı daha da azalıyor

  • Dürüst olmak gerekirse Bun’ı, arada modül test etmek dışında çok kullanmadım. Günlük hayatta daha çok Deno kullanıyorum ve son birkaç yılda birçok shell script’i de Deno ile yazdım
    Son dönemdeki kullanılabilirliğini epey beğendim; depodaki modüllere doğrudan referans verme şekli özellikle shell script’ler için çok iyi
    Ama özellikleri açık tutarken yeterli gelir modeli oluşturup oluşturamayacağı ya da en azından başkalarının onu kopyalayabilmesine izin verip veremeyeceği konusunda endişeliyim. Bu yüzden bazı kaygıları anlayabiliyorum
 
jjpark78 3 시간 전

https://github.com/oven-sh/bun/issues/17723

Sadece şunu düzeltseler bile backend'de bir kez deneyecekmişim gibi geliyor...