Buz – fork của Bun hỗ trợ Zig mới nhất và build tăng dần dưới 1 giây

• Buz là một fork ở giai đoạn đầu, bắt đầu từ commit ngay trước khi Bun được viết lại bằng Rust, đang được phát triển với mục tiêu trở thành bản thay thế tương thích dựa trên Zig mới nhất
• Toàn bộ build graph, bao gồm cả mã nguồn vendored của JavaScriptCore, đã được chuyển sang build.zig, đồng thời áp dụng một số patch nhỏ cho Zig để đạt được build tăng dần dưới 1 giây
• Dù đã đưa vào các test cho tính năng mới và bản sửa lỗi của Bun phiên bản Rust, vẫn còn nhiều test thất bại, nên dự án cần tiếp tục bám sát các tính năng upstream và thay đổi của JavaScriptCore
• Đã loại bỏ hơn 11.000 dòng mã không được sử dụng và sửa nhiều lỗi trong quá trình hiện đại hóa một số phần triển khai theo hướng dựa nhiều hơn vào thư viện chuẩn Zig
• Dự án chưa thể dùng cho production; mục tiêu dài hạn là giảm nợ kỹ thuật bằng cách kết hợp LLM với sự giám sát của con người, rồi tạo ra một codebase dễ bảo trì ngay cả khi không có LLM

---

Mục tiêu dự án và trạng thái phát triển

• Buz là một fork đang được phát triển dựa trên commit cuối cùng trước khi Bun được viết lại bằng Rust
• Tập trung vào việc trở thành một lựa chọn thay thế tương thích với Bun, đồng thời xây dựng codebase gọn gàng hơn trước
• Dự án đang ở giai đoạn rất sớm nên chưa sẵn sàng để dùng trong production
• Buz được công bố nhằm tránh trùng lặp công sức phát triển, trong bối cảnh một dự án Bun dựa trên Zig tương tự đã được công khai trên Ziggit
  • Vào thời điểm công bố, tác giả vẫn chưa xem xét dự án đó

Port sang Zig mới nhất và build tăng dần

• Bun đã được port sang Zig upstream hiện tại, đồng thời áp dụng một số patch nhỏ cho Zig để hỗ trợ rebuild tăng dần
• Toàn bộ build graph, bao gồm mã nguồn vendored của JavaScriptCore, được tích hợp vào build.zig
• Cấu hình này rút thời gian build tăng dần xuống dưới 1 giây, giúp chu kỳ phát triển lặp nhanh hơn
• Dự án bao gồm submodule Zig master đã áp dụng patch build tăng dần
• Ở thời điểm đó, dự án cũng có thể build bình thường với commit Zig upstream 2b1c663

Test tương thích và theo dõi upstream

• Các test được thêm vào Bun phiên bản Rust đã được đưa sang, trong đó có nhiều test kiểm chứng tính năng mới và bản sửa lỗi
• Hiện vẫn còn nhiều test chưa pass, nên cần tiếp tục bắt kịp Bun upstream
• Song song với việc duy trì tương thích tính năng, dự án cũng dọn dẹp mã và giảm nợ kỹ thuật
• Các thay đổi của JavaScriptCore cũng cần được theo dõi liên tục

Dọn dẹp và hiện đại hóa codebase

• Đã loại bỏ hơn 11.000 dòng mã hoàn toàn không được sử dụng trong Bun
• Một số mã được viết lại và hiện đại hóa, tăng mức sử dụng thư viện chuẩn Zig
• Trong quá trình dọn dẹp và hiện đại hóa, nhiều lỗi cũng được sửa cùng lúc
• Codebase Bun hiện tại có quy mô khoảng 600.000 dòng, và để đạt trạng thái gọn gàng, dự án cho rằng cần viết lại khá nhiều subsystem

Sử dụng LLM và chính sách đóng góp

• Dự án dự định sử dụng LLM rộng rãi để dọn dẹp mã cũ phức tạp, đồng thời áp dụng sự giám sát của con người và các thực hành phát triển tốt hơn
• Cho đến khi đánh giá codebase đã đủ gọn gàng, dự án sẽ không nhận đóng góp do con người trực tiếp viết
• Ưu tiên giảm nợ kỹ thuật và viết mã Zig theo phong cách idiomatic, với mục tiêu trong vài tuần hoặc vài tháng có được một codebase có thể là bản thay thế tương thích cho Rust Bun 1.4.0
• Dự án kêu gọi sự hỗ trợ từ các nhà phát triển có thể sử dụng Sol hoặc Fable
• Về dài hạn, mục tiêu là tạo ra một codebase dễ bảo trì ngay cả khi không có sự trợ giúp của LLM, đồng thời nâng cao năng lực Zig trong quá trình phát triển

[GN⁺]

Ý kiến trên Hacker News

• Điều thú vị nhất ở fork này là nó đã chứng minh rằng Bun lẽ ra đã có thể build nhanh từ lâu
  Hiện tại biên dịch gia tăng của Zig vẫn chưa hỗ trợ aarch64 và vá binary cũng chỉ khả dụng với linker trên Linux, nhưng việc hỗ trợ các nền tảng chính có vẻ chỉ là vấn đề thời gian
  • Nghĩ đến những ồn ào quanh việc fork trình biên dịch Zig để tăng tốc độ build, thật ngạc nhiên khi đây không phải bình luận đứng đầu
    Việc một đội một người đạt được build trong 1 giây cho thấy build chậm là hệ quả của thực hành phát triển cẩu thả, và việc dành thời gian cho fork là một sự phân bổ tài nguyên hoàn toàn sai lầm
• Dùng LLM để dọn lại mã mà LLM đã làm hỏng, có vẻ như chúng ta đã đạt đến đỉnh cao công nghệ vào năm 2026
  • Từ trước đến nay con người vẫn dọn lại mã do con người làm hỏng, nên về logic thì không mâu thuẫn
  • Kết quả của LLM tốt đến đâu phụ thuộc vào năng lực của người dùng chỉ đạo nó
  • Tôi hoài nghi về AI nhưng sẵn sàng dùng; nếu LLM thật sự có thể tự dọn dẹp kết quả của chính nó thì đó có thể là thứ thay đổi cuộc chơi
  • Tôi cũng nghĩ vậy, nhưng ngay sau đó họ nói rằng con người sẽ nắm quyền chủ đạo, giảm nợ kỹ thuật và viết mã Zig đúng idiom để tạo một codebase có thể thay thế Rust Bun 1.4.0 trong vài tuần hoặc vài tháng
    Rốt cuộc có vẻ là sẽ ra lệnh nhiều hơn, hoặc ra lệnh tốt hơn. Cấu trúc mã cũng có vẻ là vấn đề sở thích; hôm qua tôi đã có một cuộc trò chuyện kỳ quặc với một người bạn cứ khăng khăng rằng để xử lý một HTTP request cần bốn tiến trình backend
  • Ngay từ đầu mọi chuyện đã đi theo hướng này. Khi những đầu ra LLM hỏng, chỉ có hình dạng của phần mềm, không thể để con người đọc hay hiểu, đang trở thành mã, thì cuối cùng toàn bộ mã chắc chắn sẽ được tạo ra để máy đọc và viết
    Tôi cho rằng thời đại con người can dự ngay từ đầu chỉ là một giai đoạn tạm thời
• Thật đáng ngạc nhiên khi họ loại bỏ 11.000 dòng mã hoàn toàn chết khỏi Bun, hiện đại hóa để tận dụng thư viện chuẩn nhiều hơn, và còn sửa được vô số lỗi
  Tôi tự hỏi liệu đây có phải chuyện thường gặp trong các dự án lớn mà chỉ là tôi không biết hay không
  • Tổng cộng có 600 nghìn dòng, nên mã chết chiếm khoảng 1,8%. Codebase càng lớn thì để xác định mã có thật sự không được dùng hay không càng phải xem xét phạm vi rộng, và theo thời gian các thay đổi ở xa nhau cũng có thể tạo ra mã chết, nên điều này phổ biến hơn
    Không rõ đó là mã hiển nhiên như if (false) { dead_code(); }, hay là mã về mặt dispatch động thì có thể gọi nhưng về logic thì không thể được gọi. Nếu là trường hợp trước thì 1,8% là cao, nhưng nếu là trường hợp sau thì có thể thấp; cũng có nhiều dự án tích tụ mã trên thực tế gần như sẽ không bao giờ chạy phía sau các feature flag cũ
    Một lượng nhỏ mã chết như tiện ích đơn giản hoặc mã được sinh ra có thể để lại cũng không sao, nhưng đôi khi việc loại bỏ lại kéo theo các đợt xóa và đơn giản hóa dây chuyền
  • Ở công ty trước, tôi đã giảm một component 10 nghìn dòng xuống còn 2 nghìn dòng và sửa hết các lỗi lớn
    Nói nghiêm ngặt thì đó không phải mã chết, nhưng khi dọn một abstraction nhỏ bị sai, các cơ hội dọn tiếp theo mở ra liên tiếp, và cuối cùng chỉ còn phần mềm làm đúng những việc nó được dự định làm. Codebase có xu hướng phình to theo thời gian, nên với quy mô của Bun, điều đáng ngạc nhiên hơn là họ chỉ tìm được 11.000 dòng
  • Trình biên dịch Zig biên dịch lười, nên nó không phát hiện các hàm chết không được gọi từ bất kỳ hàm đã biên dịch nào
  • Xét cách Bun được phát triển, con số này ít hơn dự đoán; có lẽ trong codebase vẫn còn nhiều hơn thế rất nhiều
  • Việc ngạc nhiên trước lượng mã chết này trong một codebase lớn mới là điều đáng ngạc nhiên. Nó chỉ tương đương khoảng 10 PR cỡ bình thường
• Không biết bạn có bao nhiêu năm kinh nghiệm lập trình mà lại xem 11.000 dòng mã chết là hiếm đến vậy
  • Tôi có hơn 10 năm kinh nghiệm. Ý tôi là mã chết rõ ràng không được gọi ở bất cứ đâu, và tôi tự hỏi liệu có nhiều dự án khác có số lượng nhiều đến mức này không
• Mọi dự án coding lấy agent làm trung tâm đều xuất hiện dao động tick-tock giữa phát triển tính năng và quản lý mã
  Ở pha tick, tính năng được thêm nhanh để tạo ra một phiên bản đúng nhưng cực kỳ bừa bộn; ở pha tock, kết quả được tiêu hóa và dọn dẹp để cải thiện hiệu năng, khả năng bảo trì và mức độ dễ vỡ trước thay đổi
  Thường thì sau khi dùng vibe coding tạo một app chạy được trong một ngày, người ta dành một tuần để biến nó thành dự án có thể tiếp tục thêm tính năng mà không sụp như nhà bằng lá bài. Trước AI cũng tương tự, nhưng lập trình viên chuyên nghiệp có mô hình tinh thần mạnh hơn về hệ thống và tốc độ làm việc chậm hơn, nên sự chuyển pha không đột ngột đến mức này
  • Cuối cùng vẫn phải tự xem mã và xác nhận logic không bị lặp khắp nơi và có thật sự bảo trì được hay không
    Các mô hình coding có xu hướng mạnh là chọn lối tắt phá vỡ đóng gói hoặc sao chép mã không nên bị trùng lặp
• Tôi muốn gọi đây là lập trình hiệu năng mang tính phô trương. Tôi thích hiệu năng và thời gian build cũng nên gần 0 giây, nhưng giờ chúng ta đã bước vào vùng lợi suất giảm dần, và nút thắt hiện tại có lẽ không phải thời gian build
  • Các nhà phát triển Bun sẽ không đồng ý, vì họ đã trực tiếp trải qua thời gian chờ dài khi không tận dụng được biên dịch gia tăng: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    Trong dự án lớn, bạn không thể chờ vài phút mỗi lần chạy test hoặc kiểm tra lỗi ngữ nghĩa, nên thời gian build rõ ràng là nút thắt
  • Với những dự án như thế này, build nhanh là thiết yếu, và tôi xem đó là một bước quan trọng giúp dễ bảo trì hơn
• Một Bun do người coi trọng chất lượng mã quản lý thì đáng hoan nghênh, nhưng đó là nhiệm vụ cấp Hercules
  • Hơn là cấp Hercules, nó gần với nhiệm vụ cấp Sisyphus lặp đi lặp lại vô tận
• Ngược lại, tôi cũng muốn thấy một fork Zig chỉ nhận đóng góp từ AI
  Không phải vì tôi cực kỳ ủng hộ AI, mà vì như một dạng nghệ thuật khái niệm hay thí nghiệm, xem hai dự án tiến hóa khác nhau ra sao chắc sẽ thú vị
• Cruller, có liên quan chặt chẽ, cũng dùng codebase Bun trước khi viết lại, nhưng chỉ tập trung vào phần runtime dùng cho production
  Liên kết: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  Thảo luận HN: https://news.ycombinator.com/item?id=49017344
• Tôi không hiểu vì sao Bun lại được bàn tán nhiều như vậy. Tại sao không quay lại dùng Node + npm + Vitest + Vite là được?
  • Có dự án Nub nhằm mang các ưu điểm của Bun đến Node, và nó cũng có thể cho thấy rõ vì sao mọi người thích Bun cũng như khoảng cách với các công cụ hiện có
    https://nubjs.com
  • Chính danh sách đó là lý do nó được chú ý. Thay vì ghép rất nhiều công cụ lại với nhau, bạn có thể dùng một runtime duy nhất xử lý mọi việc cần thiết
    Kết hợp các công cụ theo từng mục đích cũng không có vấn đề, nhưng thật tiện khi mọi vấn đề được giải quyết ngay ở trạng thái mặc định. Bundler của Bun cũng có runtime API, nên cùng tiến trình phục vụ asset có thể bundle trực tiếp trong bộ nhớ mà không cần phối hợp với bundler bên ngoài hay ghi file tĩnh ra đĩa
  • Chính việc phải liệt kê bốn công cụ đã cho thấy tình hình hiện tại tệ đến mức nào
  • Giờ đây lý do phải tiếp tục dùng npm cũng không còn rõ ràng