Phỏng vấn Andrew Kelley, người sáng lập Zig

• Zig hướng tới một ngôn ngữ hệ thống vẫn giữ hiệu năng và khả năng kiểm soát của C, đồng thời giảm các footgun và điểm yếu trong gỡ lỗi, với cách tiếp cận luôn ý thức trực tiếp về CPU và bộ nhớ
• Điểm khác biệt cốt lõi là toolchain, với mục tiêu có thể build chỉ bằng zig build cho bất kỳ hệ điều hành đích nào, chạy từ bất kỳ hệ điều hành nào mà không phụ thuộc vào hệ thống
• Việc trì hoãn 1.0 là lựa chọn nhằm tránh vội vàng hứa hẹn tương thích ngược, và nhờ cấu trúc phi lợi nhuận 501(c)(3), dự án có thể tập trung vào cải tiến dài hạn
• Zig Software Foundation đạt 670.000 USD doanh thu trong năm 2024 và có nhiều hình thức tài trợ khác nhau, đồng thời chuyển từ GitHub sang Codeberg với ưu tiên hàng đầu là hoạt động của CI
• Chính sách no LLM, no AI được áp dụng cho issue và pull request; họ cho rằng đóng góp bằng AI làm tổn hại thời gian review và mentoring, nên mang giá trị âm

---

Điểm khởi đầu của Zig và thiết kế ngôn ngữ

• Bối cảnh ra đời

  • Andrew Kelley đã lần lượt thử JavaScript, Go, Rust và C++ để tạo ra một digital audio workstation, nhưng cho rằng mỗi ngôn ngữ đều có giới hạn khiến ông không thể tạo ra trải nghiệm người dùng như mong muốn
  • Ông đánh giá JavaScript quá high-level bên trong trình duyệt nên khó tận dụng đầy đủ năng lực của máy tính
  • Go có khả năng tương tác với thư viện C không tốt, và với các tác vụ thời gian thực như âm thanh, nơi xử lý phải hoàn tất trong thời gian cố định, garbage collector có thể gây glitch hoặc skip nên không phù hợp
  • Với Rust vào thời điểm trước 1.0, ông cảm thấy khó đáp ứng các quy tắc, ngay cả thay đổi nhỏ cũng có thể tạo ra chuỗi lỗi biên dịch, và sau khi mất một tháng để tinh chỉnh font rendering thì vẫn thấy khó tiến xa hơn
  • C++ ban đầu khá hiệu quả, nhưng những lỗi nhỏ hoặc lỗi gõ sai có thể dẫn đến bug hỏng bộ nhớ và phải mất hàng tuần để gỡ lỗi; ngay cả với “C-style C++” dùng compiler C++ và linker C, vấn đề footgun vẫn còn
  • Điểm xuất phát của Zig là quan điểm không thỏa hiệp về trải nghiệm người dùng dựa trên những gì máy tính về bản chất có thể làm được, chứ không phải giới hạn mà toolchain cho phép

• Vì sao được xem là có thể thay thế C

  • Zig được xem là tốt hơn C vì cải thiện các khuyết điểm và điểm yếu của C mà không từ bỏ sức mạnh của C
  • Những nỗ lực khác nhằm thay thế C thường phải từ bỏ một phần nào đó của C, còn Zig vừa làm được mọi điều C làm được, vừa giảm footgun và tăng khả năng gỡ lỗi
  • C chỉ có integer tối ưu hóa cho signed integer và ngữ nghĩa wraparound cho unsigned integer, trong khi Zig cho phép chọn wraparound hoặc bảo đảm không overflow ở cả signed lẫn unsigned, nên được mô tả là còn “giống C” hơn cả C
  • Để thay thế C, phải có khả năng viết mã có thể tái sử dụng ở mọi nơi như kernel hệ điều hành, thiết bị nhúng, video game, WebAssembly; và nếu Zig mang lại mức chức năng và độ ổn định ngang C, người ta sẽ chọn phía có hiệu năng tốt hơn và ít bug hơn

• Khác biệt với Rust

  • Khác biệt cốt lõi giữa Rust và Zig là hệ thống kiểu
  • Rust yêu cầu mô tả bằng meta-language các quy tắc như tham số hàm có hỗ trợ clone hay không, hỗ trợ interface nào, hoặc có thể truyền những kiểu nào
  • Zig không cần những cơ chế đó, mà truyền kiểu cụ thể hoặc kiểu generic hoạt động theo cách giống template của C++
  • Có một sự đánh đổi: mã Rust có nhiều bảo đảm từ hệ thống kiểu hơn, còn mã Zig có ưu thế về sự đơn giản khi đọc
  • Rust tiếp nối theo phong cách RAII tương tự C++, nơi đối tượng tham chiếu tới đối tượng khác và khi số lượng tham chiếu về 0 thì tự động bị hủy là hướng đi tự nhiên
  • Trong Zig, allocator được biểu đạt tường minh hơn nhiều; reference counting cũng có thể làm được nhưng phải viết mã đó một cách rõ ràng
  • Trong Zig, người ta thường dùng cách cấp phát bộ nhớ được điều chỉnh theo ứng dụng, chẳng hạn gom cấp phát bằng arena allocator rồi bỏ đi một lần, dùng general-purpose allocator cho cách tiếp cận hướng đối tượng, hoặc tạo ra phương án lai phù hợp với mục đích cụ thể
  • Cách viết mã theo hướng suy nghĩ CPU cần làm gì và khiến nó thực thi đúng như vậy được xem là tự nhiên hơn trong Zig so với Rust

• Tính năng killer và toolchain

  • Tính năng killer của Zig là toolchain
  • Đây là một bộ phần mềm không phụ thuộc hệ thống, có thể chạy trên bất kỳ hệ điều hành nào và build mã cho bất kỳ hệ điều hành đích nào
  • Có thể đánh giá mức độ khó để hack vào một dự án qua việc README có bắt cài nhiều system package hay không, quy trình có khác nhau theo từng hệ điều hành hay không, phải chạy bao nhiêu lệnh để cấu hình môi trường, hoặc có cần Docker hay phần cứng cụ thể hay không
  • Tiêu chuẩn tốt nhất là một dòng, một phụ thuộc, luôn hoạt động với mọi người, và bước build trong README của dự án Zig lý tưởng chỉ cần zig build

• Quy tắc ngôn ngữ và giao diện IO

  • Quy tắc coi biến không được sử dụng là lỗi biên dịch giúp bắt bug trong các đợt refactor lớn và tiết kiệm thời gian, còn chi phí thêm chú thích để bỏ biến đi là không đáng kể
  • Nhờ hỗ trợ editor từ nhóm ZLS, nếu bật cấu hình thì có thể tự động discard các biến không dùng, và khi dùng lại thì có thể bỏ discard đó
  • Giao diện IO reader / IO writer mới là một dạng trừu tượng để viết một lần các đoạn mã có thể tái sử dụng như thư viện tải ảnh hoặc mã tuần tự hóa định dạng dữ liệu
  • Mục tiêu là nhận reader cho dữ liệu đầu vào và writer cho dữ liệu đầu ra dưới dạng tham số, tách chúng thành package và dùng cùng logic trong nhiều ứng dụng
  • Khi việc đọc và ghi diễn ra dưới một lớp trừu tượng, compiler có thể khó nắm bắt logic để tối ưu hóa, từ đó làm mất hiệu năng
  • Thiết kế đưa buffer vào bên trong interface được xem là điểm cân bằng tối ưu, vừa giúp compiler tạo mã tốt vừa đạt được khả năng tái sử dụng

Trường hợp sử dụng, 1.0, định hướng sau LLVM

• Trường hợp sử dụng thực tế

  • Zig được giới thiệu là ngôn ngữ dùng khi muốn kiểm soát hoàn toàn máy tính, khai thác tối đa hiệu năng và mức sử dụng bộ nhớ, đồng thời tạo ra trải nghiệm người dùng thuyết phục
  • Ghostty là trình giả lập terminal do Mitchell Hashimoto tạo ra, được đánh giá là một dự án tốt về chất lượng mã, quản lý cộng đồng và kiểm thử fuzz
  • TigerBeetle là cơ sở dữ liệu giao dịch tài chính; khác với chiến lược đặt OLTP lên trên cơ sở dữ liệu quan hệ như PostgreSQL, nó xây dựng một cơ sở dữ liệu chuyên dụng và được mô tả là “nhanh hơn gấp nghìn lần” so với chiến lược đó
  • Khi chạy, TigerBeetle cấp phát trước toàn bộ bộ nhớ sẽ sử dụng về sau rồi không thực hiện cấp phát động nữa, nhờ đó duy trì độ trễ có thể dự đoán và nhất quán
  • Bun là một engine JavaScript dùng JavaScriptCore và nhiều thư viện C++, còn phần mã kết dính được viết bằng Zig
  • Anh cho biết Bun gần đây đã được bán cho Anthropic, và vì vậy ngày càng nhiều người muốn dùng Zig cho mục đích AI
  • Uber dùng Zigcc làm trình biên dịch C để cross-compile cùng phần mã C mà mã Go của họ phụ thuộc vào, và sử dụng nó cho các bản build nhắm tới ARM64

• Vì sao 1.0 bị chậm trễ

  • Dù Zig đã hơn 10 năm vẫn chưa có 1.0, nhưng 1.0 về bản chất là cam kết tương thích ngược, và ý nghĩa của nó khác nhau với từng dự án
  • Anh so sánh rằng Go trong thời gian dài sau 1.0 hầu như không động tới ngôn ngữ, còn Rust gắn mốc 1.0 tương đối sớm nhưng vẫn có thể thay đổi ngôn ngữ khá nhiều thông qua edition trong khi vẫn giữ tương thích ngược
  • Zig Software Foundation không phải startup mà là tổ chức phi lợi nhuận 501(c)(3), nên không có áp lực từ nhà đầu tư, không có kế hoạch bán mình hay exit, và có thời gian để cải thiện trong dài hạn
  • Khi phát hành 1.0, họ muốn đó là “thành quả của tình yêu không thỏa hiệp”, không bị mắc kẹt trong những quyết định tệ hại bị khóa lại vì vội vàng
  • Về “worse is better”, anh cho rằng bản thân cách diễn đạt đó đã vô nghĩa về mặt ngôn ngữ, còn Zig theo đuổi more with less
  • Mục tiêu là đạt được hiệu quả lớn từ tính năng comptime có độ phức tạp thấp, và hướng tới một toolchain có thể biên dịch cho những hệ điều hành và kiến trúc hoàn toàn khác nhau chỉ với một cờ
  • Anh tin rằng khi 1.0 ra mắt, mức độ tiếp nhận chắc chắn sẽ tăng vọt, nhưng mục tiêu là tạo ra một ngôn ngữ cho 50 năm tới
  • Anh cho rằng trong bản phát hành 0.16 sắp tới, thành quả của những lựa chọn này sẽ bắt đầu lộ rõ

• Vì sao rời khỏi LLVM

  • Lý do rời khỏi LLVM là vì cần tránh phụ thuộc cốt lõi đối với sản phẩm cốt lõi
  • Anh lấy ví dụ từ game arcade đối kháng 10 người chơi Killer Queen: nhà phát triển dùng Unity cho engine vật lý, và chỉ một thay đổi nhỏ hay sửa bug trong engine vật lý cũng làm cảm giác chơi đối kháng thay đổi, khiến họ không thể cập nhật lên phiên bản Unity mới
  • Anh cho rằng việc đặt một phụ thuộc như vậy vào sản phẩm cốt lõi là sai lầm, và Zig cũng đang trong quá trình sửa sai điều đó với LLVM
  • LLVM được ví như “bánh phụ của xe đạp”; sau hơn 10 năm phát triển Zig, anh đã hiểu nhiều hơn về phát triển compiler và giờ tin rằng có thể tháo bánh phụ ra để cạnh tranh với LLVM
  • Với backend x86 tự phát triển, Zig có thể biên dịch tăng dần để tạo ra binary mới trong dưới 50ms sau khi thay đổi, ngay cả với codebase lớn cỡ hàng triệu dòng

• Tên gọi và lộ trình học

  • Tên Zig được chọn khi anh tìm một từ ngắn mà kết quả tìm kiếm cho “Zig programming language” là 0, rồi dùng một script Python để in ra các từ ngẫu nhiên và chọn từ đó
  • Linh vật cự đà được gọi là “ziguana”
  • Với người mới bắt đầu, anh đặc biệt khuyến nghị Ziglings
  • Ziglings gồm một loạt bài tập với những đoạn mã gần như hoạt động nhưng có vấn đề, để người học sửa chương trình bị hỏng và qua đó học các tính năng mới của ngôn ngữ
  • Việc chuyển từ C sang Zig đặc biệt mượt mà; mọi thứ làm được trong C đều có thể làm trong Zig, nhưng có ít footgun hơn
  • Nếu trong C xảy ra segmentation fault thì thường ngoài dòng “segmentation fault” sẽ không có thêm gì và phải dựa vào khả năng dùng debugger, còn trong Zig có thể nhận được đầy đủ stack trace chỉ tới từng dòng mã
  • Việc học Zig như ngôn ngữ lập trình đầu tiên có phù hợp hay không còn tùy từng người, nhưng với ai muốn học cách máy tính hoạt động thì đây là ngôn ngữ tốt vì giúp họ học về CPU và bộ nhớ

Vận hành quỹ, quản trị và lựa chọn nền tảng

• Cấu trúc tài chính và tài trợ

  • Tổng thu nhập của Zig Software Foundation trong năm 2024 là 670 nghìn USD
  • Nguồn thu đa dạng, đến từ nhà tài trợ cá nhân và đóng góp của nhiều công ty, với cấu trúc mà không một chủ thể đơn lẻ nào có thể ép buộc định hướng phát triển
  • Nếu một nhà tài trợ yêu cầu “hãy làm việc này” thì có thể từ chối, và ngay cả khi nhà tài trợ đó ngừng hỗ trợ tiền thì vẫn có thể tồn tại
  • Nhà tài trợ chỉ có thể tạo ảnh hưởng theo cùng cách như những người khác, chẳng hạn tham gia bug tracker, gửi pull request, hoặc trò chuyện trên các kênh phát triển; không có kênh bí mật ưu tiên cao riêng biệt nào
  • Mức lương năm của Andrew Kelley là 154 nghìn USD, và được cho là đã được xác định trong cuộc họp hội đồng quản trị đầu tiên dựa trên mức lương trung vị của kỹ sư phần mềm cấp cao tại thành phố nơi tổ chức phi lợi nhuận được thành lập
  • Quỹ có 1 nhân viên và khoảng 5 nhà thầu được trả thù lao làm việc toàn thời gian, trong đó 91% thu nhập của năm trước được chi trả cho các nhà thầu làm việc cho dự án
  • Với một đề nghị 100 triệu USD không kèm điều kiện, ông trả lời rằng có thể nhận nhưng sẽ không dùng để mở rộng mà gửi ngân hàng để không phải gây quỹ trong 100 năm
  • Hiện ông đang quản lý một nhóm 5 người, cho rằng nếu vượt quá 10 người thì gánh nặng có thể lớn, và nói rằng mình không có ý định trở thành người quản lý một tổ chức 100 người

• 501(c)(3) và tính minh bạch

  • Ông phân biệt rằng 501(c)(3) khác với 501(c)(6)
  • 501(c)(6) là một business league, và Rust Foundation được nhắc đến như trường hợp các công ty như Amazon, Netflix, Microsoft, Meta cùng có lợi ích chung trong thành công của Rust và đóng góp tiền
  • 501(c)(3) không được phép vận động hành lang với chính phủ, và tồn tại chỉ vì tuyên bố sứ mệnh chứ không phải vì lợi ích của các doanh nghiệp
  • Các bài blog công khai chi tiết thu chi không phải nghĩa vụ mà là sự minh bạch tự nguyện, và ông cho rằng vì các chỉ số đang tốt nên điều đó cũng giúp tăng niềm tin và hỗ trợ gây quỹ

• Lý do rời GitHub và mạng xã hội

  • Lý do rời Reddit và Twitter là vì việc đăng bài lên các trang đó ngày càng kém liên quan, giống như đăng lên Slashdot hay Digg, và vì ông muốn giảm tối đa thời gian làm marketing với tư cách một kỹ sư phần mềm
  • Ông cho rằng tập trung nhiều hơn vào các sự kiện trực tiếp và meetup là khoản đầu tư tốt hơn cho sự phát triển cộng đồng so với mạng xã hội, nơi thuật toán kiểm soát những gì được nhìn thấy hoặc buộc phải tương tác với troll
  • Lý do chuyển kho lưu trữ chính của Zig từ GitHub sang Codeberg vào cuối năm 2025 là vì GitHub không còn cung cấp kết quả continuous integration đúng cách nữa, tức là “đơn giản là không hoạt động”
  • Sau khi chuyển sang Codeberg, máy chủ continuous integration đã hoạt động trở lại
  • Việc rời GitHub Sponsors là một lựa chọn khó khăn vì có thể mất nguồn thu, nhưng ông đánh giá rằng để viết phần mềm thì ưu tiên cao nhất là CI phải hoạt động
  • Sau khi rời GitHub, về mặt tài chính ông mô tả là “hoàn toàn ổn”
  • Zig là phần mềm theo giấy phép MIT, là một sự đóng góp vô điều kiện cho thế giới phần mềm, và ông xem tài trợ cũng là sự đóng góp vô điều kiện
  • Lý do chọn Codeberg là vì về bản chất nó tương tự GitHub nên dễ chuyển đổi, đồng thời đây là một tổ chức phi lợi nhuận của Đức
  • Ông cho rằng code forge không phải công cụ marketing của dự án; mọi người khám phá ngôn ngữ không phải qua GitHub hay Codeberg mà qua các bài thuyết trình, meetup, video YouTube, hay các nhóm meetup Zigday

• BDFL và quản trị dài hạn

  • Các dự án phần mềm thường phải chọn giữa kiểm soát theo thứ bậc và quy trình dân chủ, và nhiều dự án chọn mô hình BDFL vì tính đơn giản
  • Khi một người kiểm soát, người đó phải chịu trách nhiệm hiểu mọi thứ và có một tầm nhìn nhất quán cho dự án
  • Trong một ủy ban, các trường hợp sử dụng hợp lệ và tầm nhìn khác nhau có thể xung đột với nhau, và khi không có một thiết kế duy nhất nào có thể đồng thời thỏa mãn cả hai trường hợp sử dụng thì sự thỏa hiệp có thể dẫn đến một sản phẩm tệ hơn
  • Andrew Kelley cho rằng ngay cả khi ông rời đi, xét từ góc độ kỹ thuật phần mềm thì các đồng nghiệp của ông rất giỏi và có thể tiếp tục vận hành dự án
  • Từ góc độ chính trị của tổ chức và quỹ, ông cho rằng vẫn còn việc phải làm, và với quan điểm rằng hệ thống nơi tiền lưu chuyển sẽ bị tha hóa, hiện tại vẫn cần một sự lãnh đạo phân cấp mạnh để chống lại ảnh hưởng của tiền bạc
  • Cách một lãnh đạo mạnh duy nhất kiểm soát mọi thứ là không bền vững, vì vậy để bền vững dài hạn thì cần dân chủ, nhưng thách thức là phải thiết kế sao cho hệ thống không bị tha hóa theo thời gian bởi ảnh hưởng của tiền bạc

• Tiêu chí thành công

  • Theo một góc nhìn, Zig đã thành công rồi
  • Zig có nhiều nguồn thu nên độc lập về tài chính với bất kỳ chủ thể đơn lẻ nào, có những người dùng hài lòng và tiếp tục sử dụng, đồng thời phát hành khoảng hai lần mỗi năm và liên tục cải thiện
  • Theo góc nhìn khác, họ muốn được chấp nhận rộng rãi hơn, và một thước đo thành công là mức độ phổ biến ngang với Go và Rust
  • Việc được doanh nghiệp chấp nhận trong thương mại là hữu ích vì có thể nhận được đóng góp từ công ty, nhưng cũng cần cẩn trọng để các khoản đóng góp doanh nghiệp vẫn giữ được tính đa dạng
  • Ông cho rằng nếu tạo ra thứ gì đó hữu ích một cách phổ quát thì nó cũng sẽ hữu ích với doanh nghiệp, và điều đó cũng thể hiện qua việc mọi người đang dùng Zig cho AI

Chính sách AI, công cụ phát triển và tương lai của lập trình

• Chính sách no LLM, no AI contribution

  • Zig áp dụng chính sách nghiêm ngặt no LLM, no AI đối với issue và pull request
  • Họ cho rằng đóng góp bằng AI là “rác rưởi như cũ”, không chỉ vô giá trị mà còn tạo ra giá trị âm vì chiếm mất thời gian review
  • Hiện có hơn 200 pull request đang mở, và thời gian review là nút thắt cổ chai giữa một đội ngũ phát triển nhỏ và nhiều người đóng góp
  • Họ cho rằng các đóng góp do AI tạo ra thường lộ ra một kiểu mẫu: sau vài vòng review, người đóng góp không hiểu nội dung, rồi dán phản hồi review vào chat và nhận lại câu trả lời được “tẩy rửa” như thể là lời của chính họ
  • Lý do cốt lõi để review code và nhận đóng góp là mentorship; mục tiêu là giúp người đóng góp phát triển để sau này trở thành thành viên nòng cốt hoặc người đóng góp có giá trị hơn
  • “contributor poker” là quá trình đánh giá nên đầu tư thời gian hữu hạn vào ai để biến họ thành lập trình viên và người đóng góp tốt hơn
  • Họ cho rằng người dùng AI luôn thuộc nhóm người đóng góp một lần có giá trị đầu tư thấp, không học hỏi và cũng không có khả năng trở thành thành viên nòng cốt
  • Dự án Zig cũng là một dự án giáo dục, và việc cung cấp hướng dẫn cùng đào tạo cho học viên là một phần trong sứ mệnh
  • Nếu chỉ “cho phép AI PR tốt” thì sẽ cần người phán xét, còn cấm toàn diện là chính sách dễ thực thi
  • Họ thừa nhận việc phát hiện nội dung do AI tạo ra không phải lúc nào cũng dễ và có thể một số vẫn đã lọt vào, nhưng khi review nhiều pull request thì đôi khi sẽ trở nên rõ ràng vì phản ứng khi nhận feedback không giống con người

• Giấy phép MIT và việc huấn luyện AI

  • Codebase của Zig dùng giấy phép MIT, và với những người không quen giấy phép phần mềm thì nó gần như tương đương public domain
  • Có thể dùng cho hầu hết mọi mục đích, khi sao chép mã thì phải giữ lại giấy phép, không có bảo hành và cũng không thể quy trách nhiệm cho phía Zig nếu có vấn đề
  • Việc các tập đoàn lớn dùng mã Zig để huấn luyện AI là điều có thể, nhưng Zig lại cấm AI đóng góp cho Zig, và điều này mang tính mỉa mai
  • Họ giữ vững quan điểm rằng Zig là món quà vô điều kiện dành cho thế giới, nên việc dùng nó để huấn luyện AI cũng không sao
  • Về việc LLM có gặp khó khăn với mã Zig hơn so với Python hay JavaScript hay không, ông không trực tiếp thử nhiều, nhưng Mitchell Hashimoto nói rằng mình dùng AI coding rất rộng rãi trong Ghostty
  • Một người có nickname Rocker đã tạo ra công cụ giúp AI hoạt động tốt hơn với Zig và cho biết đã đạt được thành công

• Vibe coding và tương lai của lập trình

  • Việc theo đuổi một dự án trong thời gian dài, học kỹ thuật và đọc về những gì đã giải quyết được sẽ khơi gợi trí tưởng tượng, khiến người ta nghĩ về việc mình có thể tự tạo ra gì, đồng thời truyền đạt điều gì đó và tạo kết nối cảm xúc
  • Ông cho rằng những blog vibe coding kiểu “tôi thử phiên bản này của Claude hay phiên bản kia của OpenAI và nó hoạt động đáng kinh ngạc” không tạo cảm hứng
  • Ông nhấn mạnh rằng tiêu chuẩn chất lượng phần mềm không phải là “thật ngạc nhiên vì nó không có bug”, mà phải là sự hoàn hảo không thỏa hiệp
  • Trong một cuộc gọi riêng với Richard Feldman, ông đã thử vibe coding và cho rằng bản thân công nghệ này về gốc rễ là thú vị
  • Tuy vậy, ông có cảm giác phản đối mạnh với việc khoảng bốn công ty kiểm soát tập trung và nắm toàn quyền đối với mô hình cùng cách nó hoạt động
  • Ông nói mình không muốn chuyển từ cách viết code bằng chính máy tính và điện năng của mình sang cách dùng lập trình mã nguồn đóng trên máy tính của người khác qua mạng theo gói thuê bao hằng tháng
  • Có người đang trả 300 USD mỗi tháng, và ông nói đề nghị như vậy với bản thân mình thì nghe như chuyện điên rồ
  • Ông cho rằng sau 10 năm hay 20 năm nữa, con người vẫn sẽ tiếp tục viết code, và coding vốn vui nên ít nhất sẽ luôn tồn tại như một sở thích
  • Ông cho rằng những ứng dụng tốt nhất trên điện thoại và máy tính là các ứng dụng do con người làm như một sở thích trong thời gian rảnh, và phần mềm tự do/mã nguồn mở cùng mong muốn làm chủ thiết bị của chính mình sẽ không biến mất

• Môi trường biên tập và công cụ refactoring

  • Cần một môi trường làm việc có khả năng phục hồi để vẫn có thể tiếp tục chỉnh sửa code ngay cả khi cú pháp của Zig thay đổi
  • Những công cụ cao cấp như tree-sitter hay language server dựa trên giả định có cây cú pháp ổn định hoặc một ngôn ngữ ổn định, nên khi ngôn ngữ “vỡ” thì chúng cũng có thể vỡ theo
  • Cá nhân ông khi viết Zig dùng terminal và Vim thay vì môi trường quá phức tạp, và Vim chịu đựng thay đổi rất tốt
  • ZLS là viết tắt của Zig language server, là một implementation của Language Server Protocol cho Zig, và là dự án bên thứ ba không do Zig Software Foundation vận hành
  • Website của Zig có khuyến nghị sản phẩm JetBrains, nhưng Andrew Kelley chưa từng dùng sản phẩm JetBrains vì chúng là mã nguồn đóng
  • Trước đây ông đánh giá cao các công cụ refactoring cấp cao mà JetBrains hay Eclipse cung cấp, như trích xuất hàm, sắp xếp lại tham số hàm, hay đổi tên toàn cục
  • Về lâu dài, ông muốn có công cụ refactoring kiểu ngôn ngữ truy vấn có thể thực hiện các thay đổi lớn dựa trên thông tin kiểu và các manh mối khác
  • Với các tác vụ có phạm vi rõ ràng như đổi tên biến, nếu công cụ đáng tin cậy xử lý thì có thể tự tin 100% vào kết quả đến mức không cần tạo commit rồi review lại
  • Nếu yêu cầu cùng tác vụ đó cho công cụ AI thì vẫn phải review code, nên sẽ mất nhiều thời gian hơn và là lựa chọn tệ hơn so với công cụ refactoring đáng tin cậy

Động lực cá nhân và góc nhìn về mã nguồn mở

• Động lực tiếp tục với Zig và những khó khăn

  • Công việc với Zig xuất phát từ động lực yêu máy tính và mong muốn khiến máy tính phục vụ con người
  • Zig được mô tả như một món quà lạc quan rằng một ngôn ngữ lập trình và toolchain xuất sắc sẽ dẫn tới kết quả đó
  • Việc làm hài lòng người dùng và tạo ra trải nghiệm người dùng mạnh mẽ mang lại sự thỏa mãn lớn, và cảm giác làm ra phần mềm tốt được ví với cảm giác một nhạc công có được khi biểu diễn trên sân khấu
  • Thuế và giấy tờ cần thiết để vận hành tổ chức phi lợi nhuận được xem là phần khó khăn nhất
  • Đây là việc bắt buộc để vận hành hợp pháp và nhận các khoản quyên góp lớn mà không gặp vấn đề, nhưng hiện tại Andrew Kelley đang đảm nhiệm việc đó
  • Có ngày anh làm công việc kế toán, có ngày anh lập trình, và anh xem những ngày lập trình là những ngày tốt
  • Việc thay đổi giao diện IO reader / IO writer trong Zig 0.15 là kết quả của quá trình tìm điểm tối ưu, thiết kế API, kiểm thử và so sánh với các ngôn ngữ lập trình khác để tìm ra lời giải mới, nhưng sau đó phải mất 6 tháng để sửa thư viện chuẩn và các dự án trong hệ sinh thái

• Burnout và lời khuyên

  • Burnout được xem là xuất hiện khi bỏ ra rất nhiều nỗ lực nhưng không thấy được nhiều phần thưởng tương xứng với nỗ lực đó
  • Andrew Kelley phần lớn được bảo vệ khỏi burnout vì dù bỏ ra nhiều công sức, anh vẫn nhìn thấy những phần thưởng như người dùng hài lòng, các bản phát hành Zig, ghi chú phát hành và những cải tiến
  • Những công việc mà phần thưởng bị trì hoãn nhiều tháng như thay đổi IO có thể mang lại cảm giác giống burnout, nhưng cuối cùng khi phần thưởng đến thì mọi thứ sẽ khá hơn
  • Với người đang trải qua burnout, anh khuyên trước tiên hãy chú ý tập thể dục, ngủ đủ giấc và ăn uống lành mạnh
  • Nếu ghét công việc mình đang làm hoặc cảm thấy công ty không làm điều gì có giá trị cho thế giới nhưng vẫn phải làm việc chăm chỉ, đó là điều kiện dẫn đến burnout
  • Trong trường hợp đó, tìm công việc khác hoặc chọn con đường khó hơn là tự tạo công việc cho mình như khởi nghiệp là một lựa chọn; và nếu đang làm ở một “tập đoàn vô hồn”, anh khuyên hãy về nhà lúc 5 giờ chiều, làm việc khác và đừng cố gắng quá mức

• Những dự án được ngưỡng mộ và sự đa dạng trình duyệt

  • Dự án đầu tiên được ngưỡng mộ là Linux
  • Thế giới chỉ có các hệ điều hành độc quyền sẽ tệ hơn rất nhiều, và Linux được đánh giá là không chỉ tốt cho các nhà phát triển phần mềm tự do và mã nguồn mở mà còn tốt cho kinh tế vì giúp các quốc gia và doanh nghiệp trên toàn thế giới xây dựng hoạt động kinh doanh miễn phí
  • Dự án thứ hai là Blender, được đánh giá cao vì đây là một dự án mã nguồn mở đồng thời là tổ chức phi lợi nhuận, đang được sử dụng chuyên nghiệp và vẫn cạnh tranh, thậm chí chiến thắng, trước các công ty có rất nhiều tiền và nhân lực phát triển
  • Dự án thứ ba là VLC; anh nhớ lại rằng khi từng đóng góp cho FFmpeg, tổ chức VLC đã chi trả chi phí đi lại tới VideoLAN Dev Days cho một người đã đóng góp cho VLC hoặc các thư viện phụ thuộc của nó
  • Lý do anh dùng Firefox là vì lo ngại về sự đa dạng của trình duyệt
  • Sau khi Microsoft khai tử Internet Explorer, các trình duyệt lớn còn lại chỉ có Chromium, Safari và Firefox, và việc Chromium chiếm phần lớn thị trường được xem là vấn đề đối với web
  • Gần đây anh không hài lòng với Mozilla, và nói rằng dù là tổ chức phi lợi nhuận, nơi này vẫn có nhiều sự mục ruỗng và tạo cảm giác như có những trường hợp không đồng nhất với lợi ích của người dùng
  • Chromium thuộc về Google, Safari thuộc về Apple, Firefox có vẻ đang đi xuống nên thiếu lựa chọn thay thế, và anh cho rằng không biết nên làm gì cho tới khi các dự án trình duyệt mới trưởng thành hơn

• Nếu quay lại năm 2015, liệu có bắt đầu Zig không

  • Anh trả lời rằng dù có quay lại năm 2015 thì chắc chắn vẫn sẽ bắt đầu Zig
  • Ngày anh rời OkCupid và bắt đầu toàn thời gian với Zig là ngày tuyệt vời nhất đời mình, xét theo quỹ đạo cuộc sống từ đó về sau
  • Zig mang lại cho anh cảm giác thỏa mãn sâu sắc, tính độc lập, giá trị bản thân và cảm giác đang đóng góp cho xã hội
  • Anh cảm thấy về cơ bản mình là kiểu người khó làm nhân viên, và để hạnh phúc thì anh phải trở thành người làm chủ của chính mình; sau khi đạt được trạng thái đó, anh mới có được hạnh phúc

[GN⁺]

Ý kiến trên Lobste.rs

• Mong rằng cả những người ngoài Zig Software Foundation cũng sẽ hiểu được đam mê và triết lý mà Andrew và đội ngũ nòng cốt mang theo khi thúc đẩy dự án tiến về phía trước
  Không thể trách JetBrains vì muốn làm cuộc phỏng vấn giật gân hơn để dễ lan truyền, nhưng rốt cuộc những câu hỏi hay nhất lại không phải về Zig đối đầu Rust, mà là về Zig được xây dựng bằng tinh thần phi lợi nhuận, tính bền vững và tình yêu dành cho nó
  Tôi nghĩ Andrew đã cho thế giới thấy rất rõ khía cạnh con người âm ỉ cháy phía sau dự án
  • Thành thật mà nói, tôi cũng không thấy JetBrains thực sự lái theo hướng giật gân gì cả
    Có vẻ video nhắm đến những người tò mò về Zig và những người quan tâm đến cách vận hành dự án nhiều hơn là những người đã dùng Zig khá lâu, và chỉ đơn giản là không né tránh các chủ đề mà nhóm khán giả đó có thể muốn biết
    Người phỏng vấn cũng để lời của Andrew tự bộc lộ thay vì châm lửa thêm, và với kiểu phỏng vấn như thế này thì nó được thực hiện rất chín chắn
    Dù vậy, tôi vẫn bật cười khi thấy những từ được chọn để đưa vào phụ đề; tôi không rõ có bao nhiêu người quan tâm đến Zig nhưng lại không biết Linux hay định nghĩa của abstraction là gì
    Nhìn chung tôi có ấn tượng rất tích cực, cả về cách Zig được giới thiệu lẫn về đội marketing của JetBrains
• Ở khoảng giữa video, Andrew có nhắc đến công cụ tôi làm ra để hỗ trợ sử dụng Zig cùng AI, nên nói luôn cho ai muốn thử thì đó là zigdoc: github.com/rockorager/zigdoc
  Về cơ bản đây là công cụ để xem tài liệu của thư viện chuẩn Zig và các dependency được phát hiện trong build graph ngay từ dòng lệnh
• Tôi thật sự rất thích đoạn ở vài giây cuối video khi Andrew nói rằng anh ấy hạnh phúc
• Cụm từ “lao động vì tình yêu không thỏa hiệp” là rất đúng
  Cách định khung không vội vàng ra mắt 1.0 rất cuốn hút, nhưng Zig cũng khá may mắn khi có những người dùng chấp nhận chịu đựng sự xáo trộn do thay đổi hệ sinh thái
• Ở mảng embedded, trong nhiều năm C đã là công cụ chủ lực
  Không phải C++, mà là C
  Tôi đã phân vân mãi giữa việc chọn Zig hay Rust cho dự án embedded tiếp theo, nhưng giờ tôi có cảm giác “thời điểm đã đến”
  Cuộc phỏng vấn này có thể là cú hích quyết định với tôi, và ở đây có một tông cảm xúc tổng thể mà tôi rất đồng cảm
• Tôi thật sự rất thích câu trả lời về lý do Zig muốn rời khỏi LLVM
  Nó xử lý rất tốt phần thuộc về các tính năng cốt lõi của Zig, nơi mà cả nhóm cần có nhiều quyền kiểm soát hơn