Dukungan Bun kini dibatasi dan dialihkan menjadi akan dihentikan

• Isu ini masih berstatus Open, dan mulai rilis yt-dlp dan/atau ejs berikutnya, cakupan dukungan Bun akan dibatasi ke 1.2.11 hingga 1.3.14, sekaligus status dukungannya diubah menjadi akan dihentikan
• yt-dlp akan tetap menggunakan Bun sebagai runtime JavaScript yang kompatibel dengan ejs, tetapi tetap menyisakan hak untuk menghapus dukungan Bun sepenuhnya jika beban pemeliharaannya membesar
• Versi minimum yang didukung dinaikkan dari 1.0.31 menjadi 1.2.11, karena jika paket ejs dibangun dengan Bun sebelum 1.2.0, file lock ejs diabaikan, yang dipandang sebagai kekhawatiran keamanan besar mengingat serangan rantai pasok npm baru-baru ini
• Alasan batas bawah ditetapkan ke 1.2.11, bukan 1.2.0, adalah karena pada Bun sebelum 1.2.11, test suite ejs tidak dapat dijalankan
• Batas atas ditetapkan ke 1.3.14, dengan alasan bahwa versi ini adalah rilis terakhir yang dibangun dari codebase Zig asli
• Disebutkan bahwa Bun baru-baru ini ditulis ulang ke Rust dengan menggunakan Claude, dan arah pengembangannya tampak menuju “sepenuhnya vibe-coded”, yang menimbulkan kekhawatiran soal beban pemeliharaan dan kepercayaan ke depan
• Salah satu komentar membantah bahwa Deno juga sedang “vibe coded”, tetapi pengelola menjawab bahwa ada perbedaan besar antara menggunakan Claude dan sepenuhnya bergantung pada Claude
• Menanggapi pertanyaan apakah 1.3.4 hingga 1.3.14 juga seharusnya dikecualikan dari dukungan karena mungkin telah terdampak “vibe coding” setelah akuisisi Anthropic, pengelola menjawab bahwa hal itu akan ditinjau
• Beberapa pengguna menentang pembatasan preventif yang memblokir Bun terbaru bahkan sebelum ada masalah nyata, dan berpendapat seharusnya cukup diberi peringatan atau flag agar tetap bisa dijalankan
• Komentar lain menjelaskan bahwa karena path biner Bun bisa diberikan langsung ke --js-runtimes, pengguna tetap dapat memakai Bun terbaru seperti biasa dan menunjuk Bun statis 1.3.14 khusus untuk yt-dlp sebagai solusi sementara
• Sebagai pengumuman terkait, isu penghentian dukungan Node v20·v21 dan isu kenaikan versi minimum Deno ke v2.3.0 juga ditautkan bersama, dan disebutkan bahwa dokumen wiki EJS masih belum mencerminkan perubahan ini
• Pengelola juga meninggalkan komentar pin dengan menanggapi arus komentar dari Hacker News, meminta orang untuk terlebih dahulu mempertimbangkan apakah mereka benar-benar peduli pada masalah penggunaan Bun di yt-dlp sebelum berkomentar

[GN⁺]

Komentar Hacker News

• Keputusan ini bisa dimengerti. Kalau sebagian besar kodenya bukan ditulis langsung oleh maintainer, rasanya memang akan sulit untuk benar-benar memahami codebase
  Meninjau kode hasil penulisan ulang secara penuh juga pada praktiknya nyaris mustahil. Ada tepat 1 juta baris kode https://github.com/oven-sh/bun/pull/30412

  • Menurut saya, hanya karena berubah dari Zig ke Rust bukan berarti tiba-tiba jadi tidak tahu file tertentu berisi apa, bagaimana cara kerjanya, dan bagaimana hubungannya dengan file lain
    Pada akhirnya ini kurang lebih sama saja, hanya konten yang sama ditulis dengan sintaks berbeda, jadi mungkin di mata developer Rust hasilnya terlihat kurang enak dilihat. Sepertinya developer Bun menginginkan kode yang terasa lebih familier bagi mereka
    Namun saya pikir ini seharusnya disebut 2.0. Dengan begitu kesannya tidak akan terlalu terburu-buru seperti sekarang. Bahkan di 1.3.14 sudah ada beberapa regresi, tapi sekarang suasananya seperti ada terlalu banyak kebakaran kecil terkait Rust sampai tak ada yang terlalu peduli
    Masalah yang lebih besar adalah Bun terus mengejar fitur baru yang mengilap dan tidak menuntaskannya sampai akhir. Pengujiannya mencakup sebagian besar Vitest, tapi tidak semuanya, dan sebagian besar Jest, tapi juga tidak semuanya, lalu sebagian besar pnpm, tapi tetap tidak semuanya. Sekarang ada juga fitur image, jadi mencakup sebagian besar sharp, tapi lagi-lagi tidak semuanya. Dev server-nya mencakup sebagian besar Vite, tapi tetap belum semuanya. Proses berjalan lama secara umum mirip Node, tapi ada memory leak, dan sepertinya itu mungkin salah satu motivasi perpindahan ke Rust
    Waktu membaca tulisan tentang rutinitas image, saya jadi patah semangat. Itu lagi-lagi target mengilap lain, dan ditambah bug di pengujian, saya akhirnya pindah sepenuhnya ke Vitest
  • Fakta bahwa mereka bisa menulis sekitar 2 juta baris kode Zig, sambil tetap bisa memakai test suite yang sama di dalamnya, tetapi katanya tidak bisa meninjau 1 juta baris kode Rust, terdengar kurang meyakinkan
    Saya tidak yakin penulisan ulang ini sendiri adalah ide yang bagus dan akan berhasil, tetapi logika sebaliknya juga sama sulit diterima
  • Ini cukup umum di budaya perusahaan dengan tingkat perpindahan karyawan yang tinggi. Anda ditempatkan di tim yang “memelihara” codebase berusia 10 tahun dengan jutaan baris, dan orang yang paling lama di tim pun baru 1–2 tahun di sana
    Tak ada yang benar-benar tahu lebih dari 1 juta baris itu melakukan apa. Juga tak ada yang menangani itu dengan antusias. Mereka menerima requirement, lalu memperlakukan semuanya sebagai black box kecuali permukaan yang memang harus disentuh
    Akibatnya muncul 14 implementasi background service untuk pekerjaan yang sama, 8 dependency dengan peran yang sama, 6 framework yang saling tumpang tindih, serta ketidakselarasan total dalam gaya dan pendekatan. Tapi tetap saja tidak terlalu dianggap penting
  • Di antara codebase yang cukup besar yang sedang saya tangani sekarang, ada juga yang dibuat dengan alat bergaya agen dan orang yang membuatnya sendiri hampir tidak memahami cara kerjanya
    Menurut saya itu masih lebih baik daripada “vibe coding” murni, tapi kalau untuk bagian yang tidak penting mungkin masih oke, sedangkan untuk infrastruktur inti yang benar-benar perlu dipikirkan mendalam, itu sulit diterima
  • Mereka juga mendukung Windows, dan untuk Windows saat ini ada jutaan baris kode yang juga bukan ditulis oleh maintainer saat ini

• Ini bukan seperti mendiskriminasi ras atau agama seseorang. Kalau tidak mau punya permukaan hasil vibe coding dalam skala besar, rasanya tak perlu sampai harus membela diri
  Itu termasuk ranah kebebasan “artistik” sebagai developer, dan orang-orang sepertinya lupa bahwa software pada dasarnya memang mengandung opini

  • Kalau lihat sebagian tulisan di issue GitHub, ada orang yang tampaknya merasa seolah agamanya diserang
  • Dari komentar-komentarnya, banyak orang tampaknya mengira judul itu membahas Bun secara keseluruhan
  • Betul. Mem-fork dan sekadar menaikkan angka versi minimum tampaknya juga tidak akan sulit. Saya belum melihatnya langsung, tapi besar kemungkinan hanya perlu mengubah satu angka di suatu tempat
    Kalau sekarang berjalan, ya akan tetap berjalan. Hanya saja mereka tidak ingin mendukung dan memelihara itu serta menyelesaikan issue yang muncul
  • Bisa juga dianggap mirip diskriminasi ras atau agama, dalam arti mengecualikan berdasarkan kriteria yang arbitrer dan tidak bermakna
    Jika Bun yang di-port ke Rust memang lebih baik dalam semua aspek terukur, lolos semua tes, performanya sama atau lebih baik, dan juga memperbaiki bug yang ada, lalu kenapa penting ditulis dalam bahasa apa dan diimplementasikan bagaimana? Intinya adalah kualitasnya lebih tinggi
    Jika Anda tidak percaya saat tim Bun merilis dan menyetujui versi Rust itu, maka secara logis juga tidak masuk akal kalau Anda percaya pada versi Zig dua minggu sebelumnya. Itu membuat developer yt-dlp terlihat bodoh

• Saya sangat suka memakai Bun, jadi agak sedih arah perubahannya jadi seperti ini setelah akuisisi Anthropic
  Saya ingin Node yang bagus dengan batteries included, tapi saya tidak ingin itu dibuat dengan vibe coding

  • Saya penasaran apakah pernah benar-benar ada masalah besar yang muncul karena konversi hasil vibe coding ini
    Bukan berarti saya mendukung penggabungannya. Saya juga menentang pendekatan engineering YOLO seperti ini. Hanya saja sejak pengumuman itu saya belum mengikuti kabarnya, jadi penasaran seperti apa proses transisinya berjalan
  • Menurut tim Bun, vibe coding itu ternyata sudah berlangsung selama beberapa bulan bahkan sebelum akuisisi Anthropic
  • Saat akuisisi itu terjadi, orang-orang tampaknya berharap Bun secara umum akan tetap berjalan seperti biasa, dan lucunya harapan itu ternyata dibalik total lalu dihancurkan
    Tentu lucu di sini dalam arti yang menyedihkan dan mengerikan
  • Kalau memang belum ada masalah konkret yang terkonfirmasi akibat “vibe coding”, maka reaksi menolaknya mentah-mentah tanpa memeriksa bukti nyata juga bukankah mirip dengan perilaku yang sedang dikritik?

• Keputusan ini terlihat lebih seperti penilaian politis daripada engineering. Apakah ada yang sudah melihat peningkatan segmentation fault, kehabisan memori, kerentanan keamanan, atau bug di Bun setelah penulisan ulang Rust?
  Tentu belum, karena hasil penulisan ulangnya bahkan belum masuk. Jadi ini tampak seperti keputusan berdasarkan rasa tidak enak terhadap keterlibatan AI
  Alat engineering dipilih bukan berdasarkan perasaan, tetapi berdasarkan apakah alat itu bisa melakukan yang kita inginkan. Kalau nanti bug di Bun bertambah dan terasa seperti software yang lebih buruk, saya tidak akan memakainya, tetapi penilaian itu akan berbasis data. Jarred sudah melakukan banyak hal mengesankan dengan Bun, dan tampaknya kecil kemungkinan dia akan merilis hasil penulisan ulang yang tidak memenuhi standar kualitasnya sendiri, jadi saya akan menunggu dan melihat

  • Sebaliknya, bukan kewajiban pihak yt-dlp untuk bereksperimen apakah proses pengembangan baru Bun akan meningkatkan segmentation fault, kehabisan memori, atau kerentanan keamanan
    Kalau Anda secara masuk akal menganggap ada kemungkinan kerentanan keamanan meningkat, justru akan ceroboh bila menjadikan pengguna sebagai bahan eksperimen
    Pilihan yang bertanggung jawab lebih dekat ke, “kami tidak akan langsung mendukung menjalankan software kami di rilis Bun baru yang dipotong dari main saat ini”
    Hanya saja disayangkan karena ini terlihat bukan sekadar rencana mengevaluasi ulang rilis mendatang, melainkan niat untuk tidak pernah mendukungnya sama sekali. Tentu developer yt-dlp juga tidak berutang apa pun kepada siapa pun
  • Ini tidak harus politis. Bisa saja yt-dlp yang bersikap politis, tetapi prinsip untuk tidak mengadopsi dependency inti di production sampai sudah digunakan luas selama 6 bulan sampai 1 tahun secara umum bukan hal politis
    Penulisan ulang penuh 1 juta baris itu pada dasarnya adalah runtime baru dengan ABI yang sama seperti sebelumnya, dan bagi banyak konsumen turunannya itu bukan sesuatu yang nyaman dijadikan dependency production
    Demi diskusi, sekalipun seluruh Bun ditulis ulang sepenuhnya oleh manusia, situasinya akan tetap sama. Saya rasa keputusan seperti ini cukup standar, dan secara pribadi saya juga menduga kualitas penulisan ulang LLM Bun secara umum akan baik, tetapi saya tidak akan mempertaruhkan produk atau perusahaan saya padanya. Perubahan berisiko adalah sesuatu yang tidak ingin saya tanggung di software saya hanya karena dipaksakan oleh dependency hilir
  • Kalau Anda menunggu sampai segmentation fault, kehabisan memori, dan masalah lain meningkat, berarti Anda sudah gagal menghindari masalah. Saya rasa arah ini benar, dan sejarah akan menunjukkan siapa yang benar
  • Dalam sebuah proyek, governance itu sangat penting. Fakta bahwa para penulis Bun bertekuk lutut pada pemilik baru menunjukkan di mana prioritas mereka berada
    Saya tidak akan duduk diam menunggu sampai bug meledak dan semuanya mulai rusak
    Kalau proyek dikelola oleh orang yang berpikir memilih alat cukup dengan melihat “apakah alat itu melakukan yang saya inginkan”, saya akan menghapusnya dari dependency saya
  • Salah satu elemen inti engineering adalah memprediksi arah lintasan saat ini. Dalam konteks itu, menghindari alat yang memberi firasat buruk sepenuhnya masuk akal
    Waktu termudah untuk menjauh dari alat yang akan jadi tabrakan kereta adalah sebelum alat itu terintegrasi

• Ini memang soal konversi Rust, tetapi belum dirilis
  Mereka menyebut ada “masalah kompatibilitas dan keamanan yang dapat diprediksi”, padahal Bun versi Zig juga cukup sering crash
  Saya ingin sekali kalau yt-dlp memberikan tautan ke dasar rinci kenapa ada masalah kompatibilitas yang dapat diprediksi. Kedua proyek sama-sama punya test suite, jadi di dunia ideal seharusnya penulisan ulang cepat seperti ini bisa dilakukan
  Mungkin mereka memang tidak mau makin memanaskan situasi, tetapi kalau ada masalah spesifik yang ditemukan, saya ingin melihatnya
  Bun.rs seharusnya bukan rilis minor, melainkan 1.4 atau 2.0, dan saya juga berharap ada rilis alpha/beta

  • Kalau memang ada proyek nyata yang melaporkan regresi serius di Bun.rs dan menunjukkan datanya, itu cerita lain
    Tapi ini baru dibuka seminggu, dan sejauh ini hampir tidak terlihat data regresi nyata. Ini lebih tampak seperti gerutuan “ya pokoknya saya tidak suka”

• Logika ini terbaca tidak jauh berbeda dari, “libfoo mulai dikembangkan dengan emacs alih-alih vim, jadi sekarang tidak bisa dipercaya lagi”
  Tentu tidak persis sama, tapi ada alasan kenapa terasa mirip
  Satu-satunya kebenaran dalam software adalah apakah berfungsi untuk use case saya. Bahkan sebelum AI pun kita tidak pernah tahu apakah penulisnya bekerja dengan ketat atau cuma mencoba acak sampai berhasil
  Dengan kata lain, saya tidak pernah menilai software dengan menyelidiki metodologi atau alat yang dipakai. Saya juga sudah sering memakai software yang tidak punya test suite atau test suite-nya berantakan, dan orang yang suka memory safety pun tetap memakai alat yang ditulis dalam C, begitu juga sebaliknya
  Jadi logika “saya tidak akan memakainya karena saya tidak suka cara AI-nya digunakan” terdengar selemah mengatakan Anda berhenti memakai sesuatu karena tidak suka editor yang dipakai penulisnya

  • Jelas ada orang-orang yang benar-benar peduli bagaimana sesuatu dibuat, dan mengambil keputusan berdasarkan apakah mereka setuju dengan proses itu
    Kalau tidak, konsep seperti cokelat/kopi fair trade juga tidak akan ada
  • Analogi itu terlalu berlebihan. Ini harus dibaca sebagai sesuatu yang bahkan bukan di stadion yang sama, apalagi stadion yang berdekatan
  • Kalau begitu kita dorong satu langkah lagi: bayangkan ada cron job yang setiap Senin pertama tiap bulan menulis ulang seluruh codebase ke bahasa baru. Dari Rust ke C++, ke Go, ke Swift, lalu kembali lagi
    Bagi pelanggan yang memakai produknya, apakah itu benar-benar hampir sama saja dengan maintainer mengganti editor, dan hanya detail tak relevan?
  • Kebanyakan orang akan menganggap text editor yang dipakai tidak memberi pengaruh berarti pada kode yang dihasilkan
    Tetapi tidak banyak yang akan mengatakan hal yang sama untuk LLM
    Bisa saja vibe Bun sama bagusnya atau bahkan lebih baik daripada Bun lama, tetapi bagaimana kita bisa tahu itu sekarang?
    Dan soal “kita tidak pernah tahu apakah software dibuat secara ketat, dan tidak pernah menilainya dari metodologi”, itu juga tidak benar. Ada orang yang memang memeriksa sendiri apakah suatu proyek punya tingkat ketelitian yang bisa diterima sebelum mengadopsinya atau memutuskan terus memakainya. Saya juga begitu untuk hal-hal penting
    Lebih banyak lagi orang memakai sinyal reputasi, yang walau tidak sempurna tetap punya korelasi dan bisa cukup berguna, serta jauh lebih mudah daripada audit manual langsung

• Kita sangat butuh istilah baru untuk menjelaskan cara penggunaan LLM dalam pekerjaan pengembangan. “Vibe coding” sebenarnya punya definisi yang cukup ketat, tetapi tampaknya tidak ada yang peduli
  Sulit sekali percaya bahwa porting Rust ini dilakukan 100% sebagai “vibe” murni seperti definisi aslinya
  Ini sudah jadi lumpur campur aduk emosi, baik yang positif maupun negatif, dan kalau “vibe coding” dipakai sebagai istilah peyoratif umum untuk penggunaan LLM, jadi sangat sulit memahami masalah sebenarnya yang sedang dibicarakan
  Saya sendiri memakai LLM untuk membantu pengembangan, dan saya menghasilkan pekerjaan yang lebih baik lebih cepat dalam semua ukuran yang menurut engineer layak dianggap penting

  • Vibe coding awalnya berarti “menyerah pada getaran [...] dan bahkan melupakan bahwa kode itu ada”
    https://x.com/karpathy/status/1886192184808149383
    Untuk porting khusus ini, prosesnya tampak berlangsung terlalu cepat sehingga cukup jelas bahwa manusia tidak memverifikasi validitas terjemahannya. Dan belum jelas juga apakah verifikasi manual sungguhan akan dilakukan ke depan
    Namun kalau memakai standar Dijkstra, sebagian besar proyek software sebenarnya sudah lama melakukan “vibe coding” bahkan jauh sebelum AI muncul. Menyerah pada suasana dan melupakan bahwa ketepatan itu ada
    Menjamin ketepatan kode yang kompleks memang sulit, tetapi sekarang kita hidup di zaman ketika ada 1 miliar hacker di dalam pusat data, sehingga ini makin lama makin bukan pilihan lagi
    Tambahan: “Port Rust Bun yang belum dirilis punya 13.365 blok unsafe”
    https://news.ycombinator.com/item?id=48239790
  • Berlawanan dengan klaim bahwa memakai LLM membuat pekerjaan lebih cepat dan lebih baik, berbagai riset justru mengisyaratkan hasilnya mungkin tidak lebih cepat, bahkan bisa lebih lambat
    Teknologinya masih sangat baru sehingga sulit diteliti, tetapi kalau dilihat secara optimistis pun bukti empirisnya sejauh ini hanya menunjukkan sekitar peningkatan 3% di sebagian area
    Menulis kode jarang menjadi bottleneck dalam pekerjaan kita

• Saya tidak paham kenapa banyak orang merasa tertekan sekali oleh keputusan ini. Kalau memang benar-benar penggemar vibe coding, bukankah mereka bisa saja vibe coding yt-dlp yang lebih baik sendiri atau mem-fork yang ada lalu membuatnya sesuai kebutuhan?

  • Saya sering mendengar bahwa berkat vibe coding, membuat software kini jadi begitu mudah sampai nyaris remeh, dan siapa pun bisa membuatnya dalam sekejap
    Bahkan ada yang bilang orang akan vibe coding software pribadi sekali pakai untuk semua hal
    Kalau begitu, seharusnya para vibe coder tidak punya alasan untuk mengeluh soal keputusan software apa pun. Mem-vibe-code fork pribadi yang lebih mereka sukai seharusnya semudah membalikkan tangan, bukan? Bukankah itu janji vibe coding?
  • Selain itu, yt-dlp sudah punya dukungan plugin interpreter pihak ketiga. Mereka hanya mengatakan tidak ingin mendukung Bun secara langsung, sementara infrastrukturnya untuk orang lain memakai apa yang mereka mau sudah tersedia
    Ini adalah rasa berhak yang keliru yang sering dimiliki orang terhadap proyek yang dipelihara dengan waktu dan usaha orang lain. Sikap yang merasa bebas “menyumbangkan” waktu dan tenaga orang lain demi fitur yang mereka inginkan itu terus terasa mengejutkan
    Orang yang mengerjakan proyeknya berhak mengambil keputusan, dan kalau tidak suka ya fork sendiri. Ekosistem ini memang selalu begitu sejak awal
    yt-dlp bahkan sekarang tergolong cukup mudah diutak-atik
  • Bagi banyak penggemar AI, meski tentu tidak semua, ini hampir berfungsi seperti agama. Mereka tidak puas dengan membiarkan masing-masing hidup sendiri dan sejarah menunjukkan cara membangun software mana yang lebih baik, melainkan menuntut semua orang harus setuju dengan mereka
    Saya juga menghadapi situasi seperti itu di tempat kerja, dan soal AI ini benar-benar bikin gila karena perbedaan pendapat teknis yang jujur jadi tidak diperbolehkan

• Saya tidak tahu harus merasa bagaimana soal penulisan ulang Bun ini
  Di satu sisi, fakta bahwa sebagian besar codebase belum ditinjau terasa sangat menakutkan
  Di sisi lain, dari yang saya dengar semuanya lolos tes nyaris tanpa regresi
  Mungkin karena saya kurang pengalaman di area itu, tetapi saya rasa saya tidak akan cukup percaya pada tes sampai sepenuhnya bergantung padanya tanpa membaca kodenya sama sekali