Bản viết lại thử nghiệm của Bun bằng Rust đạt 99,8% tương thích kiểm thử trên Linux x64 glibc

• Bản viết lại bằng Rust của Bun đã vượt qua 99,8% bộ kiểm thử hiện có trong môi trường Linux x64 glibc
• Codebase này “về cơ bản là cùng một codebase”, và việc chuyển sang Rust cho phép trình biên dịch ép buộc vòng đời kiểu dữ liệu và dùng destructor vào đúng thời điểm cần thiết
• Các phần không an toàn trở nên rõ ràng hơn với unsafe của Rust, qua đó tạo tác động thúc đẩy việc refactor
• Lý do viết lại là vì đã quá mệt mỏi khi phải dành nhiều thời gian lo lắng và sửa rò rỉ bộ nhớ, crash và các vấn đề ổn định, đồng thời muốn ngôn ngữ cung cấp công cụ mạnh hơn để ngăn chặn điều đó
• Quy mô tổng thể được mô tả là viết lại 960.000 LOC, hiện đã vượt qua bộ kiểm thử trên Linux và các nền tảng khác cũng sẽ sớm được nhắm tới

---

Trạng thái bản viết lại Rust

• Bản viết lại bằng Rust của Bun đã vượt qua 99,8% bộ kiểm thử hiện có trong môi trường Linux x64 glibc
• Codebase này “về cơ bản là cùng một codebase”, và khi chuyển sang Rust, trình biên dịch có thể ép buộc vòng đời của kiểu dữ liệu và dùng destructor vào đúng thời điểm cần thiết
• Các phần không an toàn trong Rust được bộc lộ rõ hơn qua unsafe, từ đó tạo tác động thúc đẩy refactor
• Đằng sau việc viết lại là sự mệt mỏi vì phải dành quá nhiều thời gian lo lắng và sửa rò rỉ bộ nhớ, crash và các vấn đề ổn định, cùng mong muốn ngôn ngữ cung cấp công cụ mạnh hơn để ngăn các vấn đề này
• Quy mô tổng thể được mô tả là viết lại 960.000 LOC, và mã hiện thực sự hoạt động, vượt qua bộ kiểm thử trên Linux, với các nền tảng khác cũng sẽ sớm được nhắm tới

Nội dung sẽ công bố tiếp theo và trả lời về build

• Ý nghĩa đối với Bun, benchmark, mức sử dụng bộ nhớ, khả năng bảo trì về sau và quá trình viết lại thực tế sẽ được đề cập trong một bài blog riêng
• Quá trình viết lại không đơn giản chỉ là nói “claude, rewrite bun in rust. make no mistakes”, và công việc để đạt tới trạng thái chạy được đến cùng mới bắt đầu từ 6 ngày trước
• Điều này được mô tả là sẽ là khối lượng công việc khổng lồ nếu làm hoàn toàn thủ công
• Thời gian biên dịch về cơ bản tương đương với phiên bản Zig hiện tại dùng trình biên dịch Zig nhanh hơn, và nếu dùng upstream Zig compiler thì bản port sang Rust thậm chí còn biên dịch nhanh hơn
• Hiệu năng sẽ được đề cập trong một bài blog riêng
• Về bước tiếp theo là thay thế chính libc bằng phiên bản Rust là frankenlibc, thì trước đó tác giả nói sẽ tự làm libc trực tiếp

[GN⁺]

Ý kiến trên Hacker News

• 4 ngày trước cũng đã có nội dung tương tự: https://news.ycombinator.com/item?id=48019226
  Một người làm ở Bun nói đó là nhánh riêng của họ, thread lúc đó là phản ứng thái quá với đoạn mã chưa chạy được, và họ chưa từng chốt sẽ tái viết, hơn nữa rất có thể toàn bộ đoạn mã sẽ bị bỏ đi
  Họ nói muốn xem phiên bản chạy được trông như thế nào, hiệu năng và khả năng bảo trì ra sao, và việc cho nó vượt qua bộ test của Bun khó đến mức nào, rồi so sánh bản Rust và bản Zig đặt cạnh nhau

  • Khi viết tin nhắn đó, cargo check báo hơn 16.000 lỗi trình biên dịch, và nó không thể in số phiên bản hay chạy JavaScript
    Không ngờ nó có thể hoạt động nhanh đến vậy, cũng không ngờ hiệu năng lại cạnh tranh đến thế; chi tiết sẽ có trong một bài blog sắp tới
  • Có vẻ họ đã kiểm tra khả năng bảo trì, hiệu năng và bộ test rồi mới đưa ra quyết định
  • Nếu vậy thì đến lúc này, đây có nghĩa là một thử nghiệm cực kỳ thành công
  • Vài ngày trước họ còn nói rằng “mã nguồn mở có lẽ sẽ đi theo hướng ngược lại. Cấm đóng góp của con người. Slop sẽ là di vật hoài niệm của 2025~2026”
    Đáng ra phải đoán được sau khi bị Anthropic mua lại, nhưng vẫn thấy thất vọng. Tôi không phản đối bản thân công nghệ mô hình ngôn ngữ lớn, nhưng cách các công ty “AI” này nuốt dần ngành phần mềm và xã hội nói chung để giành quyền lực thì thật kinh tởm, và đang tạo ra sự phụ thuộc rất không lành mạnh
    Cần nhìn trước vài nước và chuẩn bị stack phần mềm và cộng đồng không có slop. Trong đó có cả Zig và hệ sinh thái của nó. Dù chúng ta và các thế hệ sau có thể không hoàn toàn sống thiếu slop, việc bảo đảm một nền văn hóa điện toán bền vững với tự do đúng nghĩa vẫn quan trọng hơn bao giờ hết

• Làm nhanh đến vậy thật rất ấn tượng. Tương tự, tôi đã làm một dự án port TypeScript sang Rust được 5 tháng, nhưng không có Mythos hay quyền truy cập token không giới hạn
  Dù vậy, cũng đã gần đạt tỷ lệ pass 100%, và tại thời điểm viết là 99,6%: https://tsz.dev
  Rust rất hợp để viết code bằng mô hình ngôn ngữ lớn. Nhờ hệ thống kiểu nghiêm ngặt, nó giúp tránh bớt những lỗi ngớ ngẩn mà ở ngôn ngữ khác có thể vẫn lọt qua
  Tuy nhiên, việc viết code bằng mô hình ngôn ngữ lớn không làm biến mất nhu cầu về tầm nhìn thiết kế và khả năng cân nhắc trade-off khi xây dự án. Vì thế Jarred và đội ngũ là những người phù hợp để tận dụng lượng lớn code do mô hình ngôn ngữ lớn tạo ra

  • Việc Rust cưỡng chế bất biến ở thời điểm biên dịch giúp mô hình ngôn ngữ lớn nhận phản hồi nhanh rồi quay lại sửa, nên có ích cho việc tạo ra mã chạy được
    Ngược lại, Rust là một ngôn ngữ phức tạp nên thay đổi nhỏ rất dễ kéo theo cơn lở tuyết refactor, buộc phải sửa lại cả những đoạn mã ở rất xa. Nếu kiến trúc ban đầu tệ hoặc thiếu, thì khi mô hình ngôn ngữ lớn dần mở rộng codebase theo cách thường thấy, nguy cơ nó biến thành spaghetti là rất lớn
    Cuối cùng tôi lo rằng nó sẽ thành một chương trình biên dịch được, chạy được, nhưng con người không thể đọc hay bảo trì nổi
  • Tương tự, tôi cũng đang làm Postgres đa luồng. Trong 1 tháng đã vượt 96% pg regression test và đạt 823K LOC
    Không có Mythos, tất cả chỉ là 8 tài khoản Codex giá $200/tháng
    Tôi cũng thấy điểm mạnh của Rust ở đây, và dựa trên kinh nghiệm với Postgres, tôi tin có thể đưa ra nhiều quyết định thiết kế tốt cho những phần mà mọi người đã vật lộn với pg suốt thời gian dài. Điều đáng mong đợi là nhờ AI, việc cải thiện những phần mềm phức tạp mà trước đây không thực tế giờ sẽ khả thi hơn
    [0] https://github.com/malisper/pgrust
    [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • Khi Microsoft viết lại nó bằng Go, một trong các lead nói rằng họ chọn Go thay vì Rust vì sự tương đồng về mô hình lập trình. Những thứ như garbage collection khá giống nhau, còn Rust thì khó hơn và có lẽ sẽ cần nhiều đường vòng hơn; tôi tò mò không biết cảm nhận thực tế của người từng làm trực tiếp là thế nào
  • Rust rất tuyệt, nhưng khi cố xây phần mềm Rust quy mô lớn với mô hình ngôn ngữ lớn trong các dự án lớn, cách làm mình mong muốn sẽ sụp đổ
    Ngay cả việc giữ hoặc dựng ranh giới sạch sẽ cũng không còn là trạng thái tập trung mà thành những buổi review đau đớn, rồi cuối cùng lại rơi vào chế độ trì hoãn
  • Tôi đã rất vất vả để Opus đừng phớt lờ các thành ngữ Rust và viết ra thứ Rust kỳ quặc nhất có thể. Không biết có mẹo nào không

• Tôi không có bằng chứng mạnh, nhưng giờ không muốn dính đến Bun nữa. Gần như chỉ là trực giác, nhưng tôi không còn có thể tin tưởng hay ủng hộ nó
  Họ fork Zig để tận dụng việc tái viết bằng LLM, rồi tạo ra thứ như biên dịch không quyết định mà đội Zig rõ ràng không hề muốn
  Giờ lại như đang than vãn và dùng LLM để tái viết sang Rust. Có thể chính triết lý thiết kế của Zig — ép buộc những quyết định khó nhưng đúng — đã đưa họ đến vị trí hiện tại, và việc tái viết sang Rust thật sự có thể là khởi đầu của sự sa sút
  Đây là đánh giá mang tính chính trị hơn là kỹ thuật, nhưng Bun trông như đang hoàn toàn dựa vào Claude. Tôi sẽ không ngạc nhiên nếu câu khẩu hiệu marketing tiếp theo của Anthropic là “Claude Mythos tái viết JS runtime 950K LOC hàng đầu sang Rust”

  • Tôi không biết người viết code vào repo của mình là đứa trẻ hay rên rỉ, hay là người lên Hacker News phàn nàn về chuyện đó mới như vậy
  • Tôi không thấy Jarred than vãn gì cả; có vẻ cảm xúc đang bị đặt sai chỗ
    Thread Twitter được link vào có đưa ra cơ sở kỹ thuật rõ ràng
  • Cá nhân tôi không đầu tư cảm xúc đến vậy vào Bun, nhưng tôi không hiểu sao chuyện này lại quan trọng. Tôi cũng tò mò liệu họ có soi các dependency khác theo cách này không
    Làm việc trong hệ sinh thái JS/NPM vốn đã phụ thuộc rất nhiều vào niềm tin thuần túy với những dependency chưa được kiểm chứng, và trước hay sau tái viết bằng LLM thì cũng chẳng khác gì. Nếu nó vẫn đáp ứng mục tiêu ban đầu và hợp đồng API, thì có khác biệt gì không? Cũng nghi ngờ rằng liệu trước đây họ có đọc kỹ mã nguồn hiện có hay không
  • Đồng ý. Ngay từ đầu Bun đã có triết lý thiết kế rất rõ. Nó muốn làm tất cả: runtime, bundler, test suite, package manager, rồi phát hành các bản vá hỏng vặt mỗi tuần
    Lúc nào cũng theo kiểu sẽ đè bẹp các đối thủ hiện có theo hướng tốt hơn, nhanh hơn, mạnh hơn, nhưng chuyện Keep It Simple Stupid thì rõ ràng là không bao giờ
    Cũng quá rõ là trong tương lai gần, nơi duy nhất ta thấy nó trong môi trường production thực tế sẽ chỉ là các startup YC cháy lần lượt như bị tưới chất xúc tác. Giờ có vẻ đã qua điểm không thể quay đầu
  • Bun về cơ bản là đã chết
    Anthropic mua Bun như một nỗ lực hơi ngớ ngẩn để giải quyết vấn đề “hiệu năng” của chính họ. Có vẻ họ không nhận ra vấn đề ngay từ đầu là code quá tệ
    Dù vậy, họ cũng đã kéo được vài lập trình viên thực sự giỏi về, nên có thể vẫn giúp được phần nào
    Nhưng trong quá trình đó, Bun từ một dự án công khai đã trở nên gần với công cụ nội bộ của Anthropic hơn, và giờ đang được AI funding nuông chiều quá mức trong khi mất khá nhiều trọng tâm
    Tôi hy vọng khi bong bóng xì hơi thì ít nhất vẫn cứu vãn được một phần công sức đã đổ vào Bun. Có vẻ Anthropic sẽ không bảo trì nó lâu dài. Họ đâu phải công ty bán dịch vụ hỗ trợ runtime, cũng không có quy mô kiểu Google để tiện tay duy trì một runtime ở bên cạnh

• Nếu tạm bỏ qua yếu tố AI, tôi nghĩ đây là thay đổi tích cực
  Bun khi dùng Zig có crash và lỗi bộ nhớ cực nhiều, khác với Deno viết trên Rust
  Tất nhiên nếu bản Rust port của Bun có quá nhiều unsafe thì cũng không phải mọi thứ sẽ tự nhiên được giải quyết, nhưng dù sao vẫn sẽ tốt hơn

  • Tôi tò mò không biết có thống kê hay nguồn nào cho nhận định Bun có crash và lỗi bộ nhớ cực nhiều không. Không phải tôi nghĩ nó sai
    Việc các phần xấu xí hiện rõ hơn khi nằm trong unsafe, từ đó thúc đẩy refactor, có vẻ không chỉ là vấn đề của ngôn ngữ mà còn là thứ chính Bun phần nào tự gây ra
  • Ý ở đây là dùng Zig thì “crash và lỗi bộ nhớ tăng cực nhiều” sao?
    Nếu vậy chẳng phải điều đó có nghĩa là gần như không thể làm phần mềm chất lượng cao bằng công cụ như thế sao? C/C++ cũng có rất nhiều thứ chất lượng tốt mà, nên tôi tự hỏi Zig đang làm sai điều gì
  • Vì unsafe được đánh dấu rõ ràng nên dễ tìm hơn, và tự nhiên sẽ hình thành một danh sách các vấn đề cần giải quyết

• Việc này mất 6 ngày. Dù cuối cùng có không dẫn đến kết quả thực sự có ý nghĩa, nó vẫn cho thấy token và khối lượng công việc gắn với nhau như thế nào ở hiện tại và tương lai
  Sẽ ngày càng khó cạnh tranh với cá nhân hay công ty có nhiều tài nguyên tính toán hơn. Họ đơn giản sẽ làm được những thứ mà tôi không làm được

  • Dịch một dự án từ ngôn ngữ này sang ngôn ngữ khác khi đã có bộ test tốt được biết đến là một trong những trường hợp điển hình mà mô hình ngôn ngữ lớn làm rất tốt
    Nếu có một codebase hoàn chỉnh làm ví dụ và có thể dùng bộ test để kiểm chứng, thì việc lặp để tiến gần mục tiêu mong muốn dễ hơn rất nhiều. Mô hình đã thấy mục tiêu là gì và một cách triển khai của nó trông ra sao, nên đây là bài toán dễ hơn nhiều so với bắt đầu từ đặc tả
  • Người ta cũng có thể nói điều tương tự về động cơ hơi nước hay điện. Đây không chỉ là một phép ví von hời hợt. Điều kỳ diệu của những thứ này nằm ở chỗ chúng là động cơ thông tin đa dụng
    Bạn bỏ vốn vào, tạo ra bằng kỹ thuật mở rộng đã được hiểu khá rõ, cắm điện vào là có giá trị
    Ý ở đây là, trong thế giới hiện đại, khả năng xuất hiện tầng lớp “người có và người không có” có lẽ sẽ không xảy ra, cũng như điện đã không diễn ra như vậy
  • Chưa chắc. Những sản phẩm thực sự tốt phần lớn xuất phát từ việc làm một hai thứ thật giỏi, chứ không phải làm thật nhiều thứ
    Điều tôi thấy đến nay là kiểu “wow, giờ tôi là kỹ sư gấp 10 lần!” rồi đẩy ra nhiều code hơn nhưng không có định hướng và gu rõ ràng. Phần lớn công việc dựa trên mô hình ngôn ngữ lớn hiện tại trông chỉ như nhiễu
  • Không hẳn. Những agent như thế này ngày càng dễ chạy ở máy local
    Không biết bạn đã thử Qwen 3.6 27b chưa, nhưng những gì nó làm được so với kích thước thì thật điên rồ. Nếu quản lý ngữ cảnh tốt, các dự án nhỏ thậm chí có thể 100% vibe coding
    Những mô hình kiểu này rồi cũng sẽ đi xuống theo cạnh tranh giá như điện toán thôi
  • Tôi tò mò nếu tính theo mức giá chuẩn của Anthropic thì việc này sẽ tốn khoảng bao nhiêu USD. Có ai ước lượng được sơ bộ không?

• Nhiều người đang tiếp nhận chuyện này theo đúng bề nổi, nhưng phần lớn điều đó khả thi là nhờ một bộ test rộng và toàn diện vượt chuẩn đã được xây dựng từ trước

  • Dù vậy, đây vẫn là kết quả ấn tượng mà ngay cả kỹ sư giỏi nhất cũng sẽ mất lâu hơn nhiều để đạt được
    Sau này khi marketing, sẽ tốt nếu họ cũng ghi kèm đã có bao nhiêu công sức của con người được đổ vào việc thiết kế và tuyển chọn bộ test giúp tạo ra tốc độ này
    Bộ test gần như hoạt động như môi trường lý tưởng cho thế hệ mô hình ngôn ngữ lớn hiện tại. Một bộ test đủ toàn diện trở thành đặc tả mà agent có thể triển khai theo cách mong muốn, và ở đây đích đến là Rust
    Với những bài test được xây dựng tốt như ở dự án Bun, trong vài trường hợp có cảm giác rằng thậm chí nếu bỏ toàn bộ source code và chỉ cho truy cập test, người ta vẫn có thể hiện thực lại toàn bộ từ đầu
  • Nếu đây là kiểu bộ test “vượt chuẩn” đến mức gần như là yếu tố duy nhất khiến công việc này khả thi mà dự án khác không làm được, thì tôi không rõ điều đó hòa hợp thế nào với lập luận rằng Bun phải tái viết vì nó bất ổn hơn hẳn các chương trình Zig khác
    Nếu trách nhiệm cũng nằm một phần ở bộ test, thì tôi cũng tò mò điều đó có ý nghĩa gì đối với bản port Rust
  • Bảo rằng chỉ cần nhìn vào chuyện làm được thế này trong 6 ngày thôi
    Còn hàng trăm nghìn giờ đổ vào kiến trúc gốc và bộ test khiến điều đó khả thi thì cứ bỏ qua sao

• Có thể xem đây như một ví dụ cảnh báo về việc port sang Rust bằng AI
  https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

  • Việc pass test không đồng nghĩa là nó thực sự hoạt động
    Trình biên dịch C do Claude code tạo ra đã pass 100% test của gcc nhưng thậm chí không chạy nổi cả hello world
  • Bài học rút ra từ các trường hợp đó hơi khác. Mô hình ngôn ngữ lớn làm theo vòng phản hồi mà bạn cung cấp
    Nếu chỉ đưa test logic thì nó sẽ không hề quan tâm đến tốc độ. Nếu bạn đưa cả test đo tốc độ và yêu cầu đạt hiệu năng, nó cũng sẽ làm theo hướng đó
    Đây cũng cùng loại lỗi như nhiều lỗi khác của mô hình ngôn ngữ lớn: nó không có ngữ cảnh thường thức về những gì con người xem là quan trọng. Nếu bạn không ép ranh giới thì nó sẽ bỏ qua
  • Nếu quan tâm thì chuyện này đã được thảo luận ở đây: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - tháng 3 năm 2026, 422 bình luận

• Thật là một thời đại điên rồ để được sống
  Các động lực nền tảng của ngành và nghề đã thay đổi trong thời gian quá ngắn, gần như chỉ sau một đêm
  Có ngày tôi thấy phấn khích vì giờ mình có thể làm được quá nhiều thứ. Gần như muốn gì cũng có thể tạo ra gần như ngay lập tức, và 100% những gì từng mơ về phần mềm có thể thành hiện thực
  Có ngày tôi lại sợ điều gì sẽ xảy ra với thị trường việc làm
  Đột nhiên ta có thể nhận được rất nhiều chỉ với rất ít, trong khi lượng phần mềm thế giới cần là hữu hạn
  Liệu mọi công ty lấy việc bán phần mềm làm mô hình kinh doanh cốt lõi có phá sản không?
  Nếu chỉ một số công ty hoặc chính phủ được tiếp cận những mô hình tốt nhất thì sao?

  • Hãy nghĩ đến một doanh nghiệp phần mềm như hệ thống bán vé
    Liệu 100 công ty có 1 tỷ token mỗi công ty có thể làm ra sản phẩm tốt hơn một nhà cung cấp chuyên biệt sở hữu 100 tỷ token không?
    Những vendor phần mềm và SaaS kiểu “trình tạo logo” thì đúng là đã chết rồi, nhưng trừ khi thế hệ mô hình ngôn ngữ lớn tiếp theo tích hợp sẵn cả hệ thống bán vé, các vendor hệ thống bán vé có lẽ vẫn ổn. Có thể cần ít nhân sự hơn, nhưng chưa chắc chắn
  • Gần thời điểm bong bóng dot-com vỡ, trong ngành phần mềm cũng từng có khá nhiều lời nói với sinh viên và người tìm việc rằng lĩnh vực này “đã quá bão hòa”, đừng dấn thân vào nữa
    Đại loại là số người đổ vào quá đông so với lượng việc có thể chia nhau, và cú sụp đổ càng củng cố câu chuyện đó
    Nhưng ngay cả khi còn là sinh viên lúc ấy, vẫn có thể thấy phạm vi của phần mềm gần như là vô hạn. Gần như mọi công việc nhận thức mà ta làm thủ công đều có thể làm bằng phần mềm. Tôi từng thử liệt kê những thứ như vậy, rồi nhanh chóng nhận ra còn quá nhiều việc phải làm
    Hơn nữa, tôi cũng hiểu rằng càng làm việc theo cách mới, càng có nhiều việc chưa từng tưởng tượng nổi lại xuất hiện thêm. Khả năng là không thể đếm xuể, và câu chuyện “bão hòa” rõ ràng xuất phát từ sự thiếu trí tưởng tượng và thiếu hiểu biết về phần mềm thực sự là gì
    Vì vậy tôi biết lĩnh vực này sẽ không bao giờ bão hòa. Không thể nào cạn thứ để xây bằng phần mềm được
    Nhưng dạo này thì khác. Sau này ta vẫn sẽ luôn tạo ra phần mềm mới, nhưng giờ tôi bắt đầu tự hỏi liệu tốc độ chúng ta viết phần mềm có thể nhanh hơn tốc độ chúng ta tưởng tượng ra việc mới để làm hay không
  • Các công ty và chính phủ sẽ được tiếp cận các mô hình tốt hơn công chúng. Trên thực tế, Mythos đã là một ví dụ như vậy
    Dù vậy công chúng vẫn có thể tự giúp mình bằng các mô hình chậm chân hơn tuyến đầu

• Ít nhất thì việc theo dõi một nỗ lực như thế này cũng thú vị
  Điều đầu tiên tôi muốn biết là ngay từ đầu độ bao quát và chất lượng của bộ test đến đâu. Không phải để bắt bẻ, nhưng tôi tò mò không biết kể cả khi đạt 100% trên mọi nền tảng thì đội Bun sẽ tự tin đến mức nào để thực hiện migration

• Chuyện Ubuntu coreutils tuần trước đã khiến tôi có ấn tượng cực xấu với kiểu tái viết sang Rust đạt 99,8% tương thích test
  Bấm vào tweet được link ở đây xong tôi thấy rùng mình, và giờ mỗi lần thấy kiểu này thì cảm xúc lại hoàn toàn ngược lại. Gần như khiến tôi muốn tìm đường thoát ra