การรองรับ Bun ถูกจำกัดแล้วและเตรียมเข้าสู่สถานะเลิกใช้งาน
(github.com/yt-dlp)- ประเด็นนี้ยังคงอยู่ในสถานะ Open และตั้งแต่รีลีสถัดไปของ yt-dlp และ/หรือ
ejsเป็นต้นไป ขอบเขตการรองรับ Bun จะถูกจำกัดไว้ที่เวอร์ชัน1.2.11ขึ้นไปจนถึง1.3.14และการรองรับดังกล่าวก็จะถูกเปลี่ยนเป็นสถานะเตรียมเลิกใช้งานด้วย - yt-dlp จะยังคงใช้ Bun ต่อไปในฐานะ JavaScript runtime ที่เข้ากันได้กับ
ejsแต่ก็ขอสงวน สิทธิ์ในการถอดการรองรับ Bun ออกทั้งหมด หากภาระในการดูแลรักษาสูงเกินไป - เวอร์ชันขั้นต่ำที่รองรับจะถูกยกจาก
1.0.31เป็น1.2.11โดยมองว่าการ build แพ็กเกจejsด้วย Bun รุ่นก่อน1.2.0จะทำให้ lockfile ของejsถูกละเลย ซึ่งเป็นข้อกังวลด้านความปลอดภัยอย่างมากเมื่อพิจารณาถึงการโจมตี supply chain ของ npm ที่เกิดขึ้นล่าสุด - เหตุผลที่ตั้งค่าขั้นต่ำไว้ที่
1.2.11แทนที่จะเป็น1.2.0คือ Bun ก่อน1.2.11ไม่สามารถรันejstest suite ได้ - เวอร์ชันสูงสุดถูกกำหนดไว้ที่
1.3.14โดยให้เหตุผลว่าเป็นรีลีสสุดท้ายที่ build จาก codebase เดิมซึ่งเขียนด้วย Zig - มีการหยิบยกประเด็นว่า Bun เพิ่งถูกเขียนใหม่เป็น Rust โดยใช้ Claude และทิศทางการพัฒนาดูเหมือนกำลังมุ่งไปทาง “vibe-coded” ทั้งหมด ซึ่งอาจทำให้ภาระการบำรุงรักษาและปัญหาด้านความน่าเชื่อถือเพิ่มขึ้นในอนาคต
- มีความเห็นหนึ่งโต้ว่า Deno ก็ “vibe coded” เช่นกัน แต่ผู้ดูแลตอบว่าระหว่าง การใช้ Claude กับ การพึ่งพา Claude อย่างสมบูรณ์ นั้นมีความแตกต่างกันมาก
- เมื่อมีคำถามว่าเวอร์ชัน
1.3.4ถึง1.3.14เองก็อาจได้รับผลกระทบจาก “vibe coding” หลังการเข้าซื้อโดย Anthropic และควรถูกตัดออกจากการรองรับด้วยหรือไม่ ผู้ดูแลตอบว่าจะนำไปพิจารณา - ผู้ใช้บางส่วนคัดค้านว่าการบล็อก Bun รุ่นล่าสุดตั้งแต่ก่อนเกิดปัญหาจริงเป็นการจำกัดเชิงรุกที่ไม่มีหลักฐานรองรับ และควรมีเพียงคำเตือนหรือแฟลกเพื่อให้ยังรันต่อได้
- อีกความเห็นอธิบายว่าสามารถส่งพาธของไบนารี Bun โดยตรงให้กับ
--js-runtimesได้ ดังนั้นจึงสามารถใช้ Bun รุ่นล่าสุดตามปกติ และระบุ Bun1.3.14แบบ static สำหรับ yt-dlp โดยเฉพาะเป็นทางอ้อมได้ - ในประกาศที่เกี่ยวข้อง ยังมีการเชื่อมโยงไปยังประเด็นยุติการรองรับ Node v20·v21 และประเด็นยกเวอร์ชันขั้นต่ำของ Deno เป็น
v2.3.0พร้อมระบุว่า เอกสาร EJS บนวิกิ ยังไม่ได้สะท้อนการเปลี่ยนแปลงครั้งนี้ - ผู้ดูแลได้ปักหมุดความเห็นโดยคำนึงถึงคอมเมนต์จากผู้ใช้ที่หลั่งไหลมาจาก Hacker News ว่า ก่อนจะแสดงความคิดเห็น ขอให้คิดก่อนว่าคุณสนใจปัญหาการใช้ Bun ใน yt-dlp จริงหรือไม่
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เข้าใจการตัดสินใจนี้นะ ถ้าโค้ดส่วนใหญ่ไม่ได้เขียนโดยผู้ดูแลเอง ก็คงยากที่จะ เข้าใจ codebase อย่างแท้จริง
เอาจริง ๆ แค่จะรีวิวโค้ดที่เขียนใหม่ทั้งหมดก็แทบเป็นไปไม่ได้แล้ว เพราะมีโค้ดมากถึง 1 ล้านบรรทัด https://github.com/oven-sh/bun/pull/30412
โดยรวมมันก็ใกล้เคียงกับการเขียนสิ่งเดิมด้วยไวยากรณ์อีกแบบหนึ่ง และคงดูไม่สวยในสายตานักพัฒนา Rust มากกว่า ดูเหมือนทีมนักพัฒนา Bun แค่อยากได้โค้ดที่ดูคุ้นมือสำหรับพวกเขาเอง
แต่ถึงอย่างนั้นก็ยังคิดว่านี่ควรถูกเรียกว่า 2.0 มากกว่า แบบนั้นคงไม่ให้ความรู้สึกรีบร้อนขนาดนี้ ตอนนี้แม้แต่ 1.3.14 ก็ยังมี regression อยู่บ้าง แต่บรรยากาศตอนนี้เหมือนมีเรื่องไฟไหม้เล็ก ๆ เกี่ยวกับ Rust มากเกินไปจนไม่มีใครสนใจมากนัก
ปัญหาใหญ่กว่านั้นคือ Bun มักจะไล่ตาม ฟีเจอร์ใหม่แวววาว ตลอดโดยไม่ค่อยปิดงานให้สมบูรณ์ การทดสอบรองรับ Vitest เกือบทั้งหมดแต่ไม่ทั้งหมด, Jest ก็เกือบทั้งหมดแต่ไม่ทั้งหมด, pnpm ก็เช่นกัน ตอนนี้ยังมีฟีเจอร์รูปภาพเข้ามาอีก เลยกลายเป็น sharp เกือบทั้งหมดแต่ไม่ทั้งหมด dev server ก็เป็น Vite เกือบทั้งหมดแต่ก็ยังไม่ทั้งหมด กระบวนการที่รันระยะยาวก็คล้าย Node พอสมควรแต่มี memory leak และนั่นก็น่าจะเป็นแรงจูงใจของการย้ายไป Rust
ตอนอ่านโพสต์เรื่อง image routines แล้วรู้สึกหมดแรงไปเลย มันดูเป็นของเล่นแวววาวชิ้นใหม่อีกชิ้น และพอเจอบั๊กในระบบทดสอบซ้อนเข้าไป สุดท้ายก็เลยย้ายไป Vitest แบบเต็มตัว
ผมไม่ได้มั่นใจว่าการเขียนใหม่นี้เป็นไอเดียที่ดีและจะสำเร็จ แต่เหตุผลฝั่งตรงข้ามก็ดูน่าเชื่อยากพอ ๆ กัน
ไม่มีใครรู้เลยว่าโค้ด มากกว่า 1 ล้านบรรทัด นั้นทำอะไร และก็ไม่มีใครอินกับมันจริง ๆ ด้วย รับ requirement มา แล้วมองทุกอย่างเป็นกล่องดำ ยกเว้นพื้นผิวส่วนที่ต้องไปแตะ
ผลก็คือมี background service ที่ทำงานซ้ำกัน 14 ตัว, dependency ที่บทบาทซ้ำกัน 8 ตัว, framework ที่ทับซ้อนกัน 6 ชุด, สไตล์และแนวทางที่ไม่สอดคล้องกันโดยสิ้นเชิง แต่ก็ไม่มีใครเห็นว่าเป็นเรื่องใหญ่
ยังดีกว่า “vibe coding” ล้วน ๆ แต่ถ้าเป็นส่วนที่ไม่สำคัญก็พอรับได้ ทว่าใน core infrastructure ที่ต้องคิดลึกจริง ๆ ผมรับไม่ได้
นี่ไม่ใช่การเลือกปฏิบัติต่อเชื้อชาติหรือศาสนาของใครเลย ถ้าไม่อยากได้ พื้นผิวที่ถูก vibe coding ในระดับใหญ่ จำเป็นด้วยหรือที่จะต้องคอยแก้ตัว
มันเป็นดุลยพินิจเชิง “ศิลปะ” ของนักพัฒนา และคนเหมือนลืมไปว่าซอฟต์แวร์นั้นโดยเนื้อแท้แล้ว มีมุมมองและความเห็นปะปนอยู่
ถ้ามันทำงานอยู่แล้วก็น่าจะทำงานต่อไปได้ เพียงแต่พวกเขาไม่อยาก รองรับและดูแลรักษา มัน รวมถึงไม่อยากแก้ issue ต่าง ๆ เท่านั้นเอง
ถ้า Bun เวอร์ชันที่พอร์ตเป็น Rust ดีกว่าในทุกแง่วัดผลได้ ผ่านการทดสอบทั้งหมด ประสิทธิภาพเท่าเดิมหรือดีกว่า และยังแก้บั๊กเก่าได้ด้วย แล้วภาษาไหนที่ใช้เขียนหรือวิธี implementation เป็นอย่างไรจะสำคัญไปทำไม ประเด็นคือ คุณภาพมันสูงกว่า
ถ้าคุณไม่เชื่อถือเวอร์ชัน Rust ทั้งที่ทีม Bun เป็นคน release และ approve เอง ก็ไม่มีเหตุผลเชิงตรรกะเหมือนกันว่าทำไมเมื่อ 2 สัปดาห์ก่อนถึงเชื่อถือเวอร์ชัน Zig ได้ แบบนี้นักพัฒนา yt-dlp ก็ดูเหมือนทำเรื่องโง่ ๆ
ผมชอบใช้ Bun มากจริง ๆ เลยค่อนข้างเศร้าที่ทิศทางมันเปลี่ยนไปแบบนี้หลัง Anthropic เข้าซื้อกิจการ
ผมอยากได้ Node ที่ดีแบบรวมแบตเตอรี่มาครบ แต่ไม่ได้อยากให้มันเป็นของที่ vibe coding มา
ไม่ได้หมายความว่าผมสนับสนุนการ merge นะ ผมก็ไม่ชอบแนวทางวิศวกรรมแบบ YOLO แบบนี้เหมือนกัน แค่ตั้งแต่ประกาศมาก็ไม่ได้ตามข่าว เลยอยากรู้ว่าการเปลี่ยนผ่านเป็นอย่างไรบ้าง
แน่นอนว่าเป็นความขำในความหมายที่เศร้ามาก
การตัดสินใจนี้ดูเหมือนเป็น การตัดสินทางการเมือง มากกว่าวิศวกรรม คุณเห็นหรือยังว่า Bun หลังเขียนใหม่ด้วย Rust มี segmentation fault, out-of-memory, ช่องโหว่ความปลอดภัย หรือบั๊กเพิ่มขึ้น?
แน่นอนว่ายังไม่เห็นอยู่แล้ว เพราะเวอร์ชันเขียนใหม่ยังไม่ได้ถูกนำเข้าเลย มันเลยดูเหมือนการตัดสินเพราะรู้สึกไม่ดีกับการมี AI เข้ามาเกี่ยวข้อง
เครื่องมือวิศวกรรมเราควรเลือกจากว่ามันทำงานที่ต้องการได้ไหม ไม่ใช่จากความรู้สึก ถ้า Bun มีบั๊กมากขึ้นและกลายเป็นซอฟต์แวร์ที่แย่ลง ผมก็จะไม่ใช้มัน แต่การตัดสินนั้นจะอิงกับ ข้อมูล Jarred ทำเรื่องน่าประทับใจกับ Bun มาเยอะ และก็ดูไม่น่าจะปล่อยงานเขียนใหม่ที่ไม่ผ่านมาตรฐานคุณภาพของตัวเองออกมา ดังนั้นผมจะรอดูต่อไป
ถ้าคุณเชื่ออย่างมีเหตุผลว่ามีความเป็นไปได้ที่ช่องโหว่ความปลอดภัยจะเพิ่มขึ้น การเอาผู้ใช้มาทดลองก็อาจถือว่าประมาทได้
ทางเลือกที่รับผิดชอบกว่าคือประมาณว่า “เราจะไม่รองรับการรันซอฟต์แวร์ของเราบน Bun release ใหม่ที่ตัดมาจาก main ตอนนี้ในทันที”
แต่ก็น่าเสียดายที่มันดูไม่ใช่แผนจะกลับมาประเมิน release ในอนาคตใหม่ แต่ออกแนวตั้งใจว่าจะไม่รองรับอีกต่อไปเลย แน่นอนว่า yt-dlp dev ก็ไม่ได้ติดหนี้ใครอยู่
การเขียนใหม่ทั้งก้อน 1 ล้านบรรทัดคือ runtime ใหม่แทบทั้งหมด แม้จะมี ABI เดิมก็ตาม และสำหรับ downstream consumer หลายราย มันเป็นสิ่งที่ไม่สบายใจจะใช้เป็น production dependency
เพื่อให้ถกกันได้ตรง ๆ ต่อให้ Bun ถูกเขียนใหม่ทั้งหมดด้วยมือโดยมนุษย์ สถานการณ์ก็คงเหมือนเดิม ผมคิดว่าการตัดสินใจแบบนี้ค่อนข้างมาตรฐาน และส่วนตัวก็คิดว่าคุณภาพของการเขียนใหม่ด้วย LLM ของ Bun โดยรวมคงดี แต่ผมจะไม่เอาผลิตภัณฑ์หรือบริษัทของตัวเองไปเสี่ยงด้วย การเปลี่ยนแปลงที่เสี่ยง ผมอยากเป็นคนเลือกเองในซอฟต์แวร์ของผม ไม่ใช่ถูกบังคับรับเพราะ dependency ข้างล่าง
ผมจะไม่รอนั่งดูจนกว่าบั๊กจะระเบิดแล้วทุกอย่างพัง
ถ้าเป็นโปรเจกต์ของคนที่คิดแค่ว่า “เครื่องมือทำสิ่งที่ต้องการได้ไหม” แล้วจบ ผมก็จะเอาออกจาก dependency ของผม
เวลาที่ง่ายที่สุดในการหนีจากเครื่องมือที่มีแววจะกลายเป็นรถไฟตกราง ก็คือก่อนที่คุณจะ integrate มันเข้าไป
เรื่องนี้เกี่ยวกับการแปลงเป็น Rust แต่ตอนนี้ยังไม่ได้ release
เขาพูดถึง “ปัญหาความเข้ากันได้และความปลอดภัยที่คาดการณ์ได้” แต่ Bun เวอร์ชัน Zig ก็ crash บ่อยพอตัวเหมือนกัน
ผมอยากให้ yt-dlp ลิงก์เหตุผลเชิงรายละเอียดว่าทำไมถึงมี ปัญหาความเข้ากันได้ที่คาดการณ์ได้ ทั้งสองโปรเจกต์ก็มี test suite กันอยู่แล้ว ดังนั้นในโลกอุดมคติการเขียนใหม่อย่างรวดเร็วก็น่าจะเป็นไปได้
อาจเป็นเพราะไม่อยากยั่วยุสถานการณ์ให้ร้อนแรงขึ้น แต่ถ้ามีปัญหาเฉพาะที่พบจริง ผมก็อยากเห็น
Bun.rs ควรเป็นไม่ใช่แค่ minor release แต่เป็น 1.4 หรือ 2.0 และก็น่าจะมี alpha/beta release ด้วย
แต่ตอนนี้มันเพิ่งเปิดเผยได้แค่สัปดาห์เดียว และจนถึงตอนนี้ก็แทบยังไม่เห็นข้อมูล regression จริง ดูเหมือนการบ่นแนว “ก็แค่ไม่ชอบ” มากกว่า
ตรรกะแบบนี้อ่านแล้วไม่ต่างจาก “libfoo เริ่มพัฒนาด้วย emacs แทน vim แล้ว งั้นคงเชื่อถือไม่ได้อีกต่อไป” มากนัก
แน่นอนว่ามันไม่เหมือนกันเป๊ะ แต่มีเหตุผลที่ทำให้รู้สึกคล้ายกัน
ความจริงเพียงหนึ่งเดียวของซอฟต์แวร์คือมัน ทำงานได้ไหม สำหรับ use case ของผม ก่อนยุค AI เราก็ไม่รู้เหมือนกันว่าผู้เขียนทำอย่างเคร่งครัดหรือสุ่มลองไปเรื่อยจนใช้ได้
พูดอีกแบบคือ ผมไม่เคยตัดสินซอฟต์แวร์จากวิธีการหรือเครื่องมือที่ใช้สร้างมัน ผมใช้ซอฟต์แวร์ตั้งมากที่ไม่มี test suite หรือมีแบบเละเทะ และคนที่ชอบ memory safety ก็ยังใช้เครื่องมือที่เขียนด้วย C เช่นกัน เช่นเดียวกับฝั่งตรงข้าม
เพราะงั้นตรรกะว่า “ฉันไม่ชอบวิธีใช้ AI เลยจะไม่ใช้มัน” เลยฟังดูไม่น่าเชื่อถือพอ ๆ กับการเลิกใช้เพราะไม่ชอบ editor ที่ผู้เขียนใช้
ไม่อย่างนั้นแนวคิดอย่าง ช็อกโกแลต/กาแฟแฟร์เทรด ก็คงไม่เกิดขึ้น
สำหรับลูกค้าที่ใช้ผลิตภัณฑ์อยู่ สิ่งนี้จะเป็นแค่รายละเอียดไม่เกี่ยวข้อง พอ ๆ กับการที่ผู้ดูแลเปลี่ยน editor จริงหรือ?
แต่คงมีไม่กี่คนที่จะพูดแบบเดียวกันกับ LLM
Bun แบบ vibe อาจจะดีเท่าหรือดีกว่า Bun เดิมก็ได้ แต่ตอนนี้เราจะรู้ได้อย่างไร?
อีกอย่าง คำพูดที่ว่า “เราไม่เคยรู้ว่าซอฟต์แวร์ถูกสร้างอย่างเคร่งครัดหรือไม่ และไม่เคยตัดสินจากวิธีวิทยา” ก็ไม่จริงนัก บางคนตรวจสอบเองจริง ๆ ว่ามีความเคร่งครัดในระดับที่ยอมรับได้ไหม ก่อนจะรับโปรเจกต์มาใช้หรือก่อนจะตัดสินใจใช้ต่อ ผมเองก็ทำแบบนั้นในจุดสำคัญ
คนอีกจำนวนมากใช้สัญญาณด้านชื่อเสียง ซึ่งแม้ไม่สมบูรณ์แบบ แต่ก็มีความสัมพันธ์พอสมควรและอาจเพียงพอ อีกทั้งง่ายกว่าการรีวิวด้วยมือเองมาก
เราต้องการ คำศัพท์ใหม่ อย่างมากเพื่ออธิบายรูปแบบการใช้ LLM ในงานพัฒนา ตอนนี้ “vibe coding” มีนิยามที่ค่อนข้างชัด แต่ดูเหมือนไม่มีใครสนใจ
มันยากมากจะเชื่อว่าการพอร์ต Rust ครั้งนี้ทำแบบ “vibe” 100% ตามนิยามดั้งเดิมจริง ๆ
ตอนนี้มันกลายเป็นหล่มอารมณ์ทั้งด้านบวกและลบ และเมื่อใช้ “vibe coding” เป็นเหมือน คำด่ารวมสำหรับการใช้ LLM ก็ยิ่งยากที่จะเข้าใจว่าจริง ๆ แล้วกำลังชี้ปัญหาอะไรกันแน่
ผมเองใช้ LLM มาช่วยพัฒนา และทำงานได้ดีกว่าเดิม เร็วกว่าเดิม ในทุกตัวชี้วัดที่วิศวกรน่าจะใส่ใจ
https://x.com/karpathy/status/1886192184808149383
สำหรับการพอร์ตครั้งนี้โดยเฉพาะ มันเดินเร็วมากจนดูชัดเจนว่าไม่มีมนุษย์มาตรวจสอบ ความถูกต้องสมเหตุสมผล ของการแปล และก็ยังไม่แน่ชัดด้วยว่าในอนาคตจะมีการตรวจสอบด้วยมือจริงหรือไม่
แต่ถ้าวัดตามมาตรฐานของ Dijkstra โปรเจกต์ซอฟต์แวร์ส่วนใหญ่ก็ “vibe coding” กันอยู่แล้วตั้งแต่นานก่อนมี AI ในความหมายที่ว่าปล่อยไปตามฟีลและลืมไปว่าความถูกต้องมีอยู่จริง
การรับประกันความถูกต้องของโค้ดซับซ้อนเป็นเรื่องยาก แต่ตอนนี้เราอยู่ในยุคที่มีแฮกเกอร์พันล้านคนอยู่ในดาต้าเซ็นเตอร์ มันจะยิ่งกลายเป็นสิ่งที่เลือกมองข้ามไม่ได้
เพิ่มเติม: “Rust port ของ Bun ก่อน release มี unsafe block 13,365 จุด”
https://news.ycombinator.com/item?id=48239790
เทคโนโลยียังใหม่มาก เลยศึกษาได้ยาก แต่ถ้ามองในแง่ดีที่สุด หลักฐานเชิงประจักษ์ก็ยังเห็นเพียงการปรับดีขึ้นราว 3% ในบางด้านเท่านั้น
การเขียนโค้ดเองก็มักไม่ใช่คอขวดของงานเราอยู่แล้ว
ไม่เข้าใจว่าทำไมหลายคนถึงรู้สึกกดดันกับการตัดสินใจนี้มากขนาดนั้น ถ้าเป็น คนรัก vibe coding จริง ก็เขียน yt-dlp ที่ดีกว่าเองแบบ vibe coding หรือไม่ก็ fork ของเดิมมาทำตามต้องการสิ?
ถึงขั้นมีคนบอกว่าเราจะ vibe code ซอฟต์แวร์ใช้ครั้งเดียวเฉพาะตัวสำหรับทุกเรื่องกันเลย
ถ้าอย่างนั้นพวก vibe coder ก็ไม่ควรมีเหตุผลจะบ่นเรื่องการตัดสินใจด้านซอฟต์แวร์ใด ๆ เลยไม่ใช่หรือ แค่ vibe code personal fork ที่ตัวเองชอบกว่าน่าจะง่ายเหมือนปลอกกล้วยเข้าปาก นี่ไม่ใช่ คำสัญญาของ vibe coding หรอกหรือ?
นี่คือความรู้สึกว่าตัวเองมีสิทธิ์เหนือเวลาและแรงงานของคนอื่นอย่างผิด ๆ ที่คนมักมีกับโปรเจกต์ที่มีคนคอยดูแลให้ฟรี ท่าทีที่อยากเกณฑ์เวลาและแรงของคนอื่นให้มาอาสาทำฟีเจอร์ที่ตัวเองต้องการยังทำให้ผมช็อกได้เสมอ
คนที่ลงมือทำงานมีสิทธิ์ตัดสินใจ และถ้าไม่ชอบก็ไป fork เองได้ ecosystem นี้ก็เป็นแบบนั้นมาตั้งแต่แรก
ตอนนี้ yt-dlp ก็ยังน่าแปลกใจที่แก้ไขต่อได้ค่อนข้างง่าย
ในที่ทำงานผมก็เจอสภาพแบบนี้อยู่ และเรื่องที่ทำให้แทบบ้าคือเกี่ยวกับ AI นั้นกลับไม่เปิดพื้นที่ให้มีความเห็นต่างทางเทคนิคอย่างตรงไปตรงมาเลย
ผมเองก็ไม่รู้ว่าควรรู้สึกอย่างไรกับการเขียน Bun ใหม่
ด้านหนึ่ง การที่ codebase ส่วนใหญ่ ไม่ได้รับการรีวิว มันน่ากลัวมาก
แต่อีกด้านก็ได้ยินมาว่ามันผ่านการทดสอบโดยแทบไม่มี regression เลย
อาจเป็นเพราะผมไม่มีประสบการณ์ด้านนั้นมากพอ แต่ผมคงไม่ไว้ใจการทดสอบมากขนาดจะพึ่งมันทั้งหมดโดยไม่อ่านโค้ดเลย