- Từ nay với target x86_64, backend x86 tự host của Zig sẽ được áp dụng mặc định trong chế độ debug
- Đạt được nhiều bài kiểm tra hành vi vượt qua hơn và tốc độ biên dịch nhanh hơn so với nền tảng LLVM trước đây
- Việc đưa vào backend tự host giúp Zig rút ngắn mạnh thời gian biên dịch và tăng hiệu quả cho một số tác vụ
- Nhiều cải tiến khác cũng đang được đẩy mạnh như hệ thống build vừa được bổ sung, mở rộng hỗ trợ các hệ điều hành họ BSD, cải thiện runtime UBSan, v.v.
- Tối ưu hóa thư viện chuẩn và các công cụ tự thân tiếp tục nhấn mạnh lợi thế cạnh tranh riêng của Zig
Tóm tắt các tin tức nổi bật mới nhất
8 tháng 6 năm 2025 – backend x86 tự host chuyển thành mặc định trong chế độ debug
- Với target x86_64, giờ đây mặc định sẽ sử dụng backend x86 tự host của Zig
- Trước đây Zig dùng LLVM để chuyển từ bitcode sang object file
- Trên Windows, thay đổi này vẫn bị trì hoãn vì còn cần thêm công việc cho linker COFF
- Backend x86 của Zig đã vượt qua 1.987 bài kiểm tra hành vi, cho thấy độ ổn định mạnh hơn backend LLVM (1.980 bài)
- Tổng số bài kiểm tra là 2.084, nhưng một phần bị trùng với các bài kiểm tra nội bộ của LLVM, nên chỉ được xác nhận bổ sung khi chạy kiểm tra backend tự host
- Lý do chính Zig tập trung phát triển trình sinh mã tự thân là để vượt trội LLVM về tốc độ build
- Theo kết quả benchmark, thời gian build trung bình của
zig build-exe hello.zig -fllvm (dùng LLVM) là 918ms, còn backend tự host ghi nhận 275ms
- Có thể thấy hiệu năng cải thiện rất lớn ở mọi mặt như mức dùng bộ nhớ, chu kỳ CPU, số lượng lệnh, cache miss, v.v.
- Thời gian build của các dự án lớn như chính trình biên dịch Zig cũng được rút từ 75 giây xuống còn 20 giây
- Trong tương lai, Zig dự kiến triển khai song song hóa hoàn toàn việc sinh mã, tăng cường tính năng linking, và phát triển backend aarch64
- Việc đưa vào pass Legalize mới cũng sẽ giúp tăng tốc công việc với aarch64
- Có thể tự mình trải nghiệm các thay đổi mới nhất thông qua bản build mới nhất của nhánh master của Zig
6 tháng 6 năm 2025 – video giới thiệu hệ thống build
- Một video hướng dẫn trên YouTube dành cho người mới bắt đầu với hệ thống build của Zig đã được công bố
- Video giải thích cách tạo module và package Zig, cũng như cách import chúng vào các dự án khác
- Dự kiến sẽ tiếp tục có thêm nhiều video về hệ thống build trong cùng series này
20 tháng 5 năm 2025 – tăng cường hỗ trợ target FreeBSD và NetBSD
- Sau khi hợp nhất Pull Request #23835 và #23913, giờ đây có thể build binary cho target FreeBSD 14.0.0+ và NetBSD 10.1+ bằng
zig cc và zig build
- Chiến lược trích xuất thông tin về libc và các thư viện liên quan vốn áp dụng cho glibc nay đã được mở rộng sang cả họ BSD
- Các tệp
abilists được tạo ra sẽ được phân phối cùng Zig, cho phép khi cross-compile có thể tạo thư viện stub khớp chính xác với từng thư viện libc
- Header hệ thống và header libc cũng được cung cấp kèm theo dựa trên phiên bản OS mới nhất
- OpenBSD, Dragonfly BSD, SerenityOS, Android, Fuchsia và các nền tảng khác cũng là mục tiêu hỗ trợ
9 tháng 4 năm 2025 – trang web chính thức của Zig được build bằng Zine độc lập
- Website chính thức của Zig nay đã chuyển sang cấu trúc được build bằng Zine độc lập
- Nó đã phát triển từ script build trước đây thành một file thực thi đơn lẻ
- Đây được xem là thời điểm tốt để trực tiếp dùng thử
Tin phát hành và cải tiến tính năng
- Bản phát hành 0.14.0 dự kiến sẽ sớm được phân phối, và nhiều cải tiến đáng chú ý đã được áp dụng từ trước
- Nhờ cải thiện C interop và runtime UBSan (Undefined Behavior Sanitizer), lỗi SIGILL từng mơ hồ trước đây nay được thay bằng các thông báo lỗi cụ thể và hữu ích hơn
- Ví dụ: vị trí và nguyên nhân gây tràn số nguyên có dấu được hiển thị rõ ràng, giúp tăng mạnh hiệu quả debug
- Những giới hạn UBSan còn lại:
- Chưa hỗ trợ kiểm tra kiểu động và vòng đời liên quan đến C++ vptr
- Việc hiển thị chính xác vị trí của các thuộc tính như
assume_aligned, __nonnull vẫn chưa hoàn thiện
7 tháng 2 năm 2025 – đổi mới Debug Allocator và SmpAllocator
- Debug Allocator đã được thiết kế lại để hỗ trợ nhận biết kích thước trang tại runtime và tích hợp nhiều tối ưu hóa khác nhau
- Giảm số lần tạo memory map, loại bỏ việc lặp memset 0xaa/0x00 không cần thiết, bỏ các cấu trúc dữ liệu tìm kiếm và trip, v.v.
- Metadata được lưu inline ngay trong trang, giúp việc triển khai lỗi biên dịch/xác minh trở nên dễ dàng hơn
- So với malloc dựa trên C trước đây, giải pháp này có ưu thế về độ dễ đọc và khả năng bảo trì
- Việc phát triển SmpAllocator tối ưu cho môi trường đồng thời đã giúp tối đa hóa hiệu quả thực thi phân bổ bộ nhớ trong môi trường multi-thread
- Benchmark so sánh hiệu năng với glibc đã chứng minh thực tế tốc độ và hiệu quả sử dụng tài nguyên
- Kết quả này được xem là một bước ngoặt quan trọng khi Zig về tính khả dụng đã vượt qua C và libc
24 tháng 1 năm 2025 – cung cấp môi trường debug chuyên dụng cho Zig
- Jacob đã phát triển một bản fork LLDB (trình gỡ lỗi) dành cho Zig, tăng cường hỗ trợ debug cho backend tự host
- Cách build và sử dụng bản fork LLDB này được cung cấp trong tài liệu wiki
- Các nhà phát triển dùng backend tự host của Zig có thể tận dụng công cụ này để có môi trường debug tinh vi hơn
Kết luận
- Zig đang tiếp tục thúc đẩy các thay đổi mang tính đột phá với mục tiêu cốt lõi là nâng cao hiệu năng, hiệu quả build và sự thuận tiện khi debug dựa trên nền tảng tự thân
- Zig đang dần xây dựng năng lực cạnh tranh khác biệt ở cả thuật toán độc lập, trình biên dịch, lẫn công cụ build/runtime
- Từ hỗ trợ nhiều nền tảng như BSD, cải thiện thông báo theo hướng lấy người dùng làm trung tâm, đến đổi mới mô hình bộ nhớ, Zig đang tiếp tục mang lại những tiến bộ thực tiễn có ích cho kỹ sư phần mềm
1 bình luận
Ý kiến trên Hacker News
Theo tôi biết thì Zig đang mỗi ngày phát triển nhiều tính năng khác nhau để cải thiện trải nghiệm phát triển. Ví dụ gần đây còn có PR này. Trước đây, hot code swapping cũng từng nằm trong kế hoạch phát triển của Zig, và với tốc độ này thì tôi đoán có lẽ trong vòng 1 năm nữa tính năng đó sẽ khả dụng trên x86_64. Điều bất tiện lớn nhất mà cá nhân tôi cảm thấy là tốc độ của
comptime. Tôi từng thử chạy một DSL brainF** ở compile time, và nó chạy thật sự rất chậm (dù đó là một thử nghiệm thú vị). Tôi khá tò mò không biết khi nào phần này của compiler sẽ được cải thiện. Tôi cũng cực kỳ mong chờ các backend mới, và còn muốn thử tự làm backend URCL của riêng mình cho Zig nữa 😉Về việc cải thiện hiệu năng comptime thì họ đã biết cần phải làm gì, và từ rất lâu trước đây cũng từng bắt đầu một nhánh liên quan rồi. Nhưng đây là phần đòi hỏi phải làm lại code phân tích ngữ nghĩa ở quy mô đáng kể, nên dù là một việc quan trọng, nó vẫn đang phải cạnh tranh với các ưu tiên khác
Hot code swapping là một tính năng có thể tạo ra thay đổi cực lớn trong lĩnh vực phát triển game. Điều khiến tôi ngạc nhiên là Zig dự định hỗ trợ nó gần như chỉ bằng cờ của compiler. Đây là điều với clang gần như còn khó để thử chứ chưa nói đến dùng được
Tôi chưa tìm hiểu sâu về URCL, nhưng nó đang kéo tôi vào thêm một hang thỏ khác. Nó khiến tôi tưởng tượng ra một kịch bản thật kỳ quái, nơi một IR được tạo ra cho Minecraft lại trở thành đích biên dịch thực sự của một ngôn ngữ
Tôi tò mò không biết việc tạo custom backend có dễ không. Tôi chưa trực tiếp thử, nhưng có ý định làm một thử nghiệm backend nhận AIR rồi tạo báo cáo về an toàn bộ nhớ, ví dụ như kiểm tra dùng giá trị chưa được định nghĩa, stack pointer escape, use-after-free, double free, alias xor mut, v.v.
Tôi cũng thắc mắc liệu hiệu năng comptime có thật sự chậm đến mức thành vấn đề không. Tôi đang làm một thư viện JSON-RPC, và ở compile time tôi tận dụng comptime rất mạnh để phân phối JSON đến các hàm tùy ý. Với hệ thống kiểu tĩnh mạnh của Zig thì không thể phân phối động ở runtime đến các hàm có tham số tùy ý, nên tôi buộc phải tạo mapping kiểu hàm ở compile time. Điều khiến tôi lo là như vậy thì mã đã comptime hóa sẽ bị sao chép cho từng hàm, và kích thước binary sẽ chỉ có thể tăng lên
Chỉ riêng việc đã đi được đến mức này thôi cũng là một thành tựu đáng nể. Như devlog đã nói, phần sắp tới còn đáng mong chờ hơn nữa. Ý tưởng compiler khi build chỉ thay đổi những phần cần thiết của binary vừa mới mẻ vừa mang tính đột phá, và nhờ dự án Zig mà giờ nó đã trở thành mục tiêu khả thi. Sắp tới sẽ là quãng thời gian cực kỳ thú vị
Package management của Zig mang tính thủ công hơn so với Rust. Bạn tự lấy URL gói từ CLI rồi import module trong build script. Ưu điểm của cách này là có thể dễ dàng dùng cả các archive tùy ý làm dependency, và nhiều gói thư viện C cho Zig đơn giản chỉ là nối trực tiếp các bản phát hành untouched (tarball) vào build script. Tuy vậy, với người mới thì nó có thể hơi phức tạp
Với SDL3 thì có hai lựa chọn: native Zig wrapper (https://github.com/Gota7/zig-sdl3) và https://github.com/castholm/SDL, vốn Zig-hóa thư viện/API C theo cách đơn giản hơn
QuickJS chỉ hỗ trợ C API (https://github.com/allyourcodebase/quickjs-ng)
Zig giúp dùng trực tiếp các gói C rất dễ, nhưng vì kiểu dữ liệu nghiêm ngặt nên khi làm việc với API bạn có thể sẽ cần ép kiểu khá thường xuyên
Trình biên dịch D dmd có thể tự biên dịch chính nó trong khoảng 18,4 giây ở bản debug build.
Bộ xử lý của tôi là một con AMD Athlon 64 X2 (4400+) rất cũ, nhưng nó chạy nhanh đến mức tôi thậm chí vẫn chưa nâng cấp
(bao gồm danh sách thông tin CPU chi tiết)
Tôi tò mò không biết có hướng dẫn nào để build Zig trong 20 giây cho chu kỳ phát triển nhanh không. Trước đây mỗi lần build Zig tôi có cảm giác mất rất lâu vì có nhiều stage, nhất là bootstrap từ WASM
Việc Zig có thể tự biên dịch chính nó chỉ trong 75 giây ngay cả khi vẫn dùng LLVM thật sự rất ấn tượng
Tôi hoàn toàn không có ý đòi hỏi quá mức ở Zig, và tôi biết đây là phần mềm nguồn mở, nhưng điều tôi quan tâm nhất là lịch phát hành 1.0 có thực tế hay không.
Zig gần như là ngôn ngữ bao hàm hoàn hảo những gì tôi muốn ở một ngôn ngữ cấp thấp, và giờ tôi chỉ còn chờ nó ổn định hóa.
Và tôi thật lòng khâm phục triết lý thiết kế tối giản của Zig
Với tư cách là người hoàn toàn mới, tôi tò mò Zig có những ưu điểm gì so với các ngôn ngữ khác. Tôi đang hiểu nó như một dạng C hiện đại hơn, nhưng cụ thể “hiện đại” ở đâu thì tôi muốn biết
defer,errdeferđể tự động dọn dẹp khi hàm trả về hoặc khi phát sinh lỗi@typeInfoTôi không quen với C, và luôn cảm thấy có rào cản khi bước vào lập trình cấp thấp vì nhiều điểm bất hợp lý và thiếu trực quan của C. Zig là ngôn ngữ đầu tiên khiến tôi thấy lập trình hệ thống thật sự thú vị và vui
Tôi muốn biết có hướng dẫn nào để build Zig trong 20 giây không. Tôi muốn rút ngắn chu kỳ phát triển, nhưng trước đây từng thấy cả stage1/2/3 đều mất nhiều thời gian nên rất khó để đóng góp
Nếu build hello world bằng
zig inittrong Zig ra 9,3MB, thì dùng cờ-Doptimize=ReleaseSmallcó thể giảm xuống còn 7,6KBChỉ một cờ mà chênh lệch hơn 1000 lần
-OReleaseSmall -fno-strip là 580KB, còn -ODebug -fstrip cũng có thể xuống đến 1,4MB
Backend x86 của Zig mang lại trải nghiệm debug tốt hơn nhiều với bản fork LLDB dành riêng cho Zig
Hiện tại tôi không nhớ rõ liệu đã có thể step qua logic comptime khi debug hay chưa, nhưng đây là chủ đề mới được bàn tới gần đây
Tôi nghĩ Julia có thể đáng cân nhắc dùng Zig như compiler để giành lợi thế về hiệu năng. Tôi cũng nhớ cảm giác lo lắng của các nhà phát triển Julia mỗi lần phát hành mới vì sợ hiệu năng bị thụt lùi
Trên thực tế Julia gắn rất chặt với LLVM. Nhiều phần trong hệ sinh thái phụ thuộc vào LLVM intrinsics, autodiff (Enzyme), biên dịch GPU, v.v.
Compiler đang dần trở nên có thể retarget khá tốt, và đây cũng là chủ đề đang được nghiên cứu tích cực.
Trong tương lai, cũng có thể hình dung Zig trở thành compiler thay thế cho một phần nào đó của ngôn ngữ
Có ý kiến cho rằng bản thân LLVM chính là public API của Julia. Thực tế có cả macro như @code_llvm để trực tiếp hiển thị IR
Việc này chắc chắn sẽ giúp giảm compile time, nhưng ngay trong phía Julia vẫn còn rất nhiều việc phải làm
Ví dụ như chia nhỏ compile cache hơn nữa, tooling để tránh invalidation, loại bỏ tối ưu hóa world splitting, tăng mức tận dụng multithreading của compiler, tự động precompile cho một số signature nhất định, hoặc compile/hot swap code theo kiểu lazy
Đây là một bước tiến rất lớn cho Zig, và tôi nghĩ nó sẽ trở thành hướng khác biệt hóa chính của Zig so với Rust trong tương lai. Nhân tiện, phần lớn code render của công cụ phân tích hiệu năng là do chính tôi viết, và tôi rất vui vì code của mình được dùng rộng rãi trên mạng
liên kết dự án poop
Xem rustc_codegen_cranelift
Tôi nghĩ đây chính là một trong những điều kiện tiên quyết để đưa lại async/await vào Zig
FAQ chính thức của Zig về async cũng đáng xem
Phần này thực ra đã được sắp xếp xong hết rồi, và trong 2-3 tháng tới có lẽ chúng tôi sẽ công bố vài cập nhật thú vị. Chúng tôi đang gần như làm lại toàn bộ I/O như thể đang viết lại cả thư viện chuẩn
Theo nội dung ở link thì có vẻ async hoặc là sẽ không quay lại nữa, hoặc ít nhất cũng phải đến 2028 mới có hy vọng