Việc viết lại Bun bằng Rust đang tiến triển ra sao?

• Dù được biết đến như một công việc hoàn tất trong 11 ngày, nhưng đến ngày 27/7/2026, tức 6 tuần sau khi được hợp nhất vào main, vẫn chưa có thẻ phát hành và các công việc liên quan vẫn đang tiếp tục
• Lần viết lại ban đầu từ ngày 3~14/5/2026 đã tiêu tốn 165.000 USD chi phí API Anthropic, nhưng có vẻ chưa bao gồm chi phí Buildkite CI/CD và các công việc tiếp theo
• Số PR mở của robobun đã tăng từ 1.277 vào ngày 9/7 lên 2.475 vào ngày 27/7; nếu mỗi PR mất khoảng 40 phút pipeline thì cần chạy liên tục 86 ngày mới xử lý hết
• Mức sử dụng Claude tăng vọt cùng thời điểm bắt đầu viết lại, đồng thời robobun và nhân viên Anthropic cũng tham gia nhiều hơn vào công việc Rust, nên khó thể khẳng định thời điểm hoàn tất và tổng chi phí thực tế chỉ là 165.000 USD
• Vì đội ngũ Bun không trực tiếp khẳng định việc viết lại đã hoàn tất hay tổng chi phí là như vậy, nên nếu lấy thành quả lập trình AI làm cơ sở định giá doanh nghiệp thì cần xem cả giá trị so với chi phí và mức độ can thiệp nhân lực liên tục

---

Việc viết lại vẫn tiếp diễn sau khi hợp nhất

• Jarred Sumner cho biết trong Rewriting Bun in Rust rằng từ ngày 3~14/5/2026, trong 11 ngày, ông đã chi 165.000 USD cho các lệnh gọi API Anthropic và hợp nhất kết quả viết lại vào main
  • Tức khoảng 15.000 USD mỗi ngày, một quy mô mà nhiều nhà duy trì mã nguồn mở khó có thể gánh nổi
  • Có vẻ con số này chưa bao gồm chi phí CI/CD vốn dường như tiếp tục chạy trên cụm Buildkite của tổ chức
• Tính đến ngày 27/7/2026, đã 6 tuần kể từ sau khi hợp nhất nhưng vẫn chưa có thẻ phát hành mới; kể từ thẻ cuối cùng bun-v1.3.14 thì đã trôi qua 11 tuần
  • Trước đây, lần hiếm hoi không có phát hành nào trong hơn một tháng là khoảng trống 6 tuần từ v0.2.2 ngày 26/10/2022 đến v0.3.0 ngày 7/12
• robobun PR mở, một chỉ dấu thay thế cho các PR do Claude Code tạo ra, đã tăng từ 1.277 vào ngày 9/7 lên 2.475 vào ngày 27/7
  • Người ta quan sát thấy việc kiểm tra Buildkite và hợp nhất vào main thường mất khoảng 40 phút, đôi khi lên tới 1 giờ 30 phút
  • Nếu áp dụng mức 40 phút cho mỗi PR, để hợp nhất toàn bộ 2.475 PR thì pipeline sẽ phải chạy liên tục 86 ngày
  • Một số PR không liên quan đến mã Rust, và cũng có những PR riêng lẻ trải qua lượng rà soát rất lớn

Khác biệt giữa chi phí công khai và nguồn lực thực tế bỏ vào

• Mức sử dụng Claude tăng mạnh vào thời điểm bắt đầu viết lại, và sau đó cũng cho thấy xu hướng nhân viên Anthropic và robobun tham gia nhiều hơn vào công việc Rust
  • Phân tích này bao gồm giả định rằng các commit của Jarred Sumner trong thời gian viết lại đã sử dụng Claude
  • Một số PR do nhân viên Anthropic tạo ra, nên không chỉ cần tính chi phí token mà còn phải tính đến sự can thiệp trực tiếp của nhân sự
• Nếu giả định việc viết lại tiếp tục tốn 10.000 USD mỗi ngày, chi phí tích lũy sẽ tiến gần 800.000 USD, nhưng đây là ước tính dựa trên giả định chứ không phải chi phí thực tế đã được công khai
• Đội ngũ Bun chưa từng khẳng định rằng việc viết lại đã hoàn toàn kết thúc hay tổng chi phí chỉ là 165.000 USD
  • Chỉ riêng trường hợp này vẫn khó để kết luận rằng AI đã thay thế công việc của các nhà duy trì mã nguồn mở nhanh hơn
  • Anthropic đang áp dụng nội bộ các công cụ của mình, đồng thời công việc tự động hóa và sự tham gia của nhân viên cũng vẫn tiếp diễn
• Thay vì phủ nhận AI, bài viết cảnh báo về kỳ vọng quá mức và việc định giá doanh nghiệp, nhấn mạnh cần xem giá trị thu được có tương xứng với chi phí bỏ ra hay không và mức định giá đó có hợp lý hay không
• Trình biên dịch C của Anthropic và trình duyệt web FastRender của Cursor đã không có commit nào trong nhiều tháng

[GN⁺]

Ý kiến trên Hacker News

• Bản viết lại bằng Rust của Bun đã chạy trên Claude Code hơn một tháng, nhưng hầu như không ai nhận ra, và nhìn chung nó hoạt động tốt
  Họ sẽ không phát hành cho đến khi vượt qua các bài kiểm thử tương thích Node.js đúng như đã hứa trong video Bun v1.4; nếu PR liên quan được merge, nhiều khả năng v1.4 sẽ ra mắt vào khoảng thứ Ba tuần sau

  • Có thể dành bao nhiêu thời gian cần thiết cho chất lượng phần mềm. Việc một tháng không có bản phát hành không phải chuyện lớn; nếu cần gấp một tính năng cụ thể thì có thể tự đóng góp hoặc tự build
    Node.js, ngoại trừ các bản sửa bảo mật, cũng thường không có bản phát hành đáng kể trong 4–6 tuần vào tháng 12 hằng năm, nên lời chỉ trích lần này, vốn bắt đầu bằng một bài viết bức xúc mà thậm chí không hỏi người trong cuộc trước, có cơ sở khá yếu. Tôi nói điều này với tư cách là maintainer của Node.js
  • Bản thân Claude Code cũng thường có lỗi và sự cố sau phát hành, nên không ngạc nhiên khi người dùng không phân biệt được đâu là lỗi phát sinh từ việc Bun chuyển sang nền Rust và đâu là lỗi thường ngày
  • Tôi tò mò liệu họ có thể trả lời về các chi phí được ước tính trong bài, đặc biệt là chi phí Buildkite, hay không
  • Có thể hiểu lý do lo lắng về tương lai của Bun, vì nhiều dự án vibe coding khởi đầu rất mạnh rồi có thể bị bỏ bê như Anthropic C. Bun nhanh và dễ dùng, nên hy vọng nó sẽ tồn tại lâu như GCC

• Ngay sau một đợt refactor hoặc viết lại quy mô lớn, cần thời gian để lấy lại tốc độ phát triển thường ngày, nên khó đánh giá nhiều thứ chỉ dựa vào số commit và chu kỳ phát hành
  Dù các lập trình viên đã quen với cấu trúc, họ vẫn phải làm quen lại với codebase Rust, và nhiều khả năng đang tập trung vào những việc như truy vết các chỗ dùng unsafe hơn là tính năng cho người dùng. Ngay cả trên kênh canary cũng hầu như không thấy vấn đề hay thay đổi lớn, nên có đủ lý do để xử lý công việc tồn đọng thay vì vội phát hành
  Trình biên dịch C của Anthropic và trình duyệt FastRender của Cursor được xem là các thử nghiệm năng lực chứ không phải dự án duy trì lâu dài, và hy vọng hiện không ai đang trực tiếp dùng chúng

  • Một tháng trước họ đã chuyển toàn bộ người dùng Claude Code sang phiên bản mới, nên theo một nghĩa nào đó, nó đã được phát hành cho môi trường thực tế rồi. Có vẻ họ đang tiến hành từng bước vì nhận được nhiều chú ý và không cần vội phát hành chính thức
  • Góc nhìn về chi phí CI/CD khá thú vị. Thường khi phản biện ROI của AI, người ta nói rằng nhiều code hơn không có nghĩa là giá trị cao hơn, nhưng nếu mỗi lần chạy CI đều bị tính phí thì doanh thu thực sự sẽ tăng
    Điều này cũng ăn khớp với việc CI và kiểm thử bổ sung là then chốt để ngăn các công việc lặp lại do AI tạo ra vượt ngoài kiểm soát
  • Ngay cả từ phía người viết bài, cũng không chắc các con số này cho phép phán đoán được bao nhiêu. Hy vọng sau bản phát hành tiếp theo, Anthropic hoặc Bun sẽ công bố một bài nhìn lại nêu rõ tổng chi phí

• Việc dùng LLM để dịch một dự án trong thời gian ngắn hoặc tạo một bản sao sản phẩm văn phòng chỉ trong một lần quả thật đáng kinh ngạc, nhưng bản chất của phần mềm không nằm ở việc tạo ra ban đầu thật nhanh mà ở phát triển tính năng và bảo trì dài hạn
  Một bản sao Word có thể nhanh chóng làm được các chức năng cơ bản, nhưng LLM bắt đầu hụt hơi từ những chi tiết như cấu trúc trang, bảng, hình ảnh và xoay. Ngay cả khi chuyển SQLite từ C sang Rust và vượt qua toàn bộ kiểm thử, nó nhiều khả năng vẫn chậm vì thiếu nhiều năm tối ưu hóa của triển khai hiện có, đồng thời còn phải gánh các lỗi mới do đổi ngôn ngữ và hỗ trợ về sau
  Trên Reddit liên tục xuất hiện các dự án nói rằng đã triển khai X, Y, Z, nhưng sửa lỗi, phản hồi người dùng, bảo mật, xử lý cấu trúc dữ liệu thay đổi và cơ sở dữ liệu đều không hấp dẫn, nên chúng thường bị bỏ bê nhanh không kém vibe coding
  Nếu không hiểu sâu phần mềm mình tạo ra thì cuối cùng nó sẽ phát nổ; chỉ câu đã viết lại X thành Z trong Y ngày thì chẳng có ý nghĩa gì. Đẩy nhanh điểm khởi đầu và việc hiểu, phát triển, duy trì phần code đã được port là hai chuyện hoàn toàn khác nhau; một bản Rust bị bỏ bê cùng các bài viết quảng bá có thể làm ô nhiễm kết quả tìm kiếm thay cho bản Zig đang được duy trì

  • Mong có nhiều người ghi lại quá trình này hơn. Cá nhân tôi đang học khi làm một dự án phụ thuộc nhiều vào LLM; cảm giác rất phấn khích khi các tính năng phức tạp chạy nhanh chóng, nhưng việc tích hợp, dọn dẹp và trau chuốt UI lại càng đau khổ hơn sau khi đã nếm được tốc độ ban đầu
    Khi code trở nên quá chắp vá và rối rắm, nó chạm tới một điểm quán tính nơi LLM không thể tiến tiếp mà không gây thêm hỗn loạn lớn; khi đó phải sửa kiến trúc, vứt bỏ toàn bộ để làm lại, hoặc quay về điểm cuối cùng còn hoạt động bình thường. Giống như phát triển với jetpack: bạn đến mục tiêu nhanh hơn, nhưng cũng đâm vào tường nhanh hơn và đau hơn
    Các cuộc tranh luận xem AI là tốt nhất hay tệ nhất, cùng cuộc đua về cách dùng công cụ, đã che khuất việc thiếu thông tin về điều gì hiệu quả, điều gì thất bại, và cần thay đổi hành vi ra sao trong quá trình sử dụng. Tôi cũng định viết trải nghiệm sử dụng, nhưng cứ trì hoãn vì làm tính năng mới hoặc sửa các lỗi UI thú vị hơn
  • Trước thời LLM, GitHub đã có hàng nghìn game engine và trình biên dịch cho ngôn ngữ ảo bị bỏ bê. Trên các diễn đàn hệ điều hành đầu những năm 2000, gần như ai cũng tự làm OS của mình, và một số còn chạy được cả Firefox
    Không phải phần mềm nào cũng cần mang tính thương mại hoặc có độ hoàn thiện cao mới hữu ích; chỉ riêng thử nghiệm để học tập cũng đã đủ để học được rất nhiều
  • Càng đi sâu về kỹ thuật, người ta càng dễ bị xem là có thể thay thế. Đó là vì trong tổ chức, ta chấp nhận tiền đề rằng giá trị đến từ năng lực kỹ thuật thuần túy, chứ không phải bản thân con người hay các mối quan hệ
    Nhưng dường như mọi người bắt đầu chấp nhận rằng các yếu tố ngẫu nhiên như hiệu ứng mạng lưới, quyền sở hữu và trách nhiệm giải trình cũng quan trọng. Tuy nhiên, có một nghịch lý là nhiều người làm kỹ thuật bước vào lĩnh vực kỹ thuật chính vì muốn tránh môi trường nơi chủ nghĩa thân quen, đánh giá tùy tiện và sự khoa trương được coi trọng hơn kỹ thuật
  • Tôi từng làm ở một startup đã dừng cả phát triển tính năng để viết lại hoàn toàn một codebase lớn, nhưng vì phụ trách dự án khác nên bỏ lỡ toàn bộ quá trình; vậy mà khi quay lại, gần như không có đường cong học tập nào. Dù ngôn ngữ đã thay đổi, kiến trúc cốt lõi, cấu trúc dữ liệu và khái niệm vẫn giống nhau
    Bun cũng không phải thiết kế lại từ đầu, mà trước hết là chuyển nguyên trạng sang ngôn ngữ mới. Dựa trên kinh nghiệm trước thời LLM, nếu muốn đội ngũ chuyển đổi nhanh, cách đúng là port sang ngôn ngữ khác đơn giản và nhanh nhất có thể; tối thiểu hóa X ngày của giai đoạn viết lại là một mục tiêu tốt
  • Thái độ không hiểu sâu code do chính mình viết là chủ nghĩa ngắn hạn cực đoan. Các maintainer sẽ phải học một cách vất vả ranh giới giữa code do AI tạo ra và code con người có thể bảo trì

• Có người nói rằng họ đã hiện đại hóa bản triển khai Zig ban đầu, áp dụng các best practice để sửa lỗi và đạt được build gia tăng dưới 1 giây. Điều này gợi ý rằng vấn đề từng được dùng để biện minh cho việc viết lại thực ra là do tự tạo ra và có thể giải quyết được
  https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
  Bản Zig cũng dùng LLM nên không liên quan đến cuộc chiến văn hóa. Người hiểu đúng miền vấn đề luôn có thể tạo ra kết quả tốt hơn người chỉ đổ vào các tài nguyên như token trị giá hàng trăm nghìn đô la

  • Trọng tâm để biện minh cho việc viết lại không phải là tốc độ build, mà là lỗi bộ nhớ, đặc biệt khi tương tác với các đối tượng JavaScript được quản lý bằng garbage collection. Zig không có cách tổng quát để chặn điều này, và cũng không thấy tuyên bố rằng Buz đã giải quyết được
  • Dự án này trông giống meme hoặc trò đùa hơn là một nỗ lực nghiêm túc. Họ gọi 600 nghìn dòng hiện có là đống mã hỗn loạn do AI tạo ra, và tuyên bố sẽ từ chối đóng góp do con người viết cho đến khi hầu hết các subsystem được viết lại
    Khó có thể xem nghiêm túc một dự án vừa dùng LLM để dọn dẹp mã lộn xộn, vừa cấm đóng góp của con người

• Nhờ việc viết lại Bun, họ đã mạnh dạn hơn nhiều trong việc port và viết lại mã, cũng như vendoring các phụ thuộc bên ngoài; nhờ đó có thể chuyên biệt hóa theo nhu cầu nội bộ dù không phù hợp với dự án upstream
  Đồng thời giao cho các mô hình lập trình những việc tham vọng hơn, họ cũng tập trung hơn nhiều vào hệ thống kiểm thử và xác minh bên ngoài ranh giới ngôn ngữ. Từng tham gia các đợt viết lại quy mô lớn kéo dài nhiều năm, nhưng việc Bun vừa duy trì test và tương đương tính năng, vừa thêm cải tiến được đánh giá là một thành công kỹ thuật rất lớn

• Tranh luận quanh việc viết lại Bun có nhiều lời chỉ trích kịch tính và công kích cá nhân, dường như mỗi bên đang phóng chiếu những mối quan tâm ý thức hệ sâu hơn của mình. Bài viết này hoài nghi về mức độ AI có thể thay thế lập trình viên thành công, còn luận điểm của maintainer Zig thì gần hơn với đạo đức và tương lai của open source trong thời đại LLM
  Từ góc nhìn lạc quan về năng lực AI, không có nhiều lý do để nghi ngờ rằng một lập trình viên lành nghề có thể dẫn dắt LLM tiên tiến để dịch cả một thư viện. Câu hỏi tiếp theo quan trọng hơn là chi phí hiện tại và liệu sau này có bị chia thành phe áp dụng AI toàn diện và phe không áp dụng hay không

  • Trong đội không có ai có kinh nghiệm Rust
  • Việc port Bun từ Zig sang Rust gần như không đem lại bài học có thể khái quát về Zig, Rust, port ngôn ngữ hay cách dùng LLM. Có quá nhiều đặc tính khó định lượng trong codebase trước và sau, đồng thời còn có sở thích về ngôn ngữ, cách port và coding bằng LLM
    Nếu không đạt kết quả tương tự hoặc tốn nhiều token hơn thì có thể nói là dùng công cụ sai; nếu kết quả gây thất vọng thì có thể viện cớ đó chỉ là proof of concept và các mô hình trong 6 tháng gần đây đã tốt lên nên không thể so sánh, khiến khó rút ra kết luận có thể kiểm chứng
  • LLM rất giỏi tạo ra kết quả trông có vẻ hợp lý nhưng sai, nên có nhiều lý do để hoài nghi. Bất kể kết quả lần này đúng sai ra sao, đây rõ ràng là một sự kiện marketing, và Anthropic từng có tiền lệ công bố phóng đại hoặc sai sự thật nên cần kiểm chứng nghiêm ngặt hơn

• Tôi đã nghi ngờ rằng cả tuyên bố chiến thắng lẫn bài phân tích sâu trông có vẻ thành thật đều hơi vội vàng
  Rủi ro cốt lõi của cơn sốt LLM là nó đem lại thành quả tức thì cho các lập trình viên lành nghề đã mệt mỏi với việc gõ phím và suy nghĩ thủ công, trong khi đem kinh nghiệm phần mềm tích lũy hàng chục năm ra làm tài sản thế chấp. Hóa đơn chi phí thật sự sẽ đến muộn hơn nhiều

  • Gõ phím chỉ là thứ yếu trong kỹ nghệ phần mềm, nhưng trong những tình huống thật sự bị nghẽn bởi việc gõ phím thì LLM có thể có giá trị. Tuy nhiên các tình huống như vậy rất hiếm

• Bài viết sẽ đáng tin hơn nếu phản ánh sự thật rằng Bun nền Rust đã chạy trong Claude Code từ ngày 17/6 và sau khi vào main cũng được cung cấp dưới dạng bản canary. Với một lần viết lại ở quy mô này, giai đoạn canary dài là hoàn toàn chính đáng

  • Bài viết đã đề cập đến việc Anthropic dùng nội bộ thực tế

• Anthropic có thể không mấy quan tâm đến việc phát hành công khai phiên bản tiếp theo. Bản Rust đã chạy hơn một tháng trong Claude Code, nơi có hàng triệu người dùng, và mục đích mua lại Bun có lẽ cũng là Claude Code
  Bản thân dự án open source có thể không quá quan trọng với họ

  • Nếu thật sự chỉ Claude Code mới quan trọng, thì viết lại chính Claude Code bằng Rust sẽ hiệu quả hơn nhiều so với đổi ngôn ngữ của runtime TypeScript. Chi phí khoảng 800 nghìn đô la có thể đến từ ngân sách marketing của Anthropic nhằm tạo hiệu ứng PR lớn
  • Khả năng họ từ bỏ cộng đồng rộng lớn hơn là thấp; càng có nhiều người dùng khác thì Anthropic cũng càng được lợi. Nếu lần phát hành này gặp vấn đề, họ sẽ bị chỉ trích mạnh và niềm tin cộng đồng bị tổn hại, nên có vẻ họ thận trọng hơn thường lệ
  • Bun là một thành phần quan trọng của hệ sinh thái web, nên riêng việc Anthropic phát triển nó bằng AI đã tạo ra hiệu ứng PR khổng lồ
  • Claude Code chắc có thể chạy trên bất kỳ JavaScript runtime nào, vậy tại sao lại cần Bun?
  • Rốt cuộc trông giống một sự kiện marketing để quảng bá việc viết lại mã dựa trên Claude. Thông điệp rằng nếu muốn loại bỏ một codebase khó chịu thì hãy chi nhiều tiền cho Anthropic đã được truyền tải thành công
    Nếu mục tiêu là Claude Code thì lẽ ra nên viết lại nó trước; và nếu họ luôn nhấn mạnh rằng mình không còn trực tiếp viết mã nữa, thì ngôn ngữ triển khai cũng không nên quan trọng

• Ai từng viết lại phần mềm đều có thể hiểu giai đoạn hiện tại. Phần lớn đã chạy được nhưng vẫn phải tiếp tục sửa để không có hồi quy, và áp lực khi phát hành cũng rất lớn
  Tôi cho rằng quyết định viết lại là đúng, nhưng sẽ không muốn triển khai vào môi trường production ngay từ đầu. Nếu Jarred cung cấp bản release candidate trước thay vì phát hành chính thức ngay, áp lực có thể giảm bớt