Viết lại Rust

Viết lại Rust

• Ngôn ngữ lập trình Rust mang lại cảm giác như một sản phẩm thế hệ đầu tiên
• Sức hấp dẫn ban đầu của Rust: kiểu đại số, an toàn bộ nhớ, không suy giảm hiệu năng, trình quản lý gói hiện đại
• Sau 4 năm sử dụng, Rust không phải lúc nào cũng hoàn hảo
• Sự phát triển của ngôn ngữ đã chậm lại rất nhiều
• Nhiều tính năng không ổn định chưa được đưa vào Rust ổn định

Một ngôn ngữ tuyệt vời

• Muốn fork trình biên dịch Rust và tạo một edition mới tên là "seph"
• Có thể giữ lại các tính năng hiện có của Rust đồng thời bổ sung tính năng mới

Trait của hàm (hiệu ứng)

• Rust định nghĩa trait cho struct, nhưng cũng cần định nghĩa trait cho hàm
• Có thể biểu thị nhiều đặc tính khác nhau của hàm
  • Hàm có gây panic hay không
  • Hàm có kích thước stack cố định hay không
  • Hàm chạy đến hết hay dừng chờ ở giữa
  • Hàm có thuần hay không
  • Hàm có thực thi mã unsafe hay không
  • Hàm có đảm bảo kết thúc hay không

Tính năng thời điểm biên dịch

• Nhiều dự án Rust sử dụng rất nhiều crate bên thứ ba
• Những crate này làm tăng rủi ro chuỗi cung ứng
• Đề xuất thêm tính năng buộc phải cho phép rõ ràng các lời gọi hàm nhạy cảm về bảo mật
• Muốn gọi các chức năng như fs_write thì phải cho phép một cách tường minh

Pin, Move và mượn struct

• Pin là một cách vá phức tạp để giải quyết vấn đề của borrow checker trong Rust
• Thay vì Pin, dùng marker trait Move sẽ hợp lý hơn
• Đề xuất thêm cú pháp để có thể đánh dấu field của struct đang ở trạng thái được mượn
• Đề xuất đưa vào marker trait Move và trait Mover

Thời điểm biên dịch

• Đưa tính năng comptime của Zig vào để thay thế ngôn ngữ macro của Rust
• Thêm một trình thông dịch nhỏ có thể chạy mã ở thời điểm biên dịch
• Dùng chính Rust thay cho ngôn ngữ macro của Rust

Các chỉnh sửa nhỏ

• Sửa impl<T: Copy> for Range<T>
• Sửa derive với associated type
• Hỗ trợ toán tử AND logic trong biểu thức if-let
• Cải thiện khả năng sử dụng của con trỏ thô
• Thêm đối số Allocator cho mọi kiểu collection dựng sẵn

Suy nghĩ kết thúc

• Tính năng bất đồng bộ cũng cần được cải thiện, nhưng cần một bài viết riêng
• Phần lớn các thay đổi này không tương thích với Rust hiện tại
• Có thể sẽ cần một edition Rust mới
• Đang cân nhắc fork trực tiếp trình biên dịch thay vì tiếp tục mệt mỏi với quy trình RFC trên GitHub

Tóm tắt của GN⁺

• Rust không phải lúc nào cũng hoàn hảo dù có sức hấp dẫn ban đầu
• Sự phát triển của ngôn ngữ đang chậm lại và nhiều tính năng không ổn định chưa vào được Rust ổn định
• Có nhiều đề xuất như trait cho hàm, tính năng thời điểm biên dịch, và cải tiến Pin cùng Move
• Những đề xuất này có thể cải thiện đáng kể khả năng sử dụng của Rust
• Một ngôn ngữ khác có các tính năng tương tự là Zig

[GN⁺]

Ý kiến trên Hacker News

• Ý kiến về quy trình Rust RFC

  • Việc nhóm nòng cốt của Rust khiến cho việc bổ sung tính năng mới trở nên khó khăn là một quyết định đúng đắn để duy trì tính nhất quán và khả năng dự đoán của ngôn ngữ
  • Trường hợp của Swift cho thấy việc đưa vào quá nhiều tính năng mới đã khiến ngôn ngữ trở nên phức tạp, và cuối cùng người viết đã từ bỏ Swift
  • Điều quan trọng là giữ cho Rust cô đọng nhất có thể

• Vấn đề phụ thuộc của Rust

  • Lấy ví dụ crate Cargo-watch: đây là một ứng dụng theo dõi tệp đơn giản, nhưng do phụ thuộc mà số dòng mã lên tới 4 triệu dòng

• Tình trạng hiện tại của Rust

  • Rust hiện đã ở giai đoạn "làm việc để được chấp nhận rộng rãi"
  • Việc phát triển tính năng chậm là hiện tượng tự nhiên và lành mạnh, và các lựa chọn thiết kế sai còn có thể gây hại lớn hơn
  • Sức hấp dẫn của Rust không nằm ở tính năng mới mà ở chỗ đây là một ngôn ngữ an toàn bộ nhớ, sẵn sàng cho sản xuất, và không có GC

• Ý kiến về việc viết lại Rust

  • Việc viết lại Rust bằng Rust trông giống như một trò đùa meta-châm biếm

• Bất mãn với quá trình ra quyết định của Rust

  • Có sự bất mãn với quá trình ra quyết định chậm chạp, nhưng đây là vấn đề về con người và thời gian hơn là vấn đề kỹ thuật
  • Một số tính năng cũ đã bị đình trệ, nhưng nhiều tính năng sẽ không được ổn định hóa

• Bình luận của Josh Triplett

  • Ông chỉ ra rằng một ví dụ cụ thể là không chính xác và chia sẻ liên kết liên quan

• Ý kiến về độ phức tạp của Rust

  • Rust đã có rất nhiều tính năng, nhưng vẫn có những người muốn thêm nhiều tính năng hơn
  • Zig đơn giản hơn, nhanh hơn và ít drama cộng đồng hơn

• Ý kiến về tốc độ của Rust

  • Khi dự án trưởng thành hơn, cần rất nhiều nỗ lực để tinh chỉnh các tính năng hiện có
  • Việc hợp tác giữa các nhóm đã trở nên khó khăn hơn, và có các mục tiêu dự án nhằm cải thiện điều này

• Ý kiến về việc cải thiện Mutex

  • Đã có rất nhiều nỗ lực nhằm cải thiện các primitive đồng bộ hóa của Rust
  • Các tính năng như hàm bất đồng bộ đã được bổ sung, và đây trở thành nền tảng để triển khai các tính năng phức tạp hơn

• Ý kiến về tốc độ phát triển tính năng của Rust

  • Có những người phàn nàn rằng ngôn ngữ đang phát triển quá nhanh hoặc quá chậm
  • Một số tính năng tiến triển chậm, nhưng vẫn đang có rất nhiều hoạt động diễn ra

• Ý kiến về thiết kế tính năng của Rust

  • Những tính năng như function trait gần đây đã có các đợt khám phá thiết kế lớn
  • Các tính năng compile-time không thể được giải quyết ở cấp độ ngôn ngữ, và những giải pháp như WebAssembly có khả năng thực tế hơn

• Vấn đề borrow checker của Rust

  • Việc hiểu các cấu trúc tự tham chiếu là một vấn đề cực kỳ khó
  • Người ta đã biết cách hỗ trợ partial borrow, nhưng vấn đề là làm sao phơi bày điều đó ra hệ thống kiểu

• Các tính năng compile-time của Rust

  • Đã có RFC được viết ra để làm cho các quy tắc macro mạnh mẽ hơn
  • Cần thêm nhiều công việc hơn cho việc phân tích cú pháp theo hướng lập trình

• Các tính năng không ổn định của Rust

  • Có rất nhiều tính năng không ổn định và cần phải được sắp xếp lại

• Ý kiến về tốc độ phát triển của Rust

  • Việc Mozilla rút lui đã làm dự án chậm lại, nhưng như vậy vẫn tốt hơn là đi sai hướng