Hành trình chuyển đổi Bun từ Zig sang Rust: Tại sao Jarred Sumner lại thay đổi?

Viết lại Bun bằng Rust (via) Jarred Sumner đã hứa hẹn về bài blog này (từ ngày 9 tháng 5) về việc ông viết lại Bun từ Zig sang Rust trong khoảng thời gian dài hơn nhiều so với thời gian ông thực sự hoàn thành việc viết lại đó.

Thành thật mà nói, sự chờ đợi này rất xứng đáng. Đây là mô tả chi tiết về một kỹ thuật tác nhân (agentic engineering) cực kỳ tinh vi, bao gồm các quy trình làm việc linh hoạt, các lần chạy thử nghiệm, đánh giá đối kháng và đủ loại thủ thuật thú vị khác.

Jarred dành nửa đầu bài viết để ca ngợi Zig vì đã giúp Bun tiến xa đến mức này. Sau đó, chúng ta đi đến một ý tưởng cốt lõi trong bài viết, phần nhấn mạnh là của tôi:

Danh sách sửa lỗi của chúng tôi trông rất tệ và tôi đã quá mệt mỏi khi phải đi ngủ với nỗi lo về các lỗi treo máy trong Bun. Tôi không đổ lỗi cho Zig về điều đó - những người dùng Zig khác không gặp phải các lỗi như chúng tôi, và việc kết hợp GC (thu gom rác) với bộ nhớ được quản lý thủ công là một điều hiếm gặp đến mức không ngôn ngữ nào thực sự được thiết kế cho nó. Chúng tôi sẽ không thể tiến xa đến thế nếu không có Zig, và tôi sẽ luôn biết ơn điều đó. Cho đến gần đây, việc chọn ngôn ngữ lập trình vẫn là một quyết định một chiều đối với một dự án như Bun.

Ai cũng biết rằng bạn không bao giờ nên dừng mọi thứ lại để viết lại một phần mềm lớn từ con số không. Joel Spolsky đã nhấn mạnh điều đó trong bài "Những điều bạn không bao giờ nên làm, Phần I" từ tháng 4 năm 2000!

Các tác nhân lập trình (coding agents) được vận hành bởi các mô hình tiên tiến ngày nay đã thay đổi phương trình đó.

Tại sao lại chọn Rust? Tất cả đều quy về những thách thức trong việc quản lý bộ nhớ:

Một tỷ lệ lớn các lỗi trong danh sách đó là use-after-free (sử dụng sau khi giải phóng), double-free (giải phóng hai lần) và "quên giải phóng" trong đường dẫn lỗi. Trong Rust an toàn, đây là các lỗi trình biên dịch và được xử lý bằng cơ chế dọn dẹp tự động kiểu RAII với Drop.

Một yếu tố then chốt cho phép thực hiện việc viết lại này là bộ kiểm thử (test suite) của Bun được viết bằng TypeScript, nghĩa là nó có thể đóng vai trò như một bộ kiểm chuẩn. Điều này cho phép một hệ thống tác nhân tự động hóa phần lớn quá trình chuyển đổi ban đầu từ Bun sang Rust, ban đầu như một thử nghiệm để dùng thử phiên bản sớm hơn của mô hình mà chúng ta hiện có quyền truy cập là Mythos/Fable.

Lúc đầu, tôi không mong đợi nó sẽ thành công. Sau vài ngày, một tỷ lệ lớn các bài kiểm thử bắt đầu vượt qua và tôi thấy mã nguồn Rust mới khớp với cơ sở mã Zig gốc như thế nào. Ý kiến của tôi đã chuyển từ "thử xem sao" sang "tôi sẽ hợp nhất nó". [...]

Trong hầu hết 11 ngày đó (và sau đó), tôi đã theo dõi các quy trình làm việc - đọc thủ công các kết quả đầu ra để kiểm tra các vấn đề và lỗi, đồng thời nhắc Claude chỉnh sửa vòng lặp để khắc phục mọi thứ.

Làm thế nào để bạn đánh giá một PR với hơn 1 triệu dòng mã được thêm vào? Làm thế nào để bạn bắt đầu xây dựng sự tự tin cần thiết để hợp nhất một cách có trách nhiệm một lượng lớn mã nguồn do LLM tạo ra?

Một bộ kiểm thử độc lập với ngôn ngữ với hàng triệu khẳng định, đánh giá mã đối kháng và khi có sự cố xảy ra, hãy sửa quy trình tạo ra mã đó thay vì sửa thủ công mã nguồn.

Bản triển khai mới của Bun đã hoạt động trong Claude Code được gần một tháng nay:

Claude Code v2.1.181 (phát hành ngày 17 tháng 6) trở về sau sử dụng bản chuyển đổi Bun sang Rust. Thời gian khởi động nhanh hơn 10% trên Linux nhưng ngoài ra, hầu như không ai nhận ra sự khác biệt. Nhàm chán cũng là một điều tốt.

Một đặc quyền khi làm việc tại Anthropic là bạn không phải trả tiền cho các token của mình - rất tiện lợi khi chi phí ước tính lên tới 165.000 đô la!

Trước khi hợp nhất, quá trình này tiêu tốn 5,9 tỷ token đầu vào không lưu vào bộ nhớ đệm, 690 triệu token đầu ra và 72 tỷ lượt đọc token đầu vào đã lưu vào bộ nhớ đệm — khoảng 165.000 đô la theo giá API.

Toàn bộ sự việc này là một nghiên cứu điển hình hấp dẫn về việc thực hiện các dự án đầy tham vọng với sự trợ giúp của các tác nhân song song phối hợp.