- Vợ chồng Mitchell Hashimoto cam kết 300.000 USD cho Zig Software Foundation, công khai hỗ trợ việc phát triển độc lập của Zig và hoạt động của quỹ
- Khoản quyên góp sẽ được chi trả trong 2 năm, mỗi năm 150.000 USD, và đợt thanh toán đầu tiên đã được chuyển
- Hashimoto theo dõi Zig từ năm 2019, bắt đầu sử dụng vào năm 2021, và từ năm 2022 tiếp tục viết bài cùng đóng góp cho trình biên dịch
- Dự án terminal Ghostty được công bố năm 2023 cũng được viết bằng Zig, và hiện phần lớn thời gian lập trình của ông đều dành cho Zig
- Zig vẫn còn chặng đường phải đi để đạt độ ổn định và mức độ chấp nhận rộng rãi hơn trong ngành, nhưng Hashimoto xem đây là một dự án có cộng đồng mạnh và mô hình tài trợ bền vững, đồng thời khuyến khích mọi người quyên góp
Cam kết quyên góp 300.000 USD
- Mitchell Hashimoto và vợ ông đã cam kết quyên góp 300.000 USD cho Zig Software Foundation
- Khoản tiền sẽ được chi trả trong 2 năm, mỗi năm 150.000 USD
- Đợt thanh toán đầu tiên đã được chuyển
- Trong một thông báo riêng, ZSF đề cập đến sứ mệnh của quỹ và các hạng mục sử dụng nguồn tiền cụ thể
Vì sao Hashimoto hỗ trợ Zig
- Hashimoto đã theo dõi dự án Zig từ khoảng năm 2019 và công khai chia sẻ sự kỳ vọng của mình với dự án vào năm 2021
- Ông bắt đầu sử dụng Zig từ nửa cuối năm 2021, và từ đầu năm 2022 bắt đầu viết các bài viết liên quan đến Zig và đóng góp cho trình biên dịch
- Sau đó, ông tiếp tục có hàng chục đóng góp mã nguồn cho kho lưu trữ Zig
- Dự án terminal Ghostty được công bố năm 2023 được viết bằng Zig, và hiện Hashimoto dành phần lớn thời gian lập trình của mình cho Zig
Đánh giá về Zig và ZSF
- Hashimoto xem Zig là một dự án phần mềm độc lập có thể tạo ra thay đổi và tầm ảnh hưởng
- Zig khởi đầu như một dự án vì đam mê và đến nay vẫn giữ tính chất đó; ông đánh giá cao cách vận hành dự án và sức mạnh của cộng đồng
- Ông cho rằng mô hình tài trợ minh bạch và bền vững, còn về mặt kỹ thuật thì dự án vừa tham vọng, đổi mới, vừa thực dụng và sát thực tế
- Zig vẫn cần thêm thời gian để đạt độ ổn định và được chấp nhận rộng rãi hơn trong ngành, nhưng ông tin rằng con đường và cơ hội để đạt được điều đó là rất rõ ràng
- Khoảng 1/3 nguồn quỹ của ZSF đến từ các khoản đóng góp cá nhân, và ông khuyến khích những ai có thể hãy quyên góp
1 bình luận
Ý kiến trên Hacker News
Câu “Hoạt động từ thiện của chúng tôi thường là riêng tư, nhưng với xuất thân của tôi, tôi nghĩ việc công khai ủng hộ Zig có thể thực sự giúp ích cho dự án, nên lần này tôi ngoại lệ” nghe khá chạm
Khó diễn đạt chính xác, nhưng phẩm giá căn bản trong đó rất đáng được khen ngợi
Có phải điều đó ngụ ý rằng với các hoạt động từ thiện khác thì việc công khai ủng hộ không giúp ích gì? Nếu vậy thì tôi khá tò mò những hoạt động đó mang tính chất gì. Tất nhiên tiền từ thiện là tiền của họ, muốn làm sao cũng được, nhưng cách diễn đạt nghe hơi lạ
Trong trường hợp này, sự ủng hộ công khai đó có thể kéo thêm đóng góp bổ sung còn lớn hơn cả số tiền mà bản thân anh ấy quyên góp
Nếu có ai từ Zig Foundation đang đọc, tôi rất khuyến nghị họ lập một bảng tuyển dụng
Ở nơi có lượng độc giả đúng chuyên môn, đó gần như là một nguồn doanh thu miễn phí
Có thể là câu hỏi ngớ ngẩn, nhưng tôi là lập trình viên web nên thường chỉ tiếp xúc với lập trình hệ thống/cấp thấp vì tò mò
Mọi người hay nói rằng khi có thể thì nên chuyển hết sang ngôn ngữ an toàn bộ nhớ, nhưng Zig dường như không có bảo đảm đó. Nếu Zig là ngôn ngữ mới thì trường hợp dùng chính của nó hẳn là dự án mới, vậy chẳng phải nên bắt đầu bằng ngôn ngữ an toàn bộ nhớ sao? Nếu ưu điểm của Zig là “hiện đại hơn C và đơn giản hơn Rust” thì tôi hiểu sức hút đó, nhưng nếu thiếu an toàn bộ nhớ thì chẳng phải ưu điểm ấy bị suy yếu sao?
Nếu mục tiêu cuối cùng chỉ là an toàn, thì JavaScript cũng đã đủ rồi. Rust an toàn bảo đảm an toàn bộ nhớ nên là một cải tiến lớn cho lập trình hệ thống, nhưng không phải lúc nào cũng là đáp án cuối cùng. Tùy ứng dụng mà có đánh đổi, và cá nhân tôi cho rằng việc có thể đạt được an toàn một cách dễ dàng còn quan trọng hơn an toàn được bảo đảm. Vấn đề của C và C++ là quá khó để làm cho an toàn
unsafe, tức là về thực chất đang tắt đi các tính năng an toàn bộ nhớZig trên thực tế có kém an toàn hơn Rust hay không thì còn phải xem thêm. Dù thế nào đi nữa, để làm chương trình an toàn thì vẫn phải viết nhiều bài test, và Rust không hề phép màu xóa sạch mọi bug. Trong Zig, nếu test đủ kỹ ở chế độ debug thì có lẽ cũng bắt được phần lớn lỗi an toàn bộ nhớ. Dù vậy, nếu làm thứ như trình duyệt web thì tôi vẫn sẽ dùng Rust
Chỉ cần nhìn vào ngành game, hoặc cả nền công nghiệp thời phần mềm còn phải ghi ra đĩa để phân phối. Vấn đề hiện nay là độ phức tạp của ngôn ngữ đã tăng lên, còn trình độ trung bình của lập trình viên phần mềm thì giảm xuống. Google tạo ra Go cũng phần nào để giải bài toán này, còn Rust là một ngôn ngữ khác với an toàn bộ nhớ là hạt nhân trong thiết kế. Một lý do nữa khiến Rust thuận lợi hơn cho việc viết chương trình an toàn là nó ít phức tạp hơn C++ rất nhiều. Dù nó cũng đang ngày càng phức tạp hơn, may là trong cộng đồng Rust, khái niệm an toàn bộ nhớ đã ăn sâu đến mức ngay cả khi ngôn ngữ phình to hơn thì lợi thế đó và thói quen của lập trình viên vẫn sẽ còn
Zig cũng là một lựa chọn tốt nếu coi trọng an toàn. Nó đơn giản hóa bằng cú pháp như
defer, và cung cấp nhiều mục tiêu chạy cùng công cụ để bắt vấn đề an toàn bộ nhớ trong quá trình phát triển. Dù đây không phải thứ trình biên dịch cưỡng chế mà là kiểu bắt lỗi lúc chạy trong các bản build phát triển/không phảiReleaseFast, thì nó vẫn là một bước cải thiện so với C/C++Nó có khá nhiều công cụ và kiểm tra an toàn bộ nhớ mà C không có. An toàn là một phổ. C kém an toàn hơn C++, C++ kém an toàn hơn Zig, Zig kém an toàn hơn Rust, Rust kém an toàn hơn Java, và Java kém an toàn hơn Python. Hành vi không xác định và hỏng bộ nhớ vẫn có thể xảy ra ở tất cả, chỉ khác ở chỗ chúng dễ xảy ra đến mức nào
Tuy vậy, Zig vẫn chưa phải ngôn ngữ hoàn thiện nên hiện tại khó kết luận dứt khoát. Zig có những tính năng an toàn bộ nhớ khá tốt, không ở mức JavaScript hay Rust nhưng cũng không giống hệt C. Lần trước tôi kiểm tra thì use-after-free là một vấn đề lớn, và nếu không giải quyết được chuyện này thì tôi nghĩ Zig sẽ không có tương lai
JavaScript đúng là ngôn ngữ an toàn bộ nhớ, nhưng runtime và mức độ trừu tượng của nó không phù hợp với lập trình hệ thống. Với lập trình hệ thống, tôi nghĩ cần một thứ mặc định an toàn bộ nhớ nhưng vẫn có lối thoát, và có mức trừu tượng thấp chỉ cao hơn chút so với chiếc PDP-11 ảo mà compiler và CPU phần lớn vẫn đang nhắm đến. Nó nên cho phép lập trình viên suy nghĩ theo mô hình thực thi của CPU mà không bị chôn vùi trong chi tiết, đồng thời khả năng tương thích với C cũng phải rất tốt
Theo tôi Rust làm tốt vế đầu. Điểm yếu là vế thứ hai. Nó có các tính năng cấp thấp, nhưng chúng bị chôn dưới cả đống độ phức tạp của tính năng ngôn ngữ. Ngoài ra nó còn không cho phép một số mẫu quản lý bộ nhớ hoàn toàn an toàn, khiến người ta hoặc phải dùng
unsafequá thường xuyên, hoặc phải bẻ mã theo hướng phù hợp với miền lời giải chứ không phải miền vấn đềZig thì yếu ở vế đầu. Nó có những tính năng tốt nhưng cũng có các khoảng trống lớn. Ngược lại, vế thứ hai của nó khá mạnh. Điều tôi mong muốn là Zig sẽ cung cấp an toàn bộ nhớ mặc định nhưng linh hoạt hơn Rust rất nhiều, đồng thời vẫn giữ được ưu thế về mức trừu tượng thấp và khả năng tương tác với C
Gần đây thấy tin họ chuyển sang self-hosting, tôi có cảm giác đây là một dự án đặc biệt hiệu quả, không dễ lãng phí tiền quyên góp
[1] https://kristoff.it/blog/zig-self-hosted-now-what/
[2] https://ziglang.org/news/migrate-to-self-hosting/
“Em à, anh có một ngôn ngữ lập trình mà anh thật sự rất thích và muốn kể với em”
“Hả?…”
“Anh thích ngôn ngữ đó thật sự thật sự lắm nên muốn quyên góp một chút…”
“……lại bắt đầu rồi đấy……”
“Hay đấy! Mình đi chiếc Cirrus SF50 Vision của chúng ta để đích thân mang tới cho Andrew Kelley nhé”
Rõ ràng đây là tin tốt, nhưng nếu đặt đúng góc nhìn thì số tiền này chỉ tương đương khoảng 0,75 đến 1 năm lương của một lập trình viên lành nghề làm về compiler
Chỉ là phỏng đoán thôi, nhưng có lẽ Microsoft mỗi năm chỉ riêng cho TypeScript đã chi gấp 10~20 lần con số đó, còn với C++/C# thì chắc còn nhiều hơn thế nữa
Tất nhiên chi phí cho lập trình viên không chỉ dừng ở lương. Dù vậy, tôi vẫn cảm thấy những công việc tương tự như lập trình viên compiler làm về compiler chuẩn ANSI tại các công ty công nghệ lớn thường khá khó chịu trong thực tế, so với những công việc tự do hơn, nên có khá nhiều yếu tố kiểu phụ cấp rủi ro trong đó
Nếu có nguồn vốn phù hợp, nó sẽ là chất xúc tác giúp họ không phải làm thêm nghề thứ hai hoặc chỉ làm vào buổi tối/cuối tuần nữa
Thành thật mà nói, tôi rất kỳ vọng vào Zig
Nó gọn gàng, sắc bén và không phải là một ngôn ngữ do những người trong tháp ngà tạo ra mà không quan tâm đến tính thực dụng. Nó cũng không phải được thiết kế bởi một nhóm toàn tiến sĩ như Haskell, nhưng rõ ràng có vẻ đã lấy cảm hứng từ những ý tưởng hữu ích của Rust hay Haskell. Việc viết code bằng Zig có vẻ sẽ khá thú vị
Có thể các đảm bảo về an toàn bộ nhớ không toàn diện như Rust, nhưng tôi vẫn hy vọng một ngày nào đó sẽ thấy Linux Kernel có Zig. Những lập trình viên kernel C lâu năm có lẽ sẽ thích nghi với Zig dễ hơn là với Rust
zig fmtthì tôi mới lại đặt kỳ vọng vào ZigKhi sở thích về style bị biến thành thứ bắt buộc, cảm giác sẽ rất khó chịu. Nó khiến tôi thấy như thể không tôn trọng những lập trình viên dùng ngôn ngữ như một công cụ. Đây cũng có thể là dấu hiệu của một vấn đề sâu hơn về sự tham gia của cộng đồng và mức độ cởi mở với các góc nhìn khác, và Zig dường như thực sự có vấn đề đó[0]
Ở các công ty cần tính nhất quán của code thì chỉ cần chạy linter là đủ, còn với các dự án cuối tuần thì ngoài sở thích style của chính tôi ra tôi chẳng quan tâm gì khác. Đây là vấn đề Zig có phải là ngôn ngữ dành cho người trưởng thành hay không. Nếu đằng nào cũng bị ép code theo một cách nhất định, thì chẳng có lý do gì để không dùng Rust, thứ còn cho luôn cả an toàn bộ nhớ miễn phí
[0] https://github.com/ziglang/zig/issues/16270