Sau nhiều năm tranh luận gay gắt, hạ tầng cho phép viết mã Rust bên trong nhân Linux đã được hợp nhất, và những trình điều khiển đầu tiên viết bằng Rust bắt đầu xuất hiện. Nghe có vẻ là một chi tiết kỹ thuật nhỏ, nhưng đây là lần đầu tiên trong ba mươi năm một ngôn ngữ thứ hai được chấp nhận vào một dự án suốt lịch sử chỉ dùng C. Với một cộng đồng nổi tiếng bảo thủ về công cụ, đó là một thay đổi lớn — và lý do đằng sau đáng để hiểu.
Lý do kỹ thuật
Thống kê từ nhiều dự án lớn viết bằng C và C++ đều hội tụ về cùng một con số đáng giật mình: khoảng hai phần ba lỗ hổng bảo mật nghiêm trọng bắt nguồn từ lỗi bộ nhớ — truy cập ngoài biên mảng, dùng vùng nhớ đã giải phóng, giải phóng hai lần. Không phải lỗi logic, không phải thuật toán sai, mà là quản lý bộ nhớ sai.
Điểm mấu chốt: đây không phải vấn đề trình độ. Những dự án này quy tụ một số lập trình viên giỏi nhất thế giới, có quy trình rà soát nghiêm ngặt, và vẫn mắc đều đặn suốt hàng chục năm. Lý do đơn giản là con người không có khả năng theo dõi chính xác vòng đời của từng vùng nhớ trải trên hàng triệu dòng mã — đó là giới hạn nhận thức, không phải giới hạn cố gắng. Rust dời việc theo dõi đó từ đầu người sang cho trình biên dịch, nơi nó được làm không mệt mỏi và không sót.
Vì sao lại bắt đầu từ trình điều khiển
Trình điều khiển là lựa chọn hợp lý để thử ngôn ngữ mới vì chúng hội đủ ba điều kiện: chiếm phần lớn khối lượng mã của nhân, được viết bởi rất nhiều bên khác nhau với chất lượng không đồng đều, mà lại chạy với toàn quyền trong nhân. Nói cách khác, đây là nơi rủi ro tập trung cao nhất — đúng chỗ mà sự an toàn bộ nhớ của Rust mang lại lợi ích lớn nhất — và cũng là nơi mã mới liên tục được sinh ra, nên không cần viết lại thứ đã chạy tốt.
Những khó khăn thật
- Nhân có mô hình bộ nhớ và các quy ước riêng đã tồn tại từ trước Rust; phải bọc chúng lại thành những lớp an toàn để mã Rust dùng được — công việc tỉ mỉ và rất tốn công.
- Người bảo trì giờ phải đọc hiểu được cả hai ngôn ngữ, làm tăng gánh nặng cho một nhóm người vốn đã quá tải.
- Giao diện nội bộ của nhân thay đổi liên tục — đó là văn hoá của dự án — và mỗi lần đổi lại phải cập nhật cả lớp bọc Rust tương ứng, một chi phí bảo trì thường trực.
Kỳ vọng thực tế
Rust sẽ không thay thế C trong nhân Linux, và cũng không ai nghiêm túc đặt mục tiêu đó — hàng chục triệu dòng C đang chạy tốt sẽ ở nguyên chỗ của chúng. Điều thực tế hơn nhiều là Rust chiếm dần những phần mới viết, nơi lợi ích an toàn lớn nhất và chi phí chuyển đổi gần bằng không. Ý nghĩa lâu dài không nằm ở Linux cụ thể, mà ở tín hiệu nó gửi đi: ngay cả thành trì bảo thủ nhất của lập trình hệ thống cũng đã kết luận rằng lỗi bộ nhớ là một vấn đề đáng đổi cả công cụ để giải quyết.
Thảo luận