Tại sao các lập trình viên Functional nên dành một cái nhìn cho Zig

Là một người đã dành hơn 10 năm lập trình bằng Haskell, tôi luôn đặt ra những tiêu chuẩn khắt khe về khả năng lập trình dựa trên hệ thống kiểu (type-system) khi xem xét bất kỳ ngôn ngữ mới nào. Gần đây, tôi đã dành thời gian tìm hiểu Zig và nhận thấy đây là một ngôn ngữ đáng để cộng đồng lập trình viên Functional chú ý.

Lý do đầu tiên khiến tôi quan tâm đến Zig là tính năng comptime. Tôi nghi ngờ rằng đây là một hệ thống đơn giản và linh hoạt hơn nhiều để đạt được những gì mà hệ thống kiểu của Haskell làm được.

Thoát khỏi sự phụ thuộc vào Garbage Collection

Tôi đang cố gắng tránh việc tạo ra một ngôn ngữ hệ thống kiểu functional. Trong suốt thập kỷ qua, các ngôn ngữ functional phổ biến như Haskell hay OCaml đều dựa trên sự tồn tại của Garbage Collection (GC) và bộ nhớ heap. Tuy nhiên, tôi tin rằng chúng ta đang ở giai đoạn kết thúc của một thí nghiệm quy mô lớn về GC.

Mặc dù GC mang lại giá trị to lớn bằng cách giảm thiểu tiếng ồn trong mã nguồn, nhưng đánh đổi là bạn sẽ phải đối mặt với một "rừng" các con trỏ trỏ vào heap. Điều này tạo ra một trần hiệu suất nhất định cho chương trình và việc triển khai ngôn ngữ. Hơn nữa, GC khiến các lập trình viên quá dễ dàng quên đi cách thức hoạt động thực sự của máy móc bên dưới, dẫn đến thế hệ phần mềm cồng kềnh, chậm chạp và lãng phí tài nguyên trên những cấu hình máy tính khủng khiếp ngày nay.

Bối cảnh phần cứng đã thay đổi

Giá trị của GC đã thay đổi kể từ khi nó bùng nổ cùng Java vào năm 1995. Máy móc của năm 2026 rất khác so với năm 1995. Tốc độ tính toán của CPU đã tăng nhanh gấp 10.000 lần, trong khi tốc độ truy cập bộ nhớ lại tụt lại phía sau. Chúng ta đang sử dụng các ngôn ngữ được thiết kế cho máy móc của quá khứ mà không cân nhắc đến máy móc hiện đại.

Zig giải quyết vấn đề này bằng cách khuyến khích quản lý bộ nhớ thủ công tốt hơn thông qua Arenas và Allocators. Điều này mang lại cho người dùng quyền kiểm soát nhiều hơn over bộ nhớ của chương trình, giúp mã viết bằng Zig khai thác tối đa phần cứng hiện đại.

Zig và triết lý của Functional Programming

Điều thú vị nhất là khi nhìn sâu vào thiết kế của Zig, tôi lại thấy những bóng dáng của lập trình hàm.

Trong bản phát hành Zig 0.16, hệ thống IO được thiết kế lại. Khi nhìn vào đoạn mã mẫu, tôi thấy http_client tồn tại trong một Reader monad chứa một allocator và giao diện IO. Đây chính xác là cách IO monad hoạt động trong Haskell. Việc đội ngũ phát triển Zig độc lập tìm ra thiết kế này cho thấy tính phổ quát của cấu trúc đại số trong ngôn ngữ lập trình, và họ đang đi đúng hướng.

Tiếp theo, tính năng comptime của Zig cho phép tạo ra các chương trình "đúng bằng thiết kế" (correct-by-construction).

• Newtype: Trong Zig chỉ là một struct đơn lẻ.
• Sum type: Có thể thực hiện dễ dàng thông qua union.
• Typeclasses: Có thể mô phỏng bằng comptime và structs.

Mặc dù việc phải khởi tạo và truyền đi truyền lại "typeclass dictionary" (struct chứa các hàm) có vẻ hơi cồng kềnh hơn so với Haskell, nhưng điều này phù hợp với triết lý "không có hành động ma quái ở xa" (no spooky action at a distance) của Zig. Bạn hoàn toàn kiểm soát được dòng chảy của mã nguồn.

Kết luận

Tôi cực kỳ kỳ vọng vào Zig. Ngôn ngữ này đang dám đổi mới trong một ngành công nghiệp phần lớn đã ngừng đổi mới các ngôn ngữ lập trình. Zig cung cấp những gì tôi cần để diễn đạt các ý tưởng một way ngắn gọn, đồng thời comptime hỗ trợ xuất sắc cho việc lập trình hệ thống kiểu.

Với triết lý rõ ràng và không gây bất ngờ về mặt ngữ nghĩa, Zig có một "đường đi tự do" (mean free path length) lớn hơn nhiều so với Rust hay C++. Tôi yêu Haskell, nhưng tôi chắc chắn rằng Zig sẽ chiếm một phần lớn trong tương lai lập trình của tôi.