Bun (runtime JS) đang được port thử nghiệm từ Zig sang Rust

 (github.com/oven-sh)
3 điểm bởi GN⁺ 2 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Nhà sáng lập Bun, Jarred Sumner, đã commit hướng dẫn port Zig → Rust (PORTING.md) lên nhánh claude/phase-a-port, qua đó công khai một thử nghiệm chuyển đổi ngôn ngữ quy mô lớn với sự hỗ trợ của tác nhân AI
  • Việc port được chia thành Phase A (dịch thô logic theo từng file, không cần biên dịch) và Phase B (biên dịch thành công theo từng crate), với cách làm là cung cấp cho LLM khoảng 300 quy tắc ánh xạ kiểu và thành ngữ
  • Chính Sumner đã nói trên Hacker News rằng "chưa hề quyết định rewrite, và rất có thể toàn bộ phần code này sẽ bị bỏ đi", nên ở thời điểm hiện tại đây vẫn là giai đoạn thăm dò mang tính thử nghiệm
  • Trong cộng đồng, các yếu tố được nhắc đến gồm xung đột với chính sách cấm đóng góp bằng AI của Zig sau thương vụ Anthropic, việc Bun đã vận hành trên một bản fork của Zig, cùng các lợi thế an toàn của hệ sinh thái Rust
  • Phần lớn PR được @robobun (bot AI) tự động tạo ra, sau đó CodeRabbitAI và Claude review, cho thấy một ví dụ về tính khả thi thực tế lẫn giới hạn của các đợt migration code quy mô lớn do AI dẫn dắt

Cấu trúc chính của hướng dẫn port (PORTING.md)

  • Mục tiêu port là chuyển từng file Zig thành file .rs trong cùng thư mục; ở Phase A, mục tiêu là tái hiện trung thực logic, còn việc có biên dịch được hay không thì không quan trọng
  • Cấm dùng các crate async/I/O bên ngoài như tokio, rayon, hyper, async-trait, std::fs, std::net — vì Bun tự sở hữu event loop và syscall riêng
  • Cấm async fn, mọi xử lý bất đồng bộ đều giữ nguyên mô hình callback + state machine như trong Zig
  • Những phần chưa chắc chắn được đánh dấu bằng // TODO(port):, còn các thành ngữ Zig liên quan hiệu năng được đánh dấu // PERF(port): để xử lý ở Phase B

Quy tắc ánh xạ kiểu và thành ngữ

  • Cung cấp bảng ánh xạ hơn 50 kiểu dữ liệu như []const u8 → &[u8] (tuyệt đối không dùng &str), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error>
  • defer x.deinit() → xóa rồi thay bằng impl Drop, errdefer → dùng scopeguard, comptime → chuyển thành const generic, const fn, macro_rules!
  • Chuỗi được xử lý theo nguyên tắc dựa trên byte: cấm dùng std::string::String hoặc &str, thay vào đó dùng &[u8]/Vec<u8> — vì Bun xử lý WTF-8 và byte tùy ý
  • @intCast → T::try_from(x).unwrap() (luôn kiểm tra), @truncate → x as T (wrapping có chủ ý), @bitCast → transmute; tài liệu cũng tổng hợp đối ứng Rust cho từng hàm dựng sẵn của Zig

Bản đồ crate và mô hình ownership

  • Các namespace Zig như @import("bun").X được ánh xạ 1:1 sang khoảng 30 crate Rust như bun_str, bun_sys, bun_jsc, bun_alloc
  • Các crate AST/parser giữ nguyên arena bumpalo::Bump, còn các crate khác dùng allocator mimalloc toàn cục, từ đó loại bỏ tham số allocator
  • Ánh xạ ownership con trỏ gồm bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T>

Phản ứng cộng đồng (Lobsters·HN)

  • Có nhiều ý kiến đặt câu hỏi "liệu họ có thật sự muốn chuyển sang Rust, hay đây là màn showcase cho LLM của Anthropic"
  • Có suy đoán rằng xung đột giữa chính sách cấm đóng góp bằng AI của Zig và workflow phát triển lấy AI làm trung tâm của Anthropic có thể là bối cảnh phía sau, dù cũng có người tự nhận đây gần như chỉ là thuyết âm mưu
  • Có cái nhìn hoài nghi về việc LLM có thể tuân thủ trung thành khoảng 300 quy tắc hay không — nhưng cũng có đánh giá tích cực rằng "~16k token thì khá vừa cho các sub-agent"
  • Có nhận xét thú vị rằng cách làm tạo ra code chưa biên dịch được trước ở Phase A là hoàn toàn ngược với cách dùng coding agent thông thường
  • Gánh nặng duy trì bản fork Zig của Bun, các thay đổi breaking diễn ra thường xuyên trong Zig, cùng rủi ro khi phụ thuộc sản phẩm cốt lõi vào một ngôn ngữ vẫn còn ở giai đoạn beta cũng được nhắc đến như động lực chuyển đổi

Bài viết liên quan

2 bình luận

 
GN⁺ 1 giờ trước
Ý kiến trên Hacker News

  • Tôi làm ở Bun, và đây là nhánh của tôi
    Nhìn chung, chủ đề này là một sự phản ứng thái quá. Có tới 302 bình luận về đoạn mã còn chưa chạy được, nhưng vẫn chưa có gì được xác nhận là sẽ viết lại, và cũng rất có thể toàn bộ đoạn mã này sẽ bị bỏ đi
    Tôi muốn xem phiên bản chạy được sẽ trông như thế nào, cảm giác ra sao, hiệu năng thế nào, và việc làm cho nó vượt qua bộ test của Bun cũng như trở nên dễ bảo trì sẽ khó đến mức nào. Tôi muốn so sánh song song một phiên bản Rust và phiên bản Zig khả thi

    • Thật đáng tiếc khi chỉ vì có một commit thử nghiệm trên nhánh thử nghiệm mà một số người lại phản ứng quá khích như vậy. Nếu tạm gác cảm xúc sang một bên và nhìn theo tiêu chí ưu điểm, có lẽ cũng sẽ có nhiều người đồng ý với động lực muốn nghiên cứu cách tiếp cận này
      Phần “khó đến mức nào để vượt qua bộ test của Bun và có thể bảo trì được” khá thú vị, vì đây là thời kỳ mà mỗi tháng lại xuất hiện thêm cơ hội để trừu tượng hóa hoàn toàn quá trình chuyển mã bằng agent, và tất cả đều dựa trên ngôn ngữ học
      Nếu muốn tìm một ví dụ tương tự vừa thú vị vừa có phần giống thế, có thể xem vinext mà Cloudflare đã port từ Next.js vài tháng trước. Ban đầu có vấn đề thích nghi, nhưng giờ đã được dùng trong một số dự án production mà không gặp vấn đề lớn
      [0] - https://github.com/cloudflare/vinext
    • Tôi thích công việc của Bun, nhưng cũng tò mò mọi người nhìn nhận thế nào về việc gần đây liên tục xuất hiện lo ngại về chất lượng dự án. Một phần có thể chỉ là kiểu ghét bỏ thường thấy trên Twitter, nhưng cũng có vấn đề thực tế
      Việc mọi người hỏi tại sao lại thêm xử lý ảnh hay webview vào JavaScript runtime trong khi vẫn còn các lỗi ảnh hưởng production bị bỏ mặc nghe có vẻ hoàn toàn hợp lý. Ví dụ, một trong những yếu tố chặn lớn nhất với chúng tôi là https://github.com/oven-sh/bun/issues/6608, được báo cáo từ năm 2023 nhưng đến 3 năm sau vẫn còn ảnh hưởng
    • Tôi tò mò đâu là động lực chính để xem xét Rust
      Tham khảo thêm, lần gần nhất tôi dùng Bun thì tôi đã gặp vài lỗi ở những chỗ như Bun.write, kiểu lỗi mà Rust có lẽ đã giúp ích được
      [0]: https://mastrojs.github.io/blog/2025-10-29-what-struggled-wi...)
    • Thật đáng tiếc khi một nghiên cứu hoàn toàn chính đáng lại vấp phải phản ứng dữ dội đến vậy. Với một số người, Bun được xem như dự án tiêu biểu của Zig, đặc biệt là trong nhóm không thích Rust và vì lý do nào đó mong Zig “đánh bại Rust”
      Cuối cùng thì bất kể là ngôn ngữ hay công cụ nào, cứ chọn thứ phù hợp nhất với dự án và hoàn cảnh. Cá nhân tôi thấy thử nghiệm này rất thú vị và tò mò nó sẽ diễn tiến ra sao. Để viết Rust đúng phong cách thì cần thay đổi cách suy nghĩ, nên cũng đáng xem LLM sẽ thích nghi tốt đến mức nào theo thời gian
    • Tôi đơn giản là tò mò muốn biết kết quả
      Hy vọng mã sẽ thanh lịch, không chỉ dễ bảo trì mà còn hướng tới tương lai và có hiệu năng tốt

  • Trong bối cảnh bài đang đứng top trên HN hiện tại là chuyện lo lắng cho Bun vì Anthropic mua lại Bun, thấy cái này khá thú vị. Bình luận top bên đó có không khí kiểu “Anthropic sẽ thử nghiệm trên codebase của họ chứ đội Bun sẽ không làm mấy thử nghiệm vibe coding như vậy đâu”
    Thế nhưng những gì đang thấy lúc này lại giống như một công việc quy mô lớn được làm bằng vibe coding
    Kết quả rồi thời gian sẽ trả lời, nhưng sẽ rất tốt nếu các maintainer của Bun giải thích họ đang làm gì ở đây và tại sao làm vậy

    • Gần đây có người định upstream một cải tiến cho Zig, nhưng bị chặn vì Zig có quy định nghiêm ngặt cấm mã do AI tạo. Việc phản ứng này có phải để gây áp lực lên Zig hay chỉ là chuyển sang vì lý do thực dụng thì tùy mỗi người tự đánh giá
      Có lẽ là cả hai một chút
    • Có thể đây không phải công việc lớn như vẻ ngoài. Trong vài tuần qua tôi đã thử nghiệm dùng AI để viết lại Postgres sang Rust, và AI tỏ ra khá giỏi trong các công việc viết lại kiểu này
      Nếu đã có codebase sẵn để tham chiếu thì rất nhiều vấn đề của vibe coding sẽ giảm đi. Có sẵn một kiến trúc đang chạy tốt, và cũng có bộ test để đối chiếu
      Trong một tháng, tôi đã đi từ con số 0 đến mức vượt qua hơn 95% bộ test của Postgres. Nếu Jarred là người đã tạo ra Bun thì có lẽ tiến độ còn nhanh hơn nhiều
      [0] https://github.com/malisper/pgrust
    • Tôi không biết có người nào trùng giữa các đội này không, nhưng bản thân Anthropic có vẻ cũng đang đầu tư khá nhiều vào hệ sinh thái Rust
      Gần đây họ đề xuất một số công cụ nội bộ làm phần triển khai Rust chính thức cho Connect RPC. Đây là một bộ thư viện dựa trên Protobuf, nên cũng bao gồm Buffa, trình biên dịch Protobuf nền Rust mới
      [0]: https://github.com/orgs/connectrpc/discussions/7#discussionc...
      [1]: https://connectrpc.com/
      [2]: https://github.com/anthropics/buffa
    • Claude có vẻ sẽ xử lý Rust tốt hơn Zig
    • Tôi không hiểu tại sao nhất thiết phải giải thích. Việc này chỉ giống như bước nền cho refactor ban đầu và chuyển ngôn ngữ, chứ vẫn chưa có gì được xác nhận là thực sự đổi từ Zig sang Rust
      Nếu bạn là nhà đầu tư và muốn xem họ có dùng thời gian hiệu quả không thì tôi hiểu, còn ngoài ra thì tôi không rõ vì sao điều đó lại quan trọng với người khác

  • Thật thú vị khi thời thế đã thay đổi. Năm 2015, toàn bộ runtime Go, khi đó đã là một codebase khá trưởng thành, đã được bán tự động viết lại từ C sang Go. Một trong các maintainer đã tạo công cụ chuyển C sang Go nhắm vào tập con của C mà họ sử dụng, để mã tạo ra có thể biên dịch và cho cùng đầu ra, sau đó con người chỉnh sửa lại mã kết quả để nó Go hơn và tối ưu hơn
    Giờ thì chỉ cần yêu cầu mô hình ngôn ngữ làm việc đó
    Slide:
    https://go.dev/talks/2015/gogo.slide#3
    Cũng có một điểm tương đồng thú vị

    We had our own C compiler just to compile the runtime.
    Đội Bun cũng đang duy trì một bản fork Zig riêng

    • Khác biệt lớn ở đây là công cụ C-to-Go có lẽ mang tính quyết định. Chạy đi chạy lại nhiều lần hẳn sẽ cho ra đúng cùng một kết quả
      Vì con người viết công cụ chuyển đổi, hiểu nó, kiểm thử nó và sửa lỗi cho nó, nên có thể tin cậy kết quả đó
      Còn LLM thì không tất định. Nếu để nó chuyển độc lập 10 lần thì sẽ ra 10 kết quả khác nhau, và một số có thể khác rất nhiều. Không có cách nào để xác minh trừ khi mỗi lần đều rà soát lại toàn bộ
      Điều đó không có nghĩa công cụ chuyển đổi tất định do con người làm là hoàn hảo hay không lỗi, nhưng rõ ràng có thể xây dựng được mức độ tin cậy cao hơn nhiều so với LLM

  • Commit được liên kết có vẻ không đủ thuyết phục để chống đỡ cho cái tiêu đề này. Có một nhánh nơi Claude đang đại tu mã Zig sang Rust trên diện rộng, và hiện tại là thêm 773.950 dòng và xóa 151 dòng
    [0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port

    • Quá sốc. Hồi Jarred rời Stripe lần đầu, anh ấy cũng từng để lại vài PR hơn 10 nghìn dòng để viết lại mã dashboard, và phải mất hàng tháng mới xử lý xong. Chênh lệch 750 nghìn dòng thì về cơ bản là không thể review

    • Vì tò mò về quy mô công việc, tôi đã lấy top 5 theo cloc

      Language files blank comment code

      Zig 1298 79693 60320 571814
      TypeScript 2600 67434 115281 471122
      JavaScript 4344 36947 37653 290873
      C++ 583 27129 19117 215531
      C 111 21577 83914 199576

  • Có thể thành công nhưng theo cách chậm hơn: đi theo lịch sử commit git như một chuỗi checkpoint, áp dụng ý đồ vận hành của từng commit
    Nếu làm vậy, tôi cũng muốn biết liệu có thể bỏ qua một số commit sửa lỗi cụ thể hay không, nhờ bản triển khai Rust tự nhiên tránh được vấn đề ngay từ đầu

    • Ý tưởng hay đấy, và có thể thử trên một dự án nhỏ hơn. Bun có hơn 15.000 commit, nên nếu muốn làm xong mà không cần hàng chục nghìn lần gọi API thì sẽ phải tìm cách xử lý từng cụm commit trong một prompt
    • Trong issue tracker của Bun có rất nhiều lỗi segmentation fault. Chuyển sang Rust có lẽ sẽ tránh được khá nhiều trong số đó

  • Xét việc gần đây Bun/Anthropic từng phàn nàn về thời gian biên dịch của Zig — tức là PR tăng tốc biên dịch gấp 4 lần làm bằng vibe coding đã không được chấp nhận — thì việc định chuyển sang một ngôn ngữ có lẽ còn cho thời gian biên dịch dài hơn Zig gốc tới 4 lần trông như một bước đi khá “thú vị”

    • Tôi thực sự rất hoài nghi chuyện Zig biên dịch nhanh hơn Rust
      Tôi đã viết mã tương tự bằng Zig và C++, và biên dịch nguội thì C++ nhanh hơn nhiều lần, còn biên dịch tăng dần ở C++ thì gần như xong ngay
      Theo tôi, lý do chính khiến dự án Rust biên dịch chậm là do lạm dụng dependency và lạm dụng metaprogramming trong mã
      Zig không có nhiều đơn vị biên dịch riêng nên không thể song song hóa việc biên dịch

  • Tôi rất tò mò việc port bằng AI này sẽ kết thúc ra sao. Tôi đang tham gia vào nhiều dự án đang hoạt động, nơi ngôn ngữ hay framework đang cản trở dự án nhưng lại quá lớn để viết lại hoàn toàn chỉ bằng sức người
    Với vibe coding bằng Rust, tôi thành công hơn so với ngôn ngữ động. Có cảm giác sự nghiêm ngặt của trình biên dịch Rust buộc agent AI tạo ra mã tốt hơn. Tôi cũng không chắc, có thể chỉ là vì tôi ít quen với Rust hơn nên thấy nó làm tốt hơn

    • Rust là lựa chọn tốt để thả LLM chạy với ít giám sát hơn. Theo kinh nghiệm của tôi, vẫn phải giám sát tiến độ chặt chẽ, và con người phải giữ quyền sở hữu thiết kế của thứ đang được tạo ra hay port sang
      Test harness là bắt buộc. Phải chạy test ở mỗi vòng lặp để chắc rằng không làm hỏng phần khác
      Hiện tôi đang port TypeScript sang Rust và đã học được rất nhiều trong quá trình đó. Có thể xem công việc đang làm ở đây https://github.com/mohsen1/tsz/
      Tôi có thể chia sẻ những điều đã học được
    • Với vài công việc, tôi nhắm đến Go thay vì Rust. Nhưng tương tự, dù tôi không phải lập trình viên Go, có vẻ nó vẫn hoạt động khá ổn. Dù vậy tôi cũng không tiếp cận hoàn toàn ngây thơ, vì đã làm với nhiều codebase khác nhau suốt hàng chục năm
      Cách tôi bù cho hạn chế không thể review chi tiết mã là bảo đảm test, integration test và end-to-end test bao phủ mọi thứ tôi quan tâm. Nếu không có vậy thì tôi không thể chắc rằng nó không bỏ sót chi tiết công việc
      Tôi cũng cho nó chạy benchmark và stress test, rồi phân tích codebase để tìm các nút thắt tiềm ẩn. Sau khi phát hiện và sửa vài vấn đề thì mọi thứ tốt hơn hẳn. Cuối cùng, nếu bảo nó làm review phê phán, tìm cơ hội refactor, v.v. thì nó khá giỏi trong việc tạo danh sách những thứ cần sửa tiếp theo
      Bảo nó chạy memory leak checker và công cụ phân tích tĩnh cũng là chiến lược tốt. Nếu số vấn đề tìm được theo các cách đó giảm xuống thì có lẽ mã cũng không quá tệ. Ít nhất là đã đạt tới một cực tiểu cục bộ nào đó
      Việc không có review mã nghe khá kinh khủng, nhưng trong lập trình có AI hỗ trợ thì nó nhanh chóng trở thành nút thắt lớn nhất. Loại bỏ nút thắt đó đáng sợ thật, nhưng cũng nâng lượng mã có thể xử lý lên vài bậc. Trình biên dịch nghiêm ngặt và quản lý bộ nhớ nghiêm ngặt giúp loại bỏ một số loại lỗi nhất định
      Trước đây tôi làm việc này với các ngôn ngữ mà tôi hiểu rõ. Nhưng khi bắt đầu xử lý các commit lớn hơn như chuyện thường ngày thì review trở thành vấn đề
      Tôi nghĩ kiểu công việc trên codebase lớn như thế này sẽ còn ngày càng dễ hơn và tốt hơn theo thời gian. Vấn đề khó chịu chính trong loại kỹ thuật này là mô hình có xu hướng cố tình đi đường tắt, chỉ test đường đi hạnh phúc, và trì hoãn phần việc cốt lõi sang sau
      Có vẻ nhiều mô hình bị thiên lệch để tiết kiệm token. Khá bực, nhưng cũng dễ khắc phục bằng prompt tiếp theo và test; và nếu mô hình được tinh chỉnh để hành xử tốt hơn ngay cả khi không có prompt bổ sung thì chuyện này sẽ bớt thành vấn đề hơn
    • Đó là hiệu ứng Dunning-Kruger. Dù sao thì bạn cũng đã tự thừa nhận rồi
    • Đúng vậy, nó tạo ra mã Rust tệ hại
      Câu “có thể chỉ là vì tôi ít quen với Rust hơn nên thấy nó làm tốt hơn” thì đúng là cũng có thể thật

  • Tôi hy vọng Zig thành công, nhưng vì vẫn chưa lên 1.x nên các codebase lớn như Bun có lẽ sẽ gặp khó trong việc xử lý các thay đổi phá vỡ tương thích lớn
    Ngoài ra Bun còn dùng một bản fork Zig https://x.com/bunjavascript/status/2048427636414923250?s=20

  • Tôi không hiểu sao họ không viết lại claude-code bằng Rust
    Có vẻ Anthropic đã mua đội Bun vì claude-code dùng Bun, và có lẽ giờ muốn port Bun từ Zig sang Rust vì Rust “tốt hơn”. Nói cách khác, họ hẳn muốn làm claude-code “tốt hơn”, vậy mà lại đi đường vòng phức tạp như thế thì tôi không hiểu
    Với năng lực LLM họ đang có, họ hẳn có thể viết thẳng claude-code bằng Rust để đạt trạng thái tốt nhất

    • Họ chắc cũng không tự mắc lừa chiến dịch marketing “grassroots” quá lộ liễu của chính mình, và như bất kỳ kỹ sư giỏi nào cũng biết, LLM không phải công cụ phù hợp cho việc này
      Bun cũng rất dễ bị xem là một màn biểu diễn phục vụ marketing
    • Theo tôi biết thì claude code là React render thành giao diện terminal. Có vẻ họ thật sự rất muốn dùng React. Không biết có phải dùng AI quá nhiều thì não sẽ như thế không

  • Cho đến nay, phần lớn sự ấn tượng của claude/codex vẫn gắn với các ứng dụng được tạo ra bên trong ranh giới điều kiện của những thư viện sẵn có. Mô hình trực tiếp tận dụng những thành quả tuyệt vời mà con người đã xây dựng như Python, requests, ffmpeg
    Nhưng tôi đang chờ đến giai đoạn con quái vật này vươn ra ngoài các ràng buộc đó — tức là tự viết lại, vá, đổi tên và dựng lại thư viện, DLL, binary. Khi điều đó xảy ra, thư viện sẽ tan chảy mất, còn ứng dụng sẽ nổi trên bãi cát rung lắc của một stack công nghệ hiệu quả hơn, an toàn hơn, tích hợp hơn nhưng hoàn toàn phi nhân tính
    Xét về khả năng diễn giải hay bảo mật thì rõ ràng đây là ý tưởng đáng sợ, nhưng cũng khó mà quả quyết là nó không thể hoạt động, đặc biệt nếu có một nỗ lực tập trung và chuyên trách. Cũng chưa rõ việc slop hóa toàn diện khi máy móc viết lại hoàn toàn hàng chục năm phát triển nền tảng và gia tăng dần dần có nhất thiết loại trừ lẫn nhau với khả năng diễn giải hay không
 
GN⁺ 2 giờ trước
Ý kiến trên Lobste.rs

  • Tham khảo thêm, Jarred Sumner đã nói trên HN về việc này như sau: anh ấy làm ở Bun, đây là branch của riêng anh ấy, và theo anh ấy thì thread này đang phản ứng thái quá với một đoạn mã không chạy được
    Vẫn chưa chốt là sẽ viết lại, và khả năng toàn bộ đoạn mã này bị bỏ đi cũng rất cao
    Ý của anh ấy là muốn xem phiên bản chạy được sẽ trông như thế nào, hiệu năng ra sao, độ khó để cho nó vượt qua test suite của Bun và có thể bảo trì thế nào, đồng thời muốn so sánh song song phiên bản Rust và phiên bản Zig khả thi

    • Làm tôi nhớ đến câu “lời dối trá đã đi nửa vòng trái đất trong khi sự thật còn đang xỏ giày”
      Cách diễn giải công nghệ kiểu đại chúng phần lớn thường dựa vào phản ứng tức thời

  • Ngay cả pull request thông thường của Bun cũng khá hỗn loạn: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
    Phần lớn là do @robobun tự động tạo ra, kiểm tra trùng lặp bằng GitHub Actions (dựa trên Claude), rồi được @coderabbitai và @claude review
    Trong lúc đó CI vẫn đang hỏng, và @robobun cuối cùng còn tự đóng một phần PR của chính mình vì bị trùng với PR khác do chính nó tạo
    Việc merge vào main thì con người vẫn làm

    • Cái này thì tôi không ngờ tới
      Tôi nhớ Bun từng được khen nhờ sự ám ảnh về hiệu năng của Jarred, nên không nghĩ họ lại để LLM tung hoành trong codebase đến mức này

  • Cái này thật vô lý
    Nhìn vào phần “ánh xạ thành ngữ” thì unsafe xuất hiện dày đặc, có vẻ sẽ tạo ra rất nhiều đoạn mã không mang phong cách Rust
    Cách ánh xạ @fieldParentPtr("field", ptr) trông đặc biệt thô bạo
    Tuy vậy, có vẻ “phase A” về cơ bản là dịch từng dòng, rồi sau đó mới dùng prompt để refactor thành Rust tự nhiên hơn và dễ bảo trì hơn
    Vấn đề là thiết kế ngôn ngữ có thể, và thực tế đúng là thường, đẩy mạnh hướng triển khai, nên rất dễ phát sinh những nút thắt sau này khó gỡ
    Cuối cùng thì có lẽ viết lại thủ công theo kiểu truyền thống sẽ là con đường tốt hơn

    • Có lẽ ở bước tiếp theo LLM sẽ xử lý phần biến nó thành mã an toàn và đúng phong cách hơn
      Nhất là với mức tài trợ như Anthropic, một điểm tiện của AI là nó không biết mệt khi refactor đi refactor lại cùng một đoạn mã

  • Tách riêng chuyện migration, cách họ làm việc này đặc biệt thú vị
    Trong docs/PORTING.md được liên kết có khoảng 300 quy tắc porting, và có vẻ quá nhiều để bất kỳ LLM nào có thể “nhớ” hết và làm theo một cách trung thành
    Vì Anthropic sở hữu Bun nên lần porting này về cơ bản có ngân sách token gần như vô hạn; biết đâu họ còn định tung ra số agent tương ứng với số file * số quy tắc để “đảm bảo” mọi thứ đều được tuân thủ
    Họ cũng chia quá trình porting thành hai giai đoạn: A là port thô từng file trong trạng thái cô lập và dự kiến compile sẽ hỏng, B là nối tất cả lại để compile được
    Ở phase A, họ nói với agent rằng mã “không cần phải compile”, và yêu cầu chấm từng file đã port theo chất lượng đầu ra ở mức thấp/trung bình/cao
    Thấp nghĩa là logic sai, trung bình là logic đúng nhưng không compile được, còn cao là logic đúng và có vẻ sẽ compile được
    Cách này gần như đối lập hoàn toàn với kiểu coding agent mà tôi hiểu và đang dùng, nên tôi rất tò mò về kết quả
    Theo cảm giác của tôi, nếu nói không cần compile tức là không đưa ra một “mục tiêu kết thúc” rõ ràng, thì kết quả sẽ trở nên rất khó đoán, và ở phase B có lẽ phải review cả một núi mã không đáng tin
    Tôi grep nhanh thì trong 1279 điểm chất lượng đầu ra kiểu này có khoảng 3% là thấp, 80% là trung bình, 17% là cao

    • Tính đến tháng 5/2026 thì 300 quy tắc có vẻ vẫn ổn
      PORTING.md dài khoảng 16k token và tập trung vào nhiệm vụ chính
      Với sub-agent mới thì không tệ, thậm chí có thể còn là mức lý tưởng

  • Tôi tự hỏi liệu họ thực sự muốn chuyển sang Rust, hay đây chỉ là một bài test LLM của Anthropic

  • Trông khá thú vị
    Tập quy tắc phải xử lý cùng lúc có vẻ không thể kiểm chứng nổi nếu không trải qua một chu kỳ review mã cực lớn
    Token thì có thể rất nhiều, nhưng sau kiểu chuyển đổi này, việc xác minh mã có lẽ sẽ trở nên cực kỳ khó khăn
    Nếu test cũng phải đi qua cùng một quy trình, thì tôi tự hỏi rốt cuộc điều gì còn lại làm tiêu chuẩn của sự thật
    Dù vậy, xét như một thí nghiệm thì thật đáng nể

  • Nhìn vào tình hình của các dự án muốn hạ bệ Node.js, Deno có đưa ra vài cải tiến nhỏ như hệ thống quyền hạn hay hỗ trợ TypeScript mặc định, nhưng không làm thay đổi thế giới, và các tính năng này cũng đang được nhập ngược vào Node.js
    Theo trải nghiệm của tôi thì DX không tốt hơn một cách có ý nghĩa, thậm chí đôi khi còn tệ hơn vì đã có những công cụ rất tốt như pnpm
    Nó có thể nhanh hơn, nhưng trong phạm vi sử dụng của tôi suốt 5~6 năm qua, tôi hầu như không gặp vấn đề hiệu năng nào với Node.js
    JSR cũng không tạo được làn sóng lớn, và thay vào đó cộng đồng làm ra npmx với trải nghiệm tốt hơn hiện nay
    Tuy vậy, tôi khá thích standard library của Deno, ví dụ như @std/collections
    Bun thì có phạm vi quá rộng nên ngay từ đầu đã có nhiều dấu hiệu rủi ro, nhưng tôi vẫn lạc quan dè dặt vì Jarred có vẻ muốn mất bao nhiêu năm cũng được để làm ra runtime JS đa năng tốt nhất
    Nhưng rồi sau khi bị Anthropic mua lại, thấy Jarred giờ làm khá nhiều ~~vibe coding~~ phát triển kiểu agent, rồi thêm tin vibe porting lần này nữa, thì dù chỉ là branch thử nghiệm tôi cũng càng chắc rằng đây không phải dự án mình sẽ dùng
    Vì thế Node.js vẫn tiếp tục thống trị
    Nói nghiêm túc thì TypeScript tích hợp sẵn và SQLite thật sự rất ấn tượng
    Tôi không hoàn toàn phản đối AI; tôi thấy vibe coding các script Python nhỏ hay web app để giải một bài toán rất cụ thể thì vui và hữu ích
    Nhưng với các dự án phức tạp có nhiều bộ phận chuyển động và có người dùng, niềm tin của tôi ngày càng được củng cố rằng “phát triển kiểu agent” ở quy mô lớn, dù có thể tạm thời tăng tốc làm tính năng, cuối cùng vẫn là lỗ ròng vì làm dự án kém ổn định và phình to ra
    Tôi nghĩ ngay đến các ví dụ như VSCode, Cursor, mise, giao diện web của Perplexity
    Làm một cái dropdown JS không giật lag khi cuộn khó đến thế sao
    Tôi mong nhiều công cụ, thư viện và dự án lớn mà tôi phụ thuộc sẽ nhận ra điều này và áp dụng chính sách chống AI nghiêm ngặt hơn

  • Đây đúng là đi sai hướng
    Tôi chưa từng gặp một maintainer Rust nào đang duy trì dự án Rust cỡ trung, tức vài trăm nghìn dòng trở lên, mà hài lòng với khả năng mở rộng ở codebase lớn

    • Xin chào
      Tôi thấy Rust đặc biệt tốt cho codebase lớn:
      https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
      https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
      Tuy nhiên để làm việc hiệu quả thì ít nhiều phải biết mình đang làm gì:
      https://matklad.github.io/2021/09/05/Rust100k.html
      Còn trong bối cảnh này, Zig so với Rust ra sao thì tôi không rõ lắm
      TigerBeetle có cách thiết kế khá đặc thù
    • Nói về nền tảng của tôi, tôi đã duy trì khoảng 6 codebase Rust trong khoảng 10k~100k dòng, nhưng không cái nào vượt quá 100k
      Tôi cũng biết vài trường hợp một chương trình Rust 20k dòng triển khai tính năng cốt lõi của một chương trình Go 300k dòng
      Nên xét chặt chẽ thì không đúng hẳn với điều kiện bạn nêu ra
      Nhưng trong phạm vi 10k~100k dòng, với tư cách maintainer tôi rất hài lòng với Rust
      Kích thước này đủ nhỏ để chương trình giữ được trọng tâm, nhưng cũng đủ lớn để hiện thực một ý tưởng cốt lõi một cách trọn vẹn
      Ở quy mô này, cả ngôn ngữ lẫn công cụ đều là tài sản lớn, ít nhất là theo trải nghiệm cá nhân của tôi
    • cargo-nextest hiện có 84k dòng mã Rust nếu bỏ qua comment và dòng trống, và với tư cách maintainer duy nhất, tôi cho rằng mình không thể viết nó bằng ngôn ngữ khác mà vẫn đạt tiêu chuẩn chất lượng cá nhân

  • Có lẽ vì chuyện này: https://github.com/oven-sh/bun/issues/28001

    • Tôi muốn ai đó giải thích chính xác Rust sẽ bắt được lỗi này như thế nào
      Đây không phải vấn đề an toàn bộ nhớ theo thời gian