- PR #30412 là thay đổi viết lại Bun bằng Rust, đã được merge từ nhánh
claude/phase-a-port vào main vào ngày 14 tháng 5 năm 2026
- Quy mô thay đổi được hiển thị là 6.755 commit, 2.188 tệp,
+1,009,257/-4,024 dòng
- Jarred-Sumner cho biết bài viết blog chứa thông tin chi tiết sẽ sớm được công bố
- Thay đổi này được mô tả là đã vượt qua bộ test hiện có của Bun trên mọi nền tảng, đồng thời sửa nhiều lỗi rò rỉ bộ nhớ và các bài test không ổn định
- Kích thước binary đã giảm 3MB~8MB, và benchmark được mô tả là trung lập hoặc nhanh hơn
- Lý do quan trọng nhất được đưa ra là đội ngũ giờ đây có thể bắt và ngăn ngừa các lỗi bộ nhớ mà nhóm đã tốn nhiều năm phát triển và gỡ lỗi, bằng các công cụ hỗ trợ từ compiler
- Codebase nhìn chung vẫn giữ nguyên, và kiến trúc cùng cấu trúc dữ liệu cũng được mô tả là không thay đổi
- Bun vẫn tiếp tục dùng ít thư viện bên thứ ba, và cũng nêu rõ là không sử dụng async Rust
- Người dùng có thể thử thay đổi này bằng
bun upgrade --canary
- Jarred-Sumner đã đề nghị hãy tạo issue nếu gặp vấn đề, và cho biết có thể khóa thread nếu cuộc thảo luận trở nên quá nóng
- Trước khi được đưa vào bản không-canary, vẫn còn công việc tối ưu hóa cần hoàn thành
- Công việc dọn dẹp cũng vẫn còn, và sẽ được thực hiện qua một chuỗi PR tiếp theo
4 bình luận
Wow, một PR cả triệu dòng đã được merge. Từ Zig sang Rust luôn một phát.
Cứ nói là không biết cái này có được merge hay không cơ~~ mà chỉ trong một tuần đã đổi ngôn ngữ của đoạn code đang chạy tốt chỉ trong một cú, haha.
Có cảm giác như đang xảy ra một sự kiện mang tính cột mốc nhờ AI-assisted coding.
Thật luôn à, trước đó còn bảo chỉ đang thử nghiệm thôi và khả năng cao là sẽ không dùng mà.
Vì Zig không làm nên chuyển thẳng sang Rust luôn, gan thật ghê
Bình luận trên Hacker News
Nếu trong phần công bố họ nói việc viết lại chỉ mất 1 tuần, thì tôi tự hỏi đã mất bao lâu để chuẩn bị file hướng dẫn cực kỳ chi tiết này nhằm ánh xạ các thành ngữ Zig sang thành ngữ Rust: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
Hơn nữa, nếu nhìn vào các mục
Pointers & ownershipvàCollections, có vẻ codebase của Bun đã dùng sẵn các kiểu smart pointer nội bộ để có thể ánh xạ 1:1 với các đối tượng tương ứng trong Rust, và crate Rustbun_collectionscũng đã tồn tại sẵnCó vẻ việc viết lại này đã được chuẩn bị từ rất lâu và là điều đội Bun đề xuất trong quá trình đàm phán mua lại với Anthropic
Số tiền liên quan quá lớn nên rõ ràng có động cơ cài đội marketing trá hình vào cộng đồng, và một số người thì đơn giản là bị cuốn vào logic phe phái
Một khi Anthropic đã sở hữu Bun, họ cũng có đầy đủ động cơ để khiến công việc này trông dễ hơn thực tế
Quy mô đầu ra lớn đến mức ở đây có vẻ có hiệu ứng nhân lên
Tuy vậy, tôi vẫn tò mò không biết cần bao nhiêu tri thức ngầm để tạo ra các quy tắc này, và file này đã được tinh chỉnh lặp đi lặp lại đến mức nào
Ví dụ, tôi muốn biết có bao nhiêu quy tắc trong số này xuất phát từ các ca thất bại gặp phải trong quá trình lặp dịch
using internal smart pointer types that map 1-to-1 to Rust equivalents, nhưng smart pointer không phải do Rust phát minh raNếu bạn viết code bằng ngôn ngữ khác có con trỏ, thì bạn đã mô hình hóa các kiểu tương tự trong đầu rồi
Và chuyện crate Rust
bun_collectionsđã tồn tại sẵn cũng là saiNó chỉ là một phần của PR trong codebase thôi, chứ không phải đã có từ trước
Sẽ rất dễ để bớt bị nghi ngờ và làm không khí IPO nóng hơn nữa nếu họ công khai phần công việc hậu trường cần thiết để thúc AI tiến lên thành một repo riêng và cho mọi người tái tạo kết quả
Suy cho cùng, điều khách hàng muốn đạt được chẳng phải là 1 triệu dòng code có thể dùng được chỉ trong “7 ngày” sao
Mọi người sẽ thử tái tạo nó trong workflow của mình, và các chỉ số sử dụng Anthropic cũng sẽ tăng lên
Nếu đây thực sự là một kết quả ấn tượng, có lẽ họ đã đăng một bài blog kèm liên kết và hướng dẫn trước tiên
Dĩ nhiên cũng có thể ngay lúc này bài blog đó đang được viết và tôi sẽ bị chứng minh là sai
Đó có phải là cốt lõi của thuyết âm mưu không
bun_collectionscũng không có vẻ lâu đời hơn nhiều so với hướng dẫn port+1009257 -4024à, vậy là Bun giờ đã vượt 1 triệu dòng Rust codeNó đang tiến gần tới quy mô của chính trình biên dịch Rust
Tuy vậy, BunJS phần lớn gần như là một lớp bọc quanh JavaScript interpreter và phần tái triển khai thư viện NodeJS, tức gần giống lớp bọc quanh thư viện chuẩn Rust
BunJS có vẻ đang trở thành con chim hoàng yến cho việc quản lý độ phức tạp phần mềm trong thời đại LLM
mostly a JavaScript interpreter wrapperkhông chính xácBun là một bộ transpiler (parser) JavaScript và CSS đầy đủ pin đi kèm, một minifier, bundler, package manager kiểu npm, test runner kiểu Jest, và còn có các runtime API như client Postgres, MySQL, Redis tích hợp sẵn
Đương nhiên code sẽ phải rất nhiều
Bun dùng JavaScriptCore làm JS engine, nên bản thân Bun không thực hiện, hoặc ít nhất là không nên thực hiện, việc parse JavaScript, diễn giải hay JIT
Sửa: tôi đọc nhầm. Bạn nói “JavaScript interpreter wrapper”, vậy thì diễn đạt đó đúng
+ở đầu hay còn yếu tố nào khác, nhưng trên di động thì số dòng thay đổi bị gạch dưới và bấm vào có thể gọi điệnNếu là vì kích thước diff thì cũng khá buồn cười
Việc kết quả viết lại ra LOC tương tự không phải điều gì lạ
Kết quả của
$ rg 'unsafe [{]' src/ | wc -llà 10428, còn$ rg 'unsafe [{]' src/ -l | wc -llà 736Theo ngôn ngữ thì có Rust 1443 file 929213 dòng, Zig 1298 file 711112 dòng, TypeScript 2604 file 654684 dòng, JavaScript 4370 file 364928 dòng, C 111 file 305123 dòng, C++ 586 file 262475 dòng, và C Header 779 file 100979 dòng
Thế trong Zig thì tìm mã không an toàn bằng cách nào?
Hay là cứ phải mặc định nó ở khắp mọi nơi
unsafethì đây chẳng có vẻ là một bản viết lại tốtNếu gần một nửa code vẫn là unsafe thì việc viết lại sang Rust còn ý nghĩa gì nữa
Thứ có ở nhà tôi:
10428Chúng tôi vẫn đang viết bài blog nói về chuyện này và sẽ chia sẻ chi tiết hơn
Nếu bạn tò mò về bối cảnh, hãy xem danh sách sửa lỗi trong ghi chú phát hành của Bun v1.3.14 và các bản trước đó
Rust không tự động bắt hết mọi thứ này. Những rò rỉ do giữ tham chiếu quá lâu, hay mọi vấn đề tái nhập qua biên giới JS, vẫn là trách nhiệm của chúng tôi
Nhưng một phần đáng kể trong danh sách đó là use-after-free, double-free, và quên giải phóng trên đường xử lý lỗi, những thứ này sẽ trở thành lỗi biên dịch hoặc được thay bằng cơ chế dọn dẹp tự động
I work on Bun and this is my branchThis whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.Có lẽ đây không hẳn là phản ứng thái quá?
[0]: https://news.ycombinator.com/item?id=48019226
Tôi tò mò không biết họ có kế hoạch chạy song song bản Zig và bản Rust trên phạm vi rộng với các ứng dụng thực tế, hoặc nếu có thể thì shadow run trong production để lọc lỗi hay không
Có thể đưa ra một ước lượng đại khái không
Và cụ thể họ định phát hành bản này thế nào để không làm hỏng workflow của người dùng
Khoảng 9 ngày trước Jarred đã viết rằng hoàn toàn chưa chắc nó sẽ được merge và đây là phản ứng thái quá
Thật trớ trêu
Hãy tưởng tượng Linus nói sẽ không viết lại kernel Linux, rồi một ngày nào đó thức dậy và merge toàn bộ bản viết lại Rust có máy hỗ trợ, thì sẽ thành cảnh tượng thế nào
Rõ ràng là phải biện minh cho chi phí token đã bỏ ra
Wow, chuyện này sẽ rất đáng theo dõi về sau
Gần như chắc chắn là đoạn code này chưa hề được review, nhưng biết đâu giờ chúng ta đã bước vào thời kỳ hậu nhân loại nơi có thể tin mô hình vừa viết vừa review code
Đây giống Gastown nhưng lại xảy ra ở một dự án nổi tiếng hơn nhiều
Tôi thấy thú vị không biết dự án này rồi sẽ thêm tính năng mới như thế nào, hay liệu có thể thêm nổi không
Có ai biết chính xác Anthropic dùng Bun như thế nào không?
Nó là một phần của Claude Code à?
Tôi bắt đầu khá lo khi dùng Bun về sau, nhưng không rõ mức độ lo đó có áp dụng phần nào sang cả việc dùng Claude hay không
Nếu bạn không thể tin vào test suite để bắt lỗi dịch ngôn ngữ tự động, thì ngay từ đầu bạn cũng không nên tin test suite đó chút nào cả :)
Thật ra tôi khá háo hức với chuyện thử dịch tự động, nhưng lo rằng sẽ phát sinh rất nhiều vấn đề tương thích ngược
Tôi bắt đầu xem commit và về cơ bản họ đang giải quyết vấn đề “test không pass” bằng cách sửa chính test
Phần công việc thật sự để làm cho nó chạy đúng với các chương trình đã triển khai ngoài thực tế mới chỉ là bắt đầu thôi
Điểm may mắn là cộng đồng JS phía server dường như vì lý do nào đó đã quen với việc thường xuyên bị gãy rồi
Nhưng nếu chuyện này thực sự hoạt động mà không có vấn đề lớn thì cũng khá đáng kinh ngạc
GPT/Codex có vẻ trung thực hơn ở điểm này
Tôi hoài nghi toàn bộ màn viết lại này, và Jarred Sumner có quá nhiều người theo dõi trên mạng nên nghe cứ như quảng cáo
Tuyệt vời! Chỉ cần thêm ngẫu nhiên
sleep(1)vào test là xong. Đừng lo, mọi thứ sẽ ổn thôi!Một vài dự án ít ỏi của tôi đang dùng Bun sẽ được chuyển sang thứ khác
Tôi không tin vào kiểu quản trị cho phép những thay đổi liều lĩnh như thế này
Nó vốn được viết tốt ngay từ đầu nên cũng không cần viết lại
Mặt khác, theo dõi xem lễ rửa bằng lửa này diễn ra thế nào cũng khá thú vị, và về dài hạn thì có lẽ cuối cùng các vấn đề cũng sẽ được giải quyết
Có một thread đáng xem như bài học. Một tuần trước Jarred lại tiếp tục tránh né chuyện quyết định merge, còn cả một đám lính xung kích thì công kích những người dự đoán nó sắp được merge:
https://news.ycombinator.com/item?id=48073680
Giờ nhìn lại thì đúng là những lời đó không trụ được lâu nhỉ?
Nếu chuyện này sai dù chỉ một chút, những lời chế nhạo kiểu tay buôn ma túy phê hàng của chính mình sẽ kéo dài bất tận và rất u ám
Bạn đã đọc bài báo Mythos chưa? Mức độ nhân hóa thật sự rất nặng
Có thể chỉ là trò câu chú ý rẻ tiền, nhưng nếu họ thực sự tin LLM có ý thức thì… wow