Bun desteği artık kısıtlanıyor ve kullanımdan kaldırılma sürecine giriyor

• Bu issue hâlâ Open durumunda ve bir sonraki yt-dlp ve/veya ejs sürümünden itibaren Bun desteğinin kapsamı 1.2.11 ve üzeri, 1.3.14 ve altı ile sınırlandırılıyor; ayrıca desteğin kendisi de kullanımdan kaldırılma sürecine alınıyor
• yt-dlp, Bun’u ejs ile uyumlu bir JavaScript runtime’ı olarak kullanmayı sürdürüyor, ancak bakım yükü artarsa Bun desteğini tamamen kaldırma hakkını saklı tutuyor
• Desteklenen en düşük sürüm, önceki 1.0.31 yerine 1.2.11 oluyor; çünkü 1.2.0 öncesi Bun ile ejs paketini derlerken ejs lock dosyası yok sayılıyor ve bu da yakın dönemdeki npm tedarik zinciri saldırıları düşünüldüğünde ciddi bir güvenlik endişesi olarak görülüyor
• Alt sınırın 1.2.0 değil 1.2.11 olarak belirlenmesinin nedeni, 1.2.11 öncesi Bun sürümlerinde ejs test paketinin çalıştırılamaması
• Üst sınır 1.3.14 olarak belirlendi; gerekçe olarak da bu sürümün, özgün Zig kod tabanından derlenen son release olması gösteriliyor
• Bun’un yakın zamanda Claude kullanılarak Rust ile yeniden yazıldığı ve geliştirme yönünün “tamamen vibe-coded” bir çizgiye kayıyor gibi görünmesi, ileride bakım yükü ve güven açısından sorun olarak gündeme getiriliyor
• Bir yorumda Deno’nun da “vibe coded” olduğu itirazı yapıldı, ancak yönetici Claude kullanmak ile Claude’a tamamen bağımlı olmak arasında büyük fark olduğunu söyledi
• 1.3.4 ile 1.3.14 arasındaki sürümlerin de Anthropic satın alımı sonrasında “vibe coding” etkisi altında kalmış olabileceği ve bu nedenle destek dışı bırakılması gerekip gerekmediği sorusuna yönetici, bunu değerlendireceğini söyledi
• Bazı kullanıcılar, gerçek bir sorun ortaya çıkmadan en yeni Bun sürümlerinin çalışmasını engellemenin temelsiz ve peşin bir kısıtlama olduğunu, bunun yerine uyarı ya da bir flag ile çalışmaya devam edebilmesi gerektiğini savunuyor
• Başka bir yorumda, --js-runtimes ile Bun ikilisinin yolu doğrudan verilebildiği için, en güncel Bun’un normal şekilde kullanılmaya devam edilip yt-dlp için özel olarak statik Bun 1.3.14 belirtilebileceği anlatılıyor
• İlgili duyurular olarak Node v20·v21 desteğinin sonlandırılması issue’su ile Deno için asgari desteklenen sürümün v2.3.0’a yükseltilmesi issue’su da bağlandı; ayrıca EJS wiki belgesi henüz bu değişikliği yansıtmıyor
• Yönetici, Hacker News kaynaklı yorum akışını dikkate alarak, yorum yazmadan önce gerçekten yt-dlp içinde Bun kullanımıyla ilgili bir sorunla ilgilenip ilgilenmediğinizi düşünmenizi isteyen sabitlenmiş bir yorum bıraktı

[GN⁺]

Hacker News yorumları

• Karar anlaşılabilir. Bakımcının bizzat yazmadığı kod çoğunluktaysa, kod tabanını gerçekten anlamak zor olmalı
  Baştan yazılan tüm kodu gözden geçirmek de fiilen imkânsız. Söz konusu olan tam 1 milyon satır kod https://github.com/oven-sh/bun/pull/30412

  • Zig'den Rust'a geçildi diye belirli bir dosyanın ne içerdiğini, nasıl çalıştığını ve diğer dosyalarla nasıl bağlandığını bir anda bilmez hale gelmezsiniz diye düşünüyorum
    Sonuçta aynı içeriğin başka bir sözdizimiyle yazılmış haline daha yakın ve bu yüzden Rust geliştiricilerine kötü görünüyor olabilir. Sanırım Bun geliştiricileri kendilerine tanıdık gelen bir kod istiyordu
    Yine de buna 2.0 denmeliydi diye düşünüyorum. O zaman bu kadar acele ediliyormuş hissi de azalırdı. 1.3.14'te de birkaç regresyon var ama şu anda küçük Rust kaynaklı yangın o kadar fazla ki kimse pek umursamıyor gibi
    Daha büyük sorun, Bun'ın parlak yeni özelliklerin peşinden koşup işleri sonuna kadar tamamlamaması. Testler çoğunlukla Vitest ama tamamı değil, Jest de çoğunlukla var ama tamamı değil, pnpm de öyle. Şimdi görüntü özellikleri de geldi; sharp'ın çoğu var ama tamamı değil. Geliştirme sunucusu da Vite'ın çoğu ama yine tamamı değil. Uzun süre çalışan süreçler Node'a büyük ölçüde benziyor ama bellek sızıntıları var; sanırım Rust geçişinin motivasyonlarından biri de buydu
    Görüntü rutinleri yazısını gördüğümde hevesim kaçmıştı. Bu da bir başka parlak hedefti ve test bug'larıyla birleşince sonunda tamamen Vitest'e geçtim
  • Yaklaşık 2 milyon satır Zig kodu yazılabildi ama içindeki aynı test paketini kullanmaya devam edebiliyorken 1 milyon satır Rust kodu gözden geçirilemez demek pek ikna edici gelmiyor
    Bu yeniden yazımın başlı başına iyi bir fikir olduğundan ve başarılı olacağından emin değilim ama buna karşı öne sürülen mantık da aynı derecede ikna edici değil
  • Bu, çalışan devrinin yüksek olduğu şirket kültürlerinde oldukça yaygın. Sizi 10 yıllık, milyonlarca satırlık bir kod tabanını “bakımını yapmakla” görevli ekibe atarlar ve ekipte en uzun süredir bulunan kişi bile sadece 1-2 yıldır oradadır
    O 1 milyondan fazla satırın ne yaptığını kimse bilmez. Onu gerçekten sahiplenip hevesle ilgilenen de yoktur. Gereksinimleri alırsınız ve dokunmanız gereken yüzeyler dışındaki her şeyi kara kutu muamelesi yaparsınız
    Sonuçta aynı işi yapan 14 arka plan servisi uygulaması, aynı role sahip 8 bağımlılık, birbiriyle çakışan 6 framework ve stil ile yaklaşımda tam bir uyumsuzluk ortaya çıkar. Yine de kimse bunu pek önemsemez
  • Şu anda baktığım oldukça büyük kod tabanlarından bazılarında, ajan tarzı araçlarla üretildiği için üreten kişinin nasıl çalıştığını neredeyse hiç anlamadığı bölümler var
    Buna saf “vibe coding”den daha iyi diyebilirim ama önemsiz kısımlarda idare etse bile gerçekten derin düşünme gerektiren çekirdek altyapıda kabul etmesi zor
  • Onlar Windows'u da destekliyor ve Windows tarafında da mevcut bakımcının yazmadığı milyonlarca satır kod var

• Bu, birinin ırkını ya da dinini ayrımcılığa uğratmak değil. Büyük bir vibe coding ile üretilmiş yüzey alanı istemiyorsanız neden illa açıklama yapmak zorunda olasınız ki?
  Bu, geliştiricinin “sanatsal” takdir yetkisine girer ve insanların yazılımın doğası gereği görüş içerdiğini unutmuş gibi görünüyor

  • GitHub issue'larındaki bazı yazılara bakınca, sanki kendi dinlerine saldırılmış gibi hisseden insanlar var
  • Yorumlara bakınca birçok kişi başlığın Bun'ın kendisiyle ilgili olduğunu sanıyor gibi
  • Evet. Fork'layıp sadece minimum sürüm numarasını yükseltmek de zor olmazdı. Ben bakmadım ama muhtemelen bir yerde tek bir sayıyı değiştirmek yeterlidir
    Çalışıyorsa çalışmaya devam edecektir. Sadece onlar bunu desteklemek, bakımını yapmak ve issue çözmek istemiyor
  • Bu, ırk ya da din ayrımcılığına benzetilebilir de. Keyfi ve anlamsız bir ölçüte göre dışlama yaptığı için
    Rust'a port edilen Bun ölçülebilir her açıdan daha iyiyse, tüm testlerden geçiyorsa, performansı aynı ya da daha iyiyse ve mevcut bug'ları düzeltiyorsa, hangi dilde yazıldığı ve nasıl uygulandığı neden önemli olsun ki? Esas mesele kalitenin daha yüksek olması
    Bun ekibi Rust sürümünü yayımlayıp onayladığında ona güvenmiyorsanız, 2 hafta önceki Zig sürümüne neden güvendiğiniz de mantıksal olarak tutarlı olmaz. Bu durumda yt-dlp geliştiricileri aptal gibi görünür

• Bun kullanmayı gerçekten seviyorum, o yüzden Anthropic satın alımı sonrasında yönün böyle değişmesi biraz üzücü
  İçinde her şey bulunan iyi bir Node istiyorum ama bunun vibe coding ile yapılmış olmasını istemiyorum

  • Vibe coding ile yapılan dönüşüm yüzünden gerçekten büyük bir sorun yaşandı mı diye merak ediyorum
    Birleşmeyi desteklediğim anlamına gelmesin. Böyle YOLO tarzı mühendislik yaklaşımına karşıyım. Sadece duyurudan sonra gelişmeleri takip etmedim, geçişin nasıl gittiğini merak ediyorum
  • Bun ekibine göre, Anthropic satın alımından aylar önce zaten vibe coding yapılıyormuş
  • Satın alım sırasında insanlar Bun'ın aşağı yukarı eskisi gibi devam edeceğini umuyordu ama sonunda bu beklentinin tamamen tersine dönüp bozulması gerçekten ironik
    Tabii komik derken korkunç derecede üzücü anlamda komik
  • “Vibe coding” yüzünden ortaya çıkan somut bir sorun doğrulanmadıysa, gerçek dayanakları kontrol etmeden refleks olarak reddetmek de eleştirdiği davranışa benzemiyor mu?

• Bu karar, mühendislikten çok siyasi bir yargı gibi görünüyor. Rust yeniden yazımından sonra Bun'da segmentation fault, bellek yetersizliği, güvenlik açığı ve bug artışı gördünüz mü?
  Tabii henüz yeniden yazılmış sürüm bile gelmediği için görmüş olamazsınız. Sanki AI müdahalesi fikri hoşunuza gitmediği için karar veriliyor gibi
  Mühendislik araçları hislere göre değil, istenen işi yapıp yapmadığına göre seçilir. Bun'da bug'lar artar ve daha kötü bir yazılım gibi hissettirirse kullanmam ama bu kararım veriye dayanır. Jarred, Bun ile çok etkileyici işler yaptı ve kendi kalite çıtasını karşılamayan bir yeniden yazımı yayımlaması düşük ihtimal, o yüzden bekleyip göreceğim

  • Buna karşılık, Bun'ın yeni geliştirme sürecinin segmentation fault, bellek yetersizliği ve güvenlik açıklarını artırıp artırmadığını yt-dlp tarafının deneyip görme zorunluluğu yok
    Güvenlik açığı riskinin makul biçimde artmış olabileceğini düşünürken bunu kullanıcılar üzerinde test etmek, aksine ihmalkârlık sayılabilir
    Sorumlu tercih, “şu anki main'den kesilmiş yeni Bun sürümünde yazılımımızın çalışmasını hemen desteklemeyeceğiz” demeye daha yakın
    Yine de gelecekteki sürümleri yeniden değerlendirme planı değil de, sanki artık asla desteklemeyecekleri niyeti varmış gibi görünmesi üzücü. Elbette yt-dlp geliştiricilerinin kimseye borcu yok
  • Bunun illa siyasi olması gerekmiyor. yt-dlp siyasi davranıyor olabilir ama çekirdek bir bağımlılığı production'da 6 ay-1 yıl yaygın biçimde kullanılmadan önce benimsememe ilkesi genelde siyasi değildir
    1 milyon satırlık tam yeniden yazım, aynı ABI'ye sahip olsa da fiilen yeni bir runtime demek ve birçok alt tüketici için production bağımlılığı olarak alınması rahatsız edici
    Tartışma adına Bun'ın tamamı insanlar tarafından elle yeniden yazılmış olsaydı da durum aynı olurdu. Bence bu tür kararlar oldukça standart ve kişisel olarak Bun'ın LLM ile yeniden yazım kalitesinin genel olarak iyi olacağını düşünsem de kendi ürünümü ya da şirketimi buna bağlamam. Riskli değişiklikleri yazılımımda ben seçmek isterim, alt bağımlılık yüzünden zorla üstlenmek istemem
  • Segmentation fault, bellek yetersizliği ve diğer sorunların artmasını beklediğiniz anda zaten sorundan kaçınma konusunda başarısız olmuşsunuzdur. Bence bu yön doğru ve tarihin kimin haklı olduğunu gösterecek
  • Projelerde yönetişim çok önemlidir. Bun yazarlarının yeni sahiplerinin önünde diz çökmesi, önceliklerin nerede olduğunu gösteriyor
    Bug'lar patlayıp her şey dağılmaya başlayana kadar oturup beklemeyeceğim
    “Araçları sadece istediğim işi yapıyor mu diye seçerim” diye düşünen birinin projesiyse, onu bağımlılıklarımdan çıkarırım
  • Mühendisliğin temel unsurlarından biri mevcut gidişatı öngörmektir. Bu açıdan kötü his veren araçlardan kaçınmak gayet mantıklı
    Bir tren kazasına dönüşebilecek araçtan uzaklaşmanın en kolay zamanı, onu daha entegre etmeden öncedir

• Bu, Rust dönüşümüyle ilgili ama henüz yayımlanmadı
  “Öngörülebilir uyumluluk ve güvenlik sorunları” deniyor ama Zig sürümündeki Bun da epey çöküyordu
  yt-dlp'nin neden öngörülebilir uyumluluk sorunları olduğunu daha ayrıntılı açıklayan bir bağlantı vermesini isterdim. Her iki projenin de test paketleri var, dolayısıyla ideal bir dünyada hızlı bir yeniden yazım mümkün olmalı
  Belki durumu daha fazla alevlendirmemek istiyorlar ama somut olarak tespit ettikleri sorunlar varsa görmek isterdim
  Bun.rs bunun için minör sürüm değil de 1.4 ya da 2.0 demeli ve keşke alpha/beta sürümleri de olsaydı

  • Gerçekten bir proje Bun.rs üzerinde ciddi regresyonlar raporlayıp veri paylaşmış olsaydı durum farklı olurdu
    Ama daha açıkta sadece bir hafta oldu ve şu ana kadar ortada neredeyse hiç gerçek regresyon verisi yok. Daha çok “sadece hoşuma gitmedi” tarzı bir yakınma gibi duruyor

• Bu mantık bana, “libfoo artık vim yerine emacs ile geliştiriliyor, o yüzden artık güvenilmez” demekten çok da farklı gelmiyor
  Tabii birebir aynı değil ama benzer hissettirmesinin bir nedeni var
  Yazılımda tek gerçek, benim kullanım senaryomda çalışıp çalışmadığıdır. AI'den önce de yazarın titiz ilerleyip ilerlemediğini ya da tutana kadar rastgele denemeler yapıp yapmadığını bilmiyorduk
  Başka bir deyişle, yazılımı metodoloji ya da kullanılan araçları inceleyerek değerlendirmiyordum. Test paketi olmayan ya da berbat durumda olan çok yazılım kullandım; bellek güvenliğini seven insanlar da C ile yazılmış araçlar kullanıyor, tersi de geçerli
  O yüzden “AI kullanım tarzını beğenmediğim için kullanmayacağım” mantığı, yazarın editör tercihini beğenmediği için kullanmayı bırakacağını söylemek kadar zayıf geliyor

  • Bir şeyin nasıl üretildiğini gerçekten önemseyen ve o sürece katılıp katılmamaya göre karar veren insanlar kesinlikle var
    Aksi halde fair trade çikolata/kahve diye bir kavram da olmazdı
  • O benzetme fazla zorlama. Aynı ligde değil, komşu ligde bile değil diye okunmalı
  • O zaman bir adım daha ileri gidelim: Her ayın ilk pazartesi günü tüm kod tabanını yeni bir dile baştan yazan bir cron işi kurduğunuzu düşünün. Rust'tan C++'a, Go'ya, Swift'e gidip tekrar geri dönüyor olsun
    Ürünü kullanan müşteriler için bu da bakımcının editör değiştirmesiyle neredeyse aynı, önemsiz bir ayrıntı mı olurdu?
  • Çoğu insan kullanılan metin editörünün yazılan kod üzerinde anlamlı bir etkisi olmadığını düşünür
    Ama LLM için aynı şeyi söyleyen kişi o kadar da çok olmaz
    Vibe Bun eski Bun kadar iyi ya da daha iyi olabilir ama şu anda bunu nasıl bilebiliriz?
    Ayrıca “yazılımın titizlikle üretildiğini bilmiyorduk, metodolojiye göre değerlendirmiyorduk” sözü de doğru değil. Bazı insanlar bir projeyi benimsemeden ya da kullanmaya devam edip etmeyeceğine karar vermeden önce kabul edilebilir bir titizlik düzeyi olup olmadığını bizzat kontrol eder. Ben de önemli yerlerde bunu yapıyorum
    Daha fazla insan ise itibar sinyallerini kullanıyor; kusursuz olmasalar da korelasyonları var, yeterli olabiliyorlar ve doğrudan elle incelemekten çok daha kolaylar

• Geliştirme işinde LLM kullanım biçimini anlatacak yeni bir terime gerçekten ihtiyaç var. “Vibe coding”in katı bir tanımı var ama kimse umursamıyor gibi
  Rust portunun özgün tanımdaki gibi %100 “vibe” ile yapılmış olduğuna inanmak gerçekten zor
  Olumlu ya da olumsuz, konu duyguların bulandığı bir çamur güreşine döndü ve “vibe coding” ifadesi genel bir LLM kullanım aşağılama sözü gibi kullanıldığında tam olarak hangi sorunun kastedildiğini anlamak çok zorlaşıyor
  Ben geliştirmeye yardımcı olması için LLM kullanıyorum ve bir mühendisin önemseyeceği her ölçütte daha iyi işleri daha hızlı yapıyorum

  • Vibe coding başlangıçta “olayı akışına bırakıp [...] kodun var olduğunu bile unutmak” anlamına geliyordu
    https://x.com/karpathy/status/1886192184808149383
    Bu özel port örneğinde süreç o kadar hızlı ilerledi ki insanların çevirinin geçerliliğini doğrulamadığı açık görünüyor. İleride elle doğrulama yapılıp yapılmayacağı da belirsiz
    Gerçi Dijkstra ölçütüne göre bakarsak, AI ortaya çıkmadan çok önce de çoğu yazılım projesi zaten “vibe coding” yapıyordu. Yani akışına bırakıp doğruluğun diye bir şey olduğunu unutuyordu
    Karmaşık kodun doğruluğunu garanti etmek zordur ama artık veri merkezinin içinde 1 milyar hacker bulunan bir çağdayız ve bu giderek isteğe bağlı bir şey olmaktan çıkacak
    Ek: “Bun'ın yayımlanmamış Rust portunda 13.365 unsafe block var”
    https://news.ycombinator.com/item?id=48239790
  • LLM kullanarak daha hızlı daha iyi işler yaptığınız iddiasının aksine, araştırmalar bunun daha hızlı olmayabileceğini, hatta daha yavaş bile olabileceğini gösteriyor
    Bu teknoloji çok yeni olduğu için araştırması zor ama iyimser bakıldığında bile ampirik kanıt bazı alanlarda yaklaşık %3 iyileşme dışında pek bir şey göstermiyor
    Kod yazmak işimizin nadiren darboğazıdır

• İnsanların neden bu karar karşısında bu kadar baskı hissettiğini anlamıyorum. Gerçek bir vibe coding meraklısıysanız, daha iyi bir yt-dlp'yi kendiniz vibe coding ile yapabilir ya da mevcut olanı fork'layıp istediğiniz hale getiremez misiniz?

  • Sonuçta vibe coding sayesinde yazılım yapmanın önemsiz derecede kolaylaştığını ve herkesin bunu anında yapabileceğini çok duyduk
    Hatta insanların her iş için tek kullanımlık kişisel yazılımları vibe coding ile üreteceği de söyleniyordu
    O halde vibe coder'ların herhangi bir yazılım kararından şikâyet etmek için bir nedeni olmamalı. Hoşunuza daha çok giden kişisel bir fork'u vibe coding ile yapmak çocuk oyuncağı olmalı, değil mi? Bu vibe coding'in vaadi değil miydi?
  • Ayrıca yt-dlp'nin zaten üçüncü taraf yorumlayıcı eklentisi desteği var. Sadece Bun'ı doğrudan desteklemek istemediklerini söylüyorlar; başkasının istediğini kullanabilmesi için gereken altyapı zaten mevcut
    Bu, başkalarının zamanı ve emeğiyle ayakta duran projelere karşı insanların sıkça taşıdığı yanlış hak duygusu. Sırf kendi istediği özellik olsun diye başkalarının zamanını ve emeğini gönüllü olarak seferber etme hakkını kendinde görmeleri hâlâ şaşırtıcı
    İşi yapanlar karar verme hakkına sahiptir ve beğenmiyorsanız kendiniz fork'larsınız. Bu ekosistem başından beri böyleydi
    yt-dlp hâlâ şaşırtıcı derecede kolay kurcalanabilir durumda
  • Birçok AI hayranı için, hepsi değil ama, bu neredeyse bir din gibi işliyor. Herkesin kendi yoluna gitmesine ve tarihin hangi yazılım geliştirme yaklaşımının daha iyi olduğunu göstermesine razı olmuyorlar; herkesin onlarla aynı fikirde olmasını istiyorlar
    İş yerinde de bunun benzerini yaşıyorum; AI konusunda dürüst teknik anlaşmazlığa alan bırakılmaması gerçekten çıldırtıcı

• Bun yeniden yazımı hakkında ne hissetmem gerektiğini bilmiyorum
  Bir yandan, kod tabanının büyük kısmının gözden geçirilmemiş olması çok korkutucu geliyor
  Diğer yandan, duyduğuma göre neredeyse hiç regresyon olmadan testlerden geçiyormuş
  Belki bu alanda tecrübem az olduğu içindir ama ben testlere, kodu hiç okumadan tamamen dayanacak kadar güvenmezdim