Quay lại với Zig - Zig → Rust → Zig

 (gracefulliberty.com)
4 điểm bởi GN⁺ 22 giờ trước | 3 bình luận | Chia sẻ qua WhatsApp
  • Zig khởi đầu là một ngôn ngữ cấp thấp nhằm giảm bớt những bất tiện của C, và đã trở thành một ngôn ngữ đáng xem xét lại nhờ các triết lý như cấp phát bộ nhớ tường minh và không có luồng điều khiển ẩn
  • Rust từng là một lựa chọn thực dụng để thoát khỏi việc Zig thay đổi thường xuyên và hệ sinh thái còn non trẻ, nhưng đã bộc lộ giới hạn ở các điểm như FFI, biên dịch chéo và cấp phát ẩn
  • Quyết định quay lại Zig không chỉ đến từ lý do kỹ thuật, mà còn do niềm tin vào dự án Rust suy giảm quanh vấn đề quản trị và chính sách về mã do LLM tạo ra
  • Zig của năm 2026 vẫn chưa ổn định và Zig 0.17.0 dự kiến sẽ phá vỡ hệ thống build, nhưng cảm giác về ngôn ngữ không khác nhiều so với năm 2020 và trải nghiệm quản lý gói đã tốt hơn
  • Thay vì cung cấp an toàn bộ nhớ ở thời điểm biên dịch theo kiểu Rust, Zig chọn cân bằng giữa sự đơn giản và an toàn khi chạy bằng triết lý ReleaseSafe, kiểm thử, fuzzing và assertion

Điểm khởi đầu khiến Zig hấp dẫn

  • Lần đầu biết đến Zig là vào năm 2020; khi đó nó trông như một ngôn ngữ mới nhỏ gọn với thực thi mã tại thời điểm biên dịch và các abstraction đơn giản
  • Khi học C, cảm giác trực tiếp điều khiển máy tính rất thú vị, nhưng các abstraction cũ kỹ và công cụ thiếu thốn lại gây bất tiện
  • Dù mới và chưa ổn định, Zig hứa hẹn là một ngôn ngữ thay thế cho C, và việc có thể học “ngôn ngữ tiếp theo” là điểm hấp dẫn
  • Software Should Be Perfect của Andrew Kelley đã tạo nên tiêu chuẩn để nhìn nhận ngôn ngữ lập trình và phần mềm
    • Cấp phát bộ nhớ tường minh có thể thất bại
    • Không có luồng điều khiển ẩn
    • Khả năng tái sử dụng phổ quát
  • Khi tạo một ngôn ngữ lập trình đồ chơi, công cụ literate programming và web server bằng Zig, ngôn ngữ này cho cảm giác tiện hơn C nhưng ít yếu tố rủi ro hơn

Lý do chuyển sang Rust

  • Mã Zig thường xuyên bị hỏng, và khi còn là sinh viên thì không đủ thời gian để liên tục sửa dự án cho phù hợp với phiên bản ngôn ngữ mới nhất
  • Khi đó chưa có anyzig, nên khó xử lý nhiều phiên bản Zig trên cùng một hệ thống
  • Có những lúc quay lại dự án sau vài tháng thì phải thực hiện một đợt refactor lớn mà bản thân chưa hiểu hết để nó chạy lại
  • Hệ sinh thái khi đó cũng còn nhỏ
    • Với một lập trình viên mới, chưa đủ năng lực tự triển khai mọi thứ cần thiết
    • Thư viện và ví dụ còn ít
    • Thư viện chuẩn liên tục thay đổi
    • Tài liệu cơ bản cũng chưa ổn định
  • Rust khi ấy đã ổn định trong nhiều năm và có hệ sinh thái mạnh
  • Việc học Rust rất vất vả, nhưng sau khi nắm được thì mã chạy ổn định, và sự ổn định đó rất quan trọng
  • Đây là một ngôn ngữ nhanh, cấp thấp, đồng thời cung cấp khả năng biểu đạt cần thiết và giảm chi phí do sự bất ổn từng gặp ở Zig
  • Rust giúp hình thành một mô hình bộ nhớ hữu ích ngay cả khi dùng các ngôn ngữ có ít kiểm tra tích hợp hơn
  • Trong mã không có panic, có thể viết mã tái sử dụng mà không có luồng điều khiển ẩn hay garbage collector
  • Tuy vậy, Rust cũng có mặt che giấu việc cấp phát bộ nhớ và khiến việc làm việc với C trở nên khó khăn

Những bất mãn khiến tôi nhìn lại Zig

  • Rust không phải ngôn ngữ hoàn hảo để tạo ra các chương trình tái sử dụng như mong muốn
    • FFI khó
    • Biên dịch chéo phiền phức
    • Việc cấp phát bộ nhớ bị ẩn và được xem như không thất bại gây khó chịu
    • Bị ràng buộc với LLVM, nên có thể mất rất lâu hoặc không thể hỗ trợ nhiều nền tảng như C
  • Quản trị cũng vẫn là một điểm gây khó chịu
    • Rust Foundation có nhiều foundation members là các tập đoàn khổng lồ
    • Khi các công ty lớn nhất thế giới đóng góp hàng trăm nghìn đô la mỗi năm, có khả năng họ sẽ ảnh hưởng đến hướng phát triển của Rust
  • Việc ngày càng nhiều dự án trong cộng đồng mã nguồn mở chấp nhận mã do LLM tạo ra đã gây sốc
  • Ở nhiều dự án, maintainer và người dùng đã viết hoặc yêu cầu chính sách về LLM
  • Zig đã cấm hoàn toàn LLM trong dự án
  • Rust đã tiến hành khảo sát và tâm lý chung của cộng đồng là phản đối LLM, nhưng chưa lập tức đưa ra chính sách chính thức
  • Đề xuất chính sách của Rust bao gồm một điều khoản cấm đề cập các chủ đề sau trong bình luận PR
    • Tác động xã hội và kinh tế dài hạn của LLM
    • Tác động môi trường của LLM
    • Tình trạng bản quyền của đầu ra từ LLM
    • Phán xét đạo đức đối với người dùng LLM
  • Điều khoản này đã bị gỡ bỏ sau phản ứng phản đối, nhưng chỉ riêng việc từng tồn tại một điều khoản như vậy đã làm giảm niềm tin vào dự án Rust
  • Bản thân chính sách nhìn chung là ổn, vì phần lớn nhằm hạn chế LLM và giảm slop
  • Trải nghiệm này trở thành cơ hội để nghiêm túc nhìn lại Zig sau nhiều năm

Zig của năm 2026

  • Zig vẫn chưa ổn định
  • Tôi định bắt đầu từ một ví dụ Zig 0.16.0 tìm thấy trên web, nhưng ví dụ đó đã cũ
  • Để làm việc hiệu quả với Zig, tốt nhất là giữ một bản sao mã nguồn thư viện chuẩn ở gần và làm quen với nó
  • Zig 0.17.0 sắp được phát hành, và sẽ phá vỡ hệ thống build của mọi dự án
  • Các maintainer đang cố chuyển sang ổn định hóa, và những lần phá vỡ như vậy là một phần của quá trình đó
  • May mắn là bản thân ngôn ngữ không thay đổi nhiều kể từ năm 2020
    • Phần lớn trực giác vẫn còn đúng
    • Một số phần của thư viện đã được làm lại, nhưng mã vẫn dễ đọc
    • Có thể sau 6 năm nữa mã Zig hiện tại vẫn sẽ nhận ra được
  • Giờ đây Zig đã có trình quản lý gói
    • Trước đây tôi nhớ là phải dùng git submodule để quản lý dependency
    • Công cụ tích hợp sẵn tốt hơn nhiều
    • Dự án có thể định nghĩa dependency bằng git và tarball
    • Vendoring hoạt động dễ dàng
  • Hệ sinh thái vẫn chưa đồ sộ, nhưng mục tiêu của Zig cũng không phải là một hệ sinh thái đồ sộ
  • Không có package registry chính thức, và lập trường là không cần một NPM hay crates.io khác
  • Zig hiện tại được đánh giá là đã đạt được sự cân bằng phù hợp

Cách nhìn về an toàn bộ nhớ

  • Zig không cung cấp đảm bảo an toàn bộ nhớ như Rust
  • Đây là đánh đổi vì sự đơn giản, và độ phức tạp của affine type trong Rust không được xem là xứng đáng với lợi ích an toàn mà nó mang lại
  • Dù vậy, điều đó không có nghĩa Zig từ bỏ an toàn
  • Theo góc nhìn trong Zig is safer than unsafe Rust, trong các tình huống phải dùng unsafe Rust, Zig có thể là lựa chọn tốt hơn
  • Zig cũng đang có các nỗ lực để làm ngôn ngữ an toàn hơn
    • Cách tiếp cận không tập trung vào các vùng mã unsafe mà tập trung vào chế độ release
    • Hiện tại, chế độ ReleaseSafe của Zig sẽ crash khi assertion thất bại và khởi tạo toàn bộ bộ nhớ
    • Andrew Kelley quan tâm đến hướng đưa những thứ giống Fil-C vào ReleaseSafe
  • Cách này không cung cấp an toàn bộ nhớ tại thời điểm biên dịch của Rust khi tránh unsafe, nhưng tôi không cho rằng đây là death spiral như một số người nói
  • An toàn bộ nhớ là một phổ, và không có một cách tiếp cận nào tốt nhất cho mọi tình huống
  • Cách của Zig là làm cho ReleaseSafe an toàn nhất có thể ở runtime, rồi xác nhận tính đúng đắn bằng kiểm thử và fuzzing
  • Illegal behavior chưa được kiểm tra cần được tìm ra trong quá trình này, và sau khi tính đúng đắn đã được chứng minh, có thể an toàn phân phối binary ở các chế độ release khác
  • Cách này có nhược điểm so với mô hình Rust, nhưng trong định hướng theo đuổi mạnh mẽ sự đơn giản của Zig, tôi không xem nó là kém hơn một cách tuyệt đối
  • Nếu an toàn bộ nhớ tại thời điểm biên dịch quan trọng đến mức đáng trả giá bằng hệ thống kiểu phức tạp và thời gian biên dịch dài, thì nên chọn Rust
  • Mô hình an toàn bộ nhớ của Zig cũng nối tiếp sang triết lý assertion
    • Thay vì vô hiệu hóa assertion trong ReleaseFast, ta tin rằng kiểm thử đã chứng minh assertion là đúng và đường đi đó là unreachable
    • Nhờ đó Zig có thể tối ưu hóa mã
    • Bài viết liên quan là your assertions are correct

Hướng sử dụng trong tương lai

  • Tôi đã sẵn sàng xử lý các vấn đề phần mềm bằng Zig, với thư viện chuẩn và lịch sử thay đổi release ở bên cạnh
  • Khi không muốn xử lý các chi tiết cấp thấp, tôi sẽ dùng ngôn ngữ scripting ưa thích
  • Trong phần mềm tương lai, tôi dự định lấy Zig làm công cụ cốt lõi
  • Vẫn để ngỏ khả năng không tiếp tục ở lại với Zig
    • Nếu cần độ ổn định hoặc hệ thống kiểu của Rust, tôi có thể dùng Rust
    • Suy nghĩ của tôi về cách tiếp cận của Zig cũng có thể thay đổi hoàn toàn
    • Nhiều ngôn ngữ có thể và nên cùng tồn tại
  • Zig đại diện cho một tầm nhìn phần mềm tập trung vào người dùng bằng cách không phớt lờ chất lượng phần mềm mà đón nhận nó
  • Mọi người xứng đáng nhận được phần mềm đáng tin cậy và mạnh mẽ, và trong kỷ nguyên LLM, phần mềm được tạo ra một cách chỉn chu đang trở nên hiếm hơn, còn người dùng thì bị gây áp lực phải chấp nhận thứ slop ngày càng tệ hơn

Bài viết liên quan

3 bình luận

 
clastneo 16 giờ trước

Tôi từng có trải nghiệm đang học Zig thì thấy nói sắp có phiên bản mới, nên đã bỏ cuộc.
Nếu có bản ổn định thì có lẽ đáng đưa lại vào danh sách học, nhưng đến giờ các thay đổi phá vỡ tương thích vẫn quá nhiều nên tôi thấy ngại đụng vào.
 
click 19 giờ trước

Zig cứ liên tục bỏ khả năng tương thích ngược mỗi khi thay đổi đặc tả ngôn ngữ, nên tôi nghĩ như vậy thì ít nhất cho đến khi ra bản 1.0, sẽ khó dùng cho các hệ thống quan trọng.
Có vẻ ghostty đang khá vất vả vì thay đổi ở std.IO: issue
Lấy ví dụ từ ngôn ngữ khác, nếu trong Java, sau khi Future ra đời mà JDBC API được đổi sang kiểu trả về Future hoặc CompletableFuture, chắc chắn đó sẽ là một bước tiến lớn, nhưng đổi lại hẳn sẽ gây ra sự hỗn loạn khổng lồ.
 
GN⁺ 22 giờ trước
Các ý kiến trên Lobste.rs

  • Một ngày nào đó muốn thử lại Zig
    Thật sự là muốn thử, nhưng đến giờ vẫn bận những việc khác
    Lần cuối chạm vào Zig, chỉ sau khoảng 3 giờ đã gặp lỗi trình biên dịch, nên khá ấn tượng. Công bằng mà nói thì lỗi đó đã được sửa trên nhánh mới nhất rồi

  • Thấy nghi ngờ với nhận định rằng “vì bị ràng buộc với LLVM nên để hỗ trợ nhiều nền tảng như C sẽ mất rất lâu, hoặc có thể không bao giờ làm được”
    Tò mò không biết họ muốn nhắm tới những nền tảng nào mà LLVM không hỗ trợ, và Zig tốt hơn ở điểm nào trong chuyện này
    Muốn hỏi có phải ý là Zig tạo ra mã C tier-4, rồi GCC có thể biên dịch mã đó cho hppa, alpha, sh hay không

    • Theo cách hiểu của tôi, Zig đang tích cực làm việc để giảm phụ thuộc vào LLVM, nên trong tương lai khi triển khai target mới trong trình biên dịch Zig, có thể sẽ không cần đụng tới chính dự án LLVM nữa
    • Hiện tại, cách triển khai đó là sinh mã C
      Vấn đề là Zig có backend chính thức ngoài LLVM, còn Rust thì dùng LLVM
      Nếu là một ngôn ngữ hệ thống nhằm tối đa hóa khả năng tái sử dụng phần mềm, nó nên chạy được càng rộng càng tốt; và điều này đặc biệt đúng nếu nó có ý định thay thế C như Zig
    • Theo trí nhớ lờ mờ thì trọng tâm của mối lo ngại có vẻ nghiêng về thời gian biên dịch hơn là hỗ trợ nền tảng

  • Sau khi thấy thành công của ghostty, tôi định dùng Zig cho phát triển game khi Zig đạt 1.0
    Dù vậy, tôi không chắc các loại game mình làm có thật sự cần mức hiệu năng đó không

  • Những câu kiểu “Zig không từ bỏ tính an toàn, và còn an toàn hơn unsafe Rust. Nếu đằng nào cũng phải dùng unsafe Rust thì Zig có thể tốt hơn” khá phổ biến, nhưng mỗi lần thấy tôi vẫn không hiểu lắm
    Đặc biệt là trong khi tác giả thừa nhận an toàn là một phổ, việc khuyên đổi sang một ngôn ngữ mà mọi thứ luôn luôn unsafe thay vì dùng các vùng unsafe cục bộ nghe khá lạ
    Có thể máy trừu tượng sẽ dễ suy luận hơn đôi chút, nhưng sự đánh đổi đó không thuyết phục tôi