- Vấn đề này vẫn đang ở trạng thái Open, và bắt đầu từ bản phát hành yt-dlp và/hoặc
ejs tiếp theo, phạm vi hỗ trợ Bun sẽ bị giới hạn từ 1.2.11 trở lên đến 1.3.14 trở xuống, đồng thời bản thân hỗ trợ này cũng được chuyển sang trạng thái dự kiến ngừng hỗ trợ
- yt-dlp sẽ tiếp tục dùng Bun như một JavaScript runtime tương thích với
ejs, nhưng vẫn để ngỏ quyền loại bỏ hoàn toàn hỗ trợ Bun nếu gánh nặng bảo trì tăng quá lớn
- Phiên bản hỗ trợ tối thiểu được nâng từ
1.0.31 lên 1.2.11; nhóm này cho rằng nếu build gói ejs bằng Bun trước 1.2.0 thì file khóa của ejs sẽ bị bỏ qua, và xét đến các cuộc tấn công chuỗi cung ứng npm gần đây thì đây là một lo ngại bảo mật lớn
- Lý do chọn
1.2.11 thay vì 1.2.0 làm mốc dưới là vì ở các phiên bản Bun trước 1.2.11, không thể chạy bộ test của ejs
- Mốc trên được đặt ở
1.3.14, với lý do được đưa ra là đây là bản phát hành cuối cùng vốn được build từ codebase Zig ban đầu
- Việc Bun gần đây được viết lại sang Rust với sự hỗ trợ của Claude, và định hướng phát triển bị cho là đang chuyển sang kiểu “vibe-coded” hoàn toàn, được nêu ra như một vấn đề về gánh nặng bảo trì và độ tin cậy trong tương lai
- Một bình luận phản bác rằng Deno cũng đang “vibe coded”, nhưng quản trị viên trả lời rằng có khác biệt rất lớn giữa sử dụng Claude và phụ thuộc hoàn toàn vào Claude
- Trước câu hỏi rằng từ
1.3.4 đến 1.3.14 cũng có thể đã chịu ảnh hưởng “vibe coding” sau thương vụ Anthropic mua lại, nên có phải cũng cần loại khỏi phạm vi hỗ trợ hay không, quản trị viên trả lời rằng sẽ xem xét
- Một số người dùng phản đối rằng việc chặn chạy Bun mới nhất ngay cả trước khi có lỗi thực tế xảy ra là một hạn chế phòng ngừa thiếu căn cứ, và cho rằng nên đưa ra cảnh báo hoặc cờ tùy chọn để vẫn cho phép tiếp tục chạy
- Một bình luận khác giải thích rằng vì có thể truyền trực tiếp đường dẫn binary Bun vào
--js-runtimes, nên có thể dùng Bun mới nhất như bình thường và chỉ định riêng Bun tĩnh 1.3.14 cho yt-dlp như một cách lách hạn chế
- Trong các thông báo liên quan, issue ngừng hỗ trợ Node v20·v21 và issue nâng phiên bản hỗ trợ tối thiểu của Deno lên
v2.3.0 cũng được liên kết kèm theo; đồng thời có lưu ý rằng tài liệu wiki EJS vẫn chưa phản ánh thay đổi lần này
- Quản trị viên cũng để lại một bình luận ghim nhằm nhắm tới các ý kiến đổ về từ Hacker News, đề nghị mọi người trước khi bình luận hãy tự hỏi liệu mình có thực sự quan tâm đến vấn đề dùng Bun trong yt-dlp hay không
1 bình luận
Ý kiến trên Hacker News
Quyết định này có thể hiểu được. Nếu phần lớn mã nguồn không phải do chính người bảo trì viết, thì việc thật sự hiểu codebase hẳn sẽ rất khó
Trên thực tế, việc rà soát toàn bộ phần code viết lại cũng gần như bất khả thi. Có tới 1 triệu dòng mã https://github.com/oven-sh/bun/pull/30412
Xét cho cùng thì cũng gần như là cùng một nội dung được viết bằng cú pháp khác, nên có vẻ nó chỉ trông khó chịu trong mắt các lập trình viên Rust. Có lẽ các lập trình viên Bun muốn code trông quen thuộc hơn với chính họ
Tuy vậy, tôi nghĩ lẽ ra họ nên gọi đây là 2.0. Như vậy sẽ bớt cảm giác gấp gáp hơn. Ngay cả ở 1.3.14 cũng đã có vài regression, nhưng bây giờ có quá nhiều “đám cháy” nhỏ liên quan đến Rust nên dường như chẳng ai thật sự để tâm
Vấn đề lớn hơn là Bun cứ liên tục chạy theo tính năng mới hào nhoáng mà không hoàn thiện đến nơi đến chốn. Phần test thì là phần lớn của Vitest nhưng không phải toàn bộ, Jest cũng vậy, pnpm cũng vậy. Giờ lại có cả tính năng ảnh, kiểu như phần lớn của sharp nhưng vẫn không phải toàn bộ. Dev server thì là phần lớn của Vite nhưng vẫn chưa đủ. Các tiến trình chạy lâu thì nhìn chung giống Node nhưng lại bị rò rỉ bộ nhớ, và có lẽ đó chính là động cơ cho việc chuyển sang Rust
Khi đọc bài viết về phần xử lý ảnh, tôi thực sự thấy nản. Lại là một món đồ lấp lánh khác, và cộng thêm các lỗi test nên cuối cùng tôi đã chuyển hẳn sang Vitest
Tôi cũng không chắc việc viết lại này là ý tưởng hay và sẽ thành công, nhưng lập luận ngược lại cũng khó mà thấy hợp lý hơn
Không ai biết hơn 1 triệu dòng đó thực sự làm gì. Cũng chẳng ai có nhiệt huyết đặc biệt với nó. Họ nhận yêu cầu, rồi coi mọi thứ ngoài phần bề mặt cần chạm vào như một hộp đen
Thế là xuất hiện 14 implementation service nền làm cùng một việc, 8 dependency cho cùng một vai trò, 6 framework chồng lấn, và phong cách cùng cách tiếp cận thì hoàn toàn không nhất quán. Nhưng rốt cuộc cũng chẳng ai xem đó là điều quá quan trọng
Tôi nghĩ thế vẫn còn hơn “vibe coding” thuần túy, nhưng nếu là phần không quan trọng thì còn tạm chấp nhận được; chứ với hạ tầng cốt lõi đòi hỏi suy nghĩ rất kỹ thì thật khó chấp nhận
Đây đâu phải chuyện phân biệt chủng tộc hay tôn giáo với ai. Nếu không muốn một bề mặt vibe-coded quy mô lớn thì tôi không nghĩ cần phải bào chữa gì cả
Đó là một phần thuộc quyền tự quyết mang tính “nghệ thuật” của lập trình viên, và có vẻ nhiều người quên rằng phần mềm vốn dĩ mang tính quan điểm
Nếu đang chạy được thì nó vẫn sẽ tiếp tục chạy. Chỉ là họ không muốn hỗ trợ và bảo trì nó, cũng như xử lý issue cho nó thôi
Nếu bản Bun được port sang Rust tốt hơn trên mọi phương diện có thể đo được, vượt qua toàn bộ test, hiệu năng ngang hoặc tốt hơn, và còn sửa được các bug cũ, thì vì sao chuyện nó được viết bằng ngôn ngữ gì và triển khai thế nào lại quan trọng? Điều cốt lõi là chất lượng cao hơn
Nếu không thể tin đội Bun khi họ phát hành và phê duyệt bản Rust, thì về mặt logic cũng chẳng có lý do gì để tin bản Zig từ 2 tuần trước. Như vậy trông các lập trình viên yt-dlp mới là người ngớ ngẩn
Tôi thật sự rất thích dùng Bun, nên thấy hướng đi thay đổi thế này sau vụ Anthropic mua lại thì hơi buồn
Tôi muốn một Node tốt theo kiểu có sẵn đủ thứ, nhưng không muốn nó là thứ được vibe coding ra
Không phải tôi ủng hộ việc merge. Tôi phản đối kiểu tiếp cận kỹ thuật YOLO này. Chỉ là từ sau thông báo đó tôi chưa theo dõi tiếp, nên muốn biết quá trình chuyển đổi diễn ra thế nào
Tất nhiên là buồn cười theo nghĩa đau lòng khủng khiếp
Quyết định này trông giống một phán đoán chính trị hơn là một quyết định kỹ thuật. Bạn đã thấy Bun có thêm lỗi segmentation fault, hết bộ nhớ, lỗ hổng bảo mật hay bug sau khi viết lại bằng Rust chưa?
Tất nhiên là chưa, vì bản viết lại còn chưa được đưa vào. Nó giống như đang quyết định chỉ vì cảm thấy khó chịu với việc có AI can dự
Công cụ kỹ thuật nên được chọn dựa trên việc nó có làm được thứ mình muốn hay không, chứ không phải cảm giác. Nếu Bun bắt đầu có nhiều bug hơn và giống phần mềm tệ hơn thì tôi sẽ không dùng, nhưng phán đoán đó sẽ dựa trên dữ liệu. Jarred đã làm được nhiều thứ ấn tượng với Bun, và có vẻ không phải kiểu người sẽ tung ra một bản viết lại không đạt chuẩn chất lượng của chính mình, nên tôi sẽ chờ xem
Nếu họ có lý do hợp lý để nghĩ rủi ro bảo mật có thể tăng lên, thì dùng chính người dùng của họ để thử nghiệm mới là điều có thể xem là cẩu thả
Lựa chọn có trách nhiệm sẽ gần với kiểu “chúng tôi sẽ không ngay lập tức hỗ trợ chạy phần mềm của mình trên bản Bun mới tách ra từ main hiện tại”
Tuy nhiên, điều đáng tiếc là nó không giống một kế hoạch sẽ đánh giá lại các bản phát hành tương lai, mà giống ý định sẽ không bao giờ hỗ trợ nữa. Dĩ nhiên các lập trình viên yt-dlp cũng chẳng nợ ai điều gì
Một bản viết lại 1 triệu dòng thực chất là một runtime mới gần như hoàn toàn, chỉ giữ ABI như trước, và với nhiều bên tiêu thụ phía dưới thì đó là thứ khó chấp nhận làm dependency production
Ngay cả nếu giả sử toàn bộ Bun được con người viết lại thủ công thì tình huống cũng vậy thôi. Tôi thấy kiểu quyết định này khá tiêu chuẩn, và cá nhân tôi cũng nghĩ chất lượng bản viết lại bằng LLM của Bun nhìn chung có lẽ sẽ ổn, nhưng tôi sẽ không đem sản phẩm hay công ty của mình ra cược. Những thay đổi rủi ro là thứ tôi muốn tự chọn trong phần mềm của mình, chứ không muốn bị ép gánh qua dependency cấp dưới
Tôi sẽ không ngồi yên chờ đến khi bug bùng nổ và mọi thứ bắt đầu sụp đổ
Nếu đó là kiểu dự án của người chỉ chọn công cụ dựa trên việc “nó có làm được thứ mình muốn không”, thì tôi sẽ loại nó khỏi dependency của mình
Thời điểm dễ rời khỏi một công cụ có nguy cơ thành tai nạn tàu hỏa nhất là trước khi bạn tích hợp nó
Đây là chuyện về bản chuyển sang Rust, nhưng nó vẫn chưa được phát hành
Họ nói có “các vấn đề tương thích và bảo mật có thể dự đoán được”, nhưng bản Bun Zig cũng crash khá nhiều
Tôi muốn yt-dlp liên kết rõ hơn tới cơ sở chi tiết cho việc vì sao có vấn đề tương thích có thể dự đoán được. Cả hai dự án đều có bộ test, nên trong một thế giới lý tưởng việc viết lại nhanh vẫn phải khả thi
Có thể họ không muốn làm tình hình thêm căng, nhưng nếu có vấn đề cụ thể đã được phát hiện thì tôi muốn xem
Bun.rs đáng ra nên là 1.4 hoặc 2.0, chứ không phải một bản minor release, và cũng nên có alpha/beta release
Nhưng nó mới chỉ công khai được một tuần, và đến giờ gần như chưa thấy dữ liệu regression thực tế nào. Có vẻ gần với kiểu than phiền “tôi chỉ là không thích nó” hơn
Lập luận này đọc lên không khác quá nhiều so với kiểu “libfoo bắt đầu được phát triển bằng emacs thay vì vim nên không thể tin nữa”
Tất nhiên không hoàn toàn giống hệt, nhưng có lý do để nó tạo cảm giác tương tự
Trong phần mềm, sự thật duy nhất là nó có hoạt động với use case của tôi hay không. Ngay cả trước thời AI, ta cũng đâu biết tác giả làm việc một cách nghiêm ngặt hay chỉ thử ngẫu nhiên đến khi chạy được
Nói cách khác, tôi chưa từng đánh giá phần mềm bằng cách điều tra phương pháp luận hay công cụ tác giả dùng. Tôi đã dùng rất nhiều phần mềm không có test suite hoặc test suite tệ hại, và những người thích an toàn bộ nhớ vẫn dùng công cụ viết bằng C, chiều ngược lại cũng vậy
Vì thế lập luận kiểu “tôi không thích cách dùng AI nên sẽ không dùng” nghe kém thuyết phục chẳng khác mấy việc nói sẽ ngừng dùng chỉ vì không thích trình soạn thảo của tác giả
Nếu không thì khái niệm như sô-cô-la/cà phê fair trade đã chẳng tồn tại
Với khách hàng dùng sản phẩm, chuyện đó cũng gần như tương đương việc người bảo trì đổi editor, một chi tiết không liên quan sao?
Nhưng không nhiều người sẽ nói điều đó với LLM
Bun kiểu vibe có thể tốt ngang hoặc hơn Bun cũ, nhưng ở thời điểm này làm sao chúng ta biết được?
Và câu “ta đâu biết phần mềm có được làm nghiêm ngặt hay không, nên không đánh giá theo phương pháp luận” cũng không đúng. Một số người thật sự tự kiểm tra xem có mức độ nghiêm ngặt chấp nhận được hay không trước khi nhận một dự án hoặc quyết định tiếp tục dùng nó. Tôi cũng làm vậy ở những chỗ quan trọng
Nhiều người khác dùng các tín hiệu danh tiếng; chúng không hoàn hảo nhưng có tương quan và có thể là đủ, lại dễ hơn rất nhiều so với tự rà soát thủ công
Rất cần một thuật ngữ mới để mô tả cách dùng LLM trong công việc phát triển. “Vibe coding” vốn có một định nghĩa khá chặt, nhưng dường như chẳng ai quan tâm
Thật khó tin bản port sang Rust này được làm 100% theo kiểu “vibe” như định nghĩa ban đầu
Nó đã biến thành một mớ bùn cảm xúc, cả tích cực lẫn tiêu cực, và nếu dùng “vibe coding” như một từ miệt thị chung cho việc dùng LLM thì sẽ rất khó xác định người ta thật ra đang muốn nói vấn đề gì
Tôi đang dùng LLM để hỗ trợ phát triển, và đang làm việc tốt hơn, nhanh hơn trên mọi thước đo mà một kỹ sư có thể coi trọng
https://x.com/karpathy/status/1886192184808149383
Trong trường hợp bản port cụ thể này, nó diễn ra quá nhanh đến mức có vẻ rõ ràng là con người đã không xác minh tính đúng đắn của phần chuyển đổi. Việc xác minh thủ công có thực sự diễn ra trong tương lai hay không cũng chưa rõ
Tuy nhiên, theo tiêu chuẩn của Dijkstra thì từ rất lâu trước khi AI xuất hiện, phần lớn các dự án phần mềm đã là “vibe coding” rồi. Kiểu phó mặc cho cảm giác và quên mất rằng tính đúng đắn là thứ có tồn tại
Việc đảm bảo tính đúng đắn của mã phức tạp vốn rất khó, nhưng nay khi chúng ta sống trong thời đại có 1 tỷ hacker trong trung tâm dữ liệu, điều đó sẽ ngày càng không còn là chuyện tùy chọn nữa
Bổ sung: “Bản port Rust chưa phát hành của Bun có 13.365 khối
unsafe”https://news.ycombinator.com/item?id=48239790
Vì đây là công nghệ còn quá mới nên nghiên cứu khá khó, nhưng ngay cả nhìn lạc quan thì bằng chứng thực nghiệm cũng chỉ cho thấy mức cải thiện khoảng 3% trong một số lĩnh vực
Viết code hiếm khi là nút thắt cổ chai trong công việc của chúng ta
Tôi không hiểu vì sao nhiều người lại cảm thấy bị áp lực vì quyết định này đến thế. Nếu thật sự là người mê vibe coding, chẳng phải họ có thể tự vibe code một yt-dlp tốt hơn, hoặc fork cái hiện có rồi chỉnh theo ý mình sao?
Thậm chí người ta còn nói mọi người sẽ vibe code phần mềm dùng một lần cho cá nhân mình cho đủ mọi việc
Vậy thì các vibe coder lẽ ra chẳng có lý do gì để than phiền về bất kỳ quyết định phần mềm nào. Vibe code ra một bản fork cá nhân hợp ý hơn chẳng phải phải dễ như ăn cháo sao? Chẳng phải đó là lời hứa của vibe coding sao?
Đây là kiểu cảm giác có quyền sai lầm mà người ta hay có với những dự án được duy trì bằng thời gian và công sức của người khác. Việc cứ muốn tình nguyện hóa thời gian và công sức của người khác cho tính năng mình muốn thật sự lúc nào cũng gây sốc
Những người làm việc mới có quyền đưa ra quyết định, và nếu không thích thì cứ tự fork. Hệ sinh thái này ngay từ đầu vốn đã như vậy
yt-dlp hiện tại cũng vẫn là thứ dễ đụng vào hơn bạn tưởng
Tôi cũng đang gặp cảnh đó ở nơi làm việc, và việc với AI thì ngay cả bất đồng kỹ thuật một cách chân thành cũng không được chấp nhận thực sự khiến tôi phát điên
Tôi không biết nên cảm thấy thế nào về việc Bun viết lại
Một mặt, việc phần lớn codebase chưa được review nghe cực kỳ đáng sợ
Mặt khác, theo những gì tôi nghe thì nó vẫn vượt qua test mà hầu như không có regression
Có thể là do tôi thiếu kinh nghiệm ở mảng đó, nhưng tôi không nghĩ mình sẽ tin test đến mức dựa hoàn toàn vào nó mà không cần đọc code