Bốn tháng làm việc với Zig: trải nghiệm thực tế từ một lập trình viên chuyển từ Rust

Sau khoảng bốn tháng quay lại với Zig sau vài năm vắng bóng, tác giả đã viết một số phần mềm và tham gia trở lại cộng đồng, cả trực tuyến lẫn trực tiếp. Bài viết tổng hợp những gì anh thích và chưa thích ở ngôn ngữ này, kèm theo so sánh với Rust — ngôn ngữ mà anh từng dùng làm lựa chọn chính trước đây.

Những dự án thực tế

Dự án đầu tiên là snurl, một thư viện tương tác với "smallnet" (Gemini, Finger, Gopher, Spartan...). Mục tiêu là tạo ra một giải pháp thay thế cho curl trong hệ sinh thái nhỏ này, với yêu cầu kiểm thử và fuzzing tương tự nhưng ở quy mô gọn hơn, đồng thời tuân theo tinh thần TigerStyle trong chừng mực hợp lý.

Một vấn đề gặp phải ngay từ đầu: trình fuzzing chưa thực sự hoạt động. Dù tính năng này được quảng bá trong file main.zig mẫu do lệnh zig init tạo ra, nó vẫn chưa được hoàn thiện — điều không quá bất ngờ với trạng thái hiện tại của Zig, nhưng vẫn gây thất vọng.

Sau đó, tác giả viết thêm hai chương trình chưa công bố: một trò chơi gõ phím dạng TUI (đơn giản hơn dự kiến) và một trình mô phỏng n-body có mô phỏng tiến hóa sao sử dụng raylib.

Zig Day: khi cộng đồng gặp gỡ trực tiếp

Sự kiện đáng chú ý nhất là Zig Day Seattle diễn ra ngày 20/8, với sự có mặt của Andrew Kelley — người sáng tạo ra Zig. Sự kiện ban đầu dự kiến tổ chức tại thư viện Bellevue nhưng phải chuyển sang thư viện Bothell vì lượng đăng ký vượt quá sức chứa.

Định dạng của Zig Day rất đáng học hỏi: những người quan tâm đến Zig tụ họp, cùng làm dự án và trao đổi. Do được tổ chức bởi các nhóm địa phương, cộng đồng Zig trở nên gắn kết hơn. Tác giả đã cùng một người bạn làm việc trên snurl, tích hợp thư viện chuẩn TLS của Zig làm backend thay thế.

Những điểm được yêu thích

anyzig và việc quản lý phiên bản

Công cụ anyzig rất hữu ích khi phải dùng đồng thời zig master và 0.16.0 cho các dự án khác nhau. Hạn chế duy nhất: nó không hoạt động ngoài thư mục có file build.zig.zon, khiến việc tự động định dạng các script Zig lẻ bị gián đoạn.

Cấp phát bộ nhớ tường minh

Mỗi hàm trong Zig phải nhận một tham số allocator tường minh. Điều này khác với hầu hết ngôn ngữ lập trình — vốn dùng allocator mặc định có thể thay đổi toàn cục, hoặc dùng context ngầm định như Odin.

Ưu điểm là có thể linh hoạt chọn allocator cho từng phần mã: arena allocator cho một số tác vụ, general purpose allocator cho tác vụ khác, hay FixedBufferAllocator khi chỉ cần thao tác đơn giản. Cách làm của Zig rõ ràng hơn hệ thống context ngầm định của Odin, và vượt trội hơn việc Rust ẩn các lần cấp phát, gây panic khi hết bộ nhớ.

Tham số IO

Tham số IO thậm chí còn mạnh mẽ hơn. Mọi hàm tương tác với hệ điều hành đều phải nhận tham số này, cung cấp ngữ cảnh cho vào/ra và mọi thứ khác. Việc chuyển Zig sang hệ điều hành mới chủ yếu chỉ là chuyển IO.

Trong kiểm thử, điều này cực kỳ tiện lợi: chỉ cần truyền vào một IO giả lập, có thể thay đổi luồng đầu vào, giả lập lỗi ghi... Tương tự như allocator, tham số IO giúp phân biệt rõ hàm thuần túy và hàm có tác dụng phụ.

Triết lý của Zig là giữ mọi thứ đơn giản nhưng vẫn bổ sung tính năng mạnh mẽ. Thay vì thêm 100 tính năng nhỏ na ná nhau, họ cung cấp một tính năng lớn hỗ trợ mọi trường hợp sử dụng. Sàn thấp, trần cao.

Comptime

Comptime là cách liền mạch để vừa lập trình meta vừa tính toán trước. Đây là một trong những điểm mạnh được tác giả đánh giá cao nhất.

Build system

Build system của Zig rất xuất sắc — đến mức các công ty như Uber đã áp dụng nó cho phần mềm viết bằng ngôn ngữ khác. Tác giả đặc biệt thích khả năng tích hợp các công cụ bên ngoài một cách liền mạch, điều mà Cargo thường gây khó khăn — đặc biệt quan trọng với dự án có sinh mã tự động.

Văn hóa phụ thuộc

Văn hóa phụ thuộc của Zig rất lành mạnh với nguyên tắc đơn giản: tránh phụ thuộc khi không cần thiết. Khi buộc phải dùng, đó thường là thư viện đã được kiểm chứng và tích hợp dễ dàng qua translate-c. Hầu hết chương trình Zig chỉ có một hai phụ thuộc trực tiếp và không có phụ thuộc gián tiếp — tương phản rõ rệt với Rust, nơi dự án nhỏ nhất cũng có hàng chục phụ thuộc gián tiếp.

Lý do một phần là các tính năng thiết yếu như reflection, sinh số ngẫu nhiên, xử lý lỗi và phân tích JSON đã có sẵn trong ngôn ngữ hoặc thư viện chuẩn, không cần các thư viện riêng như serde hay syn.

Xử lý lỗi dễ dàng

Zig khuyến khích xử lý lỗi đúng cách ngay từ đầu. Cách lười nhất là dùng từ khóa try và thêm ! vào kiểu trả về của hàm. Ngược lại, Rust dễ dẫn lập trình viên đến việc chèn panic khi tạo mẫu rồi quên gỡ bỏ — tác giả từng thấy mã Rust chạy production mà panic thay vì trả lỗi đúng cách.

Biên dịch tăng dần

Với lệnh zig build --watch -fincremental, trình biên dịch theo dõi thay đổi, xác định chính xác phần đã sửa và chỉ biên dịch lại phần đó, xuống tận bước liên kết. Kết quả nhanh đến mức dưới ngưỡng cảm nhận của con người, ngay cả với mã nguồn lớn.

Điều này tạo ra quy trình làm việc rất mượt: chạy trình biên dịch ở chế độ tăng dần bên cạnh trình soạn thảo và nhận cập nhật ngay khi lưu file. Với Rust, vòng lặp biên dịch 10 giây trở lên là phổ biến — đủ lâu để mất tập trung nhưng chưa đủ để làm việc khác hiệu quả.

Hiện tại, biên dịch tăng dần chỉ hỗ trợ trên x86_64 Linux và macOS. Người dùng hệ điều hành hoặc kiến trúc khác sẽ phải chờ đợi.

Những gì cần cải thiện

Tính ổn định

Như mọi người dùng Zig, tác giả mong thư viện chuẩn sớm ổn định. Đây được hiểu là một trong những nhiệm vụ cuối cùng trước phiên bản 1.0, và là lý do bản 0.17.0 mất nhiều thời gian phát hành. Đây cũng là lý do duy nhất khiến tác giả vẫn dùng Rust cho một số dự án.

Hỗ trợ lifetime

Tác giả mong trình biên dịch phát hiện lỗi trả về biến cục bộ (dangling pointer) trong chế độ debug — dưới dạng lint tích hợp hoặc vô hiệu hóa vùng nhớ đó sau khi hàm kết thúc. Hiện tại, việc này rất dễ xảy ra ngoài ý muốn, và trình biên dịch còn chấp nhận mã sẽ bị hỏng trong tương lai khi biến tồn tại suốt phạm vi thay vì chỉ trong khối.

Tài liệu

Zig được ghi chép khá sơ sài. Đủ để bắt đầu nhưng muốn đi xa hơn phải suy luận ý định từ các chú thích thưa thớt gắn với hàm. Ví dụ rất hiếm — tác giả vẫn chưa làm cho TLS của thư viện chuẩn hoạt động trong snurl vì không ai trong nhóm hiểu cách thiết lập buffer đúng cách.

Hệ quả là kiến thức xây dựng chương trình Zig vững chắc bị phân tán khắp nơi trên mạng. Người gắn bó với cộng đồng sẽ thành công, nhưng người mới thì gặp khó khăn. Mặt tích cực là điều này thúc đẩy tương tác cộng đồng — trong bối cảnh LLM đang đe dọa sự hợp tác giữa người với người, kết nối này càng quý giá.

Allocator tại comptime

Tác giả muốn phân tích JSON ngay lúc biên dịch. Với dự án có file JSON tĩnh nhúng trong binary, việc phân tích sẵn thành tập hợp struct sẽ rất hữu ích. Nhưng trình phân tích JSON của thư viện chuẩn cần allocator, mà chưa có allocator nào hoạt động tại comptime. Giải pháp dài hạn là khôi phục khả năng dùng FixedBufferAllocator ở comptime.

Bootstrapping

Quá trình bootstrapping của Zig khá ấn tượng: nhóm phát triển loại bỏ phiên bản C++ của trình biên dịch và thay bằng một WASM blob nhỏ kèm trình thông dịch WASM. Tuy nhiên, cách này vẫn cần blob nhị phân đã biên dịch sẵn trong mã nguồn — kẻ xấu vẫn có thể chèn mã độc.

Hệ quả quan trọng: nhiều bản phân phối như Debian không thể đóng gói Zig vì không đáp ứng hướng dẫn đóng gói. Tác giả từng phải chọn ngôn ngữ khác cho một dự án chỉ vì lý do này. Vấn đề mang tính tạm thời — khi Zig ổn định, việc xây dựng trình biên dịch thay thế sẽ dễ dàng hơn nhiều nhờ thiết kế ngôn ngữ đơn giản.

Bước tiếp theo

Tác giả sẽ tiếp tục dùng Zig và tham gia cộng đồng. Anh cho biết chưa tìm được ngôn ngữ nào mình thích hơn Zig, kể cả với những thiếu sót hiện tại. Kế hoạch sắp tới gồm chuyển dự án ReTangled (trước đây viết bằng Rust) sang Zig để tận dụng build system, và đóng góp trực tiếp nhiều hơn cho dự án — dù bị hạn chế bởi thời gian học tập và tài liệu chưa đầy đủ.

Với độc giả Việt Nam quan tâm đến ngôn ngữ lập trình hệ thống, Zig đại diện cho một hướng tiếp cận thú vị: tường minh hơn C, ít phức tạp hơn Rust, và sẵn sàng phá vỡ tương thích để đạt kết quả tốt nhất. Đây là lựa chọn đáng theo dõi khi Việt Nam ngày càng có nhiều kỹ sư tham gia các dự án mã nguồn mở quốc tế.