Một cuộc thảo luận gần đây về các struct có thể thay đổi kích thước trong Zig đã bất ngờ châm ngòi cho một cuộc tranh luận sôi nổi trong cộng đồng về các quyết định thiết kế cơ bản của ngôn ngữ này, đặc biệt là xung quanh việc phân bổ stack và Variable Length Arrays (VLAs). Điều bắt đầu như một bài viết kỹ thuật đề xuất một cấu trúc dữ liệu mới đã phát triển thành một cuộc trò chuyện rộng hơn về chiến lược async I/O sắp tới của Zig và những tác động của nó đối với các nhà phát triển.
Ràng buộc Async I/O thay đổi mọi thứ
Tranh cãi tập trung xung quanh quyết định của Zig loại trừ VLAs khỏi đặc tả ngôn ngữ. Andy Kelley , người tạo ra Zig , tiết lộ rằng hạn chế này là rất quan trọng cho việc triển khai async I/O sắp tới của ngôn ngữ. Trình biên dịch cần tính toán mức sử dụng stack giới hạn trên cho các lệnh gọi hàm, điều này trở nên không thể thực hiện được với việc phân bổ stack được biết tại runtime. Lựa chọn thiết kế này có những hệ quả sâu rộng mở rộng ra ngoài việc quản lý bộ nhớ đơn giản.
Chiến lược async I/O cũng tác động đến cách thức hoạt động của đệ quy trong Zig . Vì tất cả mã tồn tại trong một đơn vị biên dịch, trình biên dịch có thể phân tích toàn bộ đồ thị gọi hàm. Khi nó gặp các chu kỳ (đệ quy), nó kích hoạt một lỗi. Các nhà phát triển phải sử dụng các builtin của ngôn ngữ để gọi các hàm với các stack khác nhau, thường được lấy thông qua phân bổ heap.
Lưu ý: VLAs (Variable Length Arrays) là các mảng có kích thước được xác định tại runtime thay vì compile time.
Các ràng buộc về phân bổ Stack của Zig:
- Không có Variable Length Arrays (VLAs) trong đặc tả ngôn ngữ
- Trình biên dịch phải tính toán giới hạn trên của việc sử dụng stack cho async I/O
- Đệ quy gây ra lỗi biên dịch trong đồ thị gọi hàm
- Các nhà phát triển phải sử dụng builtin của ngôn ngữ cho các hàm đệ quy với các stack khác nhau
- Tất cả mã nguồn tồn tại trong một đơn vị biên dịch duy nhất để phân tích hoàn chỉnh
Phản ứng của cộng đồng về sự đánh đổi hiệu suất
Nhiều nhà phát triển đang đặt câu hỏi liệu lợi ích async I/O có biện minh cho chi phí hiệu suất hay không. Những người chỉ trích cho rằng việc luôn phân bổ cho các tình huống tệ nhất sẽ lãng phí bộ nhớ và làm tổn hại hiệu suất cache. Họ đề xuất các phương án thay thế như phân bổ giới hạn tại compile-time có thể cung cấp tính địa phương bộ nhớ tốt hơn trong khi duy trì khả năng tính toán giới hạn stack của trình biên dịch.
Cuộc tranh luận đã tiết lộ một căng thẳng cơ bản giữa tính an toàn và hiệu suất. Một số thành viên cộng đồng cảm thấy rằng cách tiếp cận của Zig hy sinh quá nhiều tính linh hoạt cho những lợi ích lý thuyết mà nhiều nhà phát triển có thể không bao giờ sử dụng. Những người khác bảo vệ quyết định này là cần thiết để tạo ra một ngôn ngữ có thể dự đoán và an toàn hơn.
Mối quan ngại của cộng đồng:
- Tác động hiệu suất từ việc cấp phát bộ nhớ trong trường hợp xấu nhất
- Giảm tính địa phương của bộ nhớ ảnh hưởng đến hiệu suất cache
- Khả năng tương tác hạn chế với các thư viện C và con trỏ hàm
- Thách thức đối với biên dịch phân tán và tăng dần
- Mất khả năng kiểm soát cấp độ thấp so với các ngôn ngữ lập trình hệ thống khác
Các cách tiếp cận thay thế và giải pháp thay thế
Bất chấp các hạn chế, các nhà phát triển đã tìm ra những giải pháp sáng tạo. Cộng đồng đã khám phá việc sử dụng các kiểu opaque và quản lý bộ nhớ thủ công để đạt được chức năng tương tự. Một số đề xuất sử dụng các buffer được phân bổ stack làm kho lưu trữ hỗ trợ, cho phép các nhà phát triển xử lý lỗi một cách khéo léo thay vì rủi ro gặp sự cố tràn stack.
Cuộc thảo luận cũng đã làm nổi bật cách những ràng buộc này ảnh hưởng đến khả năng tương tác với các thư viện C và con trỏ hàm. Yêu cầu đơn vị biên dịch duy nhất tạo ra thách thức cho việc biên dịch phân tán và xây dựng tăng dần, mặc dù các nhà phát triển lưu ý rằng caching và song song hóa có thể giảm thiểu một số vấn đề này.
Các Giải Pháp Thay Thế và Cách Khắc Phục Được Đề Xuất:
- Sử dụng các kiểu dữ liệu không minh bạch với quản lý bộ nhớ thủ công
- Bộ đệm được cấp phát trên stack làm kho lưu trữ hỗ trợ với xử lý lỗi
- Cấp phát có giới hạn tại thời điểm biên dịch với các tham số giới hạn trên
- Triển khai đệ quy thủ công trong các hàm đơn lẻ
- Cấp phát heap để phá vỡ các chu trình đệ quy
Nhìn về phía trước
Cuộc tranh luận phản ánh những câu hỏi rộng hơn về triết lý thiết kế ngôn ngữ. Trong khi một số nhà phát triển đánh giá cao cách tiếp cận có chủ kiến của Zig về tính an toàn và khả năng dự đoán, những người khác lo lắng về việc mất đi sự kiểm soát cấp thấp thu hút họ đến các ngôn ngữ lập trình hệ thống. Cộng đồng tiếp tục khám phá các cách để làm việc trong những ràng buộc này trong khi duy trì các đặc tính hiệu suất làm cho Zig hấp dẫn.
Khi chiến lược async I/O của Zig phát triển, cộng đồng có thể sẽ tiếp tục tinh chỉnh những cách tiếp cận này và tìm ra những cách mới để cân bằng tính an toàn, hiệu suất và tính ergonomic của nhà phát triển. Cuộc thảo luận thể hiện cả niềm đam mê của cộng đồng Zig và những sự đánh đổi phức tạp liên quan đến thiết kế ngôn ngữ hiện đại.
Tham khảo: Resizable structs in Zig