18 điểm bởi GN⁺ 2025-06-12 | 5 bình luận | Chia sẻ qua WhatsApp
  • Bài viết tổng hợp 10 năm kinh nghiệm đưa Rust vào thực tế ngay sau khi Rust 1.0 ra mắt và những kỳ vọng cho 10 năm tiếp theo
  • Ở giai đoạn đầu, việc thích nghi với vấn đề tương thích phiên bản, thời gian build và borrow checker là rất khó khăn
  • Cộng đồng và hệ sinh thái Rust phát triển rất nhanh nhờ “cảm quan lập trình xuất sắc” và văn hóa cộng đồng mạnh mẽ; đặc biệt nổi bật là hiện tượng các lập trình viên giỏi đổ về với Rust
  • Giờ đây, trong các lĩnh vực hệ thống và backend nói chung, Rust đã trở thành một “lựa chọn ổn định”; nhờ sự phát triển của thư viện chuẩn và độ trưởng thành của hệ sinh thái crate, mức độ bất định đã giảm đi rất nhiều
  • Bài viết nêu cụ thể những thách thức còn lại và hướng phát triển của Rust như tốc độ build, tính di động, tính năng const, đồng thời và mở rộng sang nhiều domain khác nhau
  • 10 năm tới được kỳ vọng sẽ mang lại biên dịch nhanh hơn, mở rộng mạnh hơn sang nhiều domain và đổi mới trong trải nghiệm lập trình viên, đồng thời vòng phản hồi tích cực của hệ sinh thái Rust sẽ càng được tăng tốc

  • Vào tháng 6 năm 2015, khoảng một tháng sau khi sự hào hứng quanh việc công bố Rust 1.0 lắng xuống, tác giả đã viết những dòng mã Rust đầu tiên
  • Từ chỗ từng dùng C, Python và JavaScript, sau khi tiếp cận Rust, tác giả không còn muốn quay lại nữa
  • Dựa trên kinh nghiệm tại hai startup dùng Rust và hơn 500.000 dòng mã đã viết, tác giả chia sẻ những suy ngẫm sau 10 năm

Thời kỳ đầu là quãng thời gian gian nan - The early days were painful

  • Khi mới áp dụng Rust, tính tương thích phiên bản giữa crate và compiler cực kỳ bất ổn; ngay cả những bản sửa lỗi nhỏ cũng thường buộc phải cập nhật toàn bộ môi trường build
  • Khái niệm borrow checker và quản lý lifetime gây nhiều khó khăn, đồng thời thời gian biên dịch tăng vọt khi các kiểu phức tạp ngày càng nhiều
  • Mỗi khi cần tính năng mới hay sửa lỗi, gần như phải cập nhật “mọi phiên bản trên đời”, và tốn rất nhiều thời gian để tìm được các phiên bản tương thích

Sự xuất sắc của cộng đồng Rust - The people were and are exceptional

  • Hệ sinh thái Rust đã hình thành một văn hóa lập trình xuất sắc, theo đuổi cách triển khai đơn giản, thanh lịch cùng hiệu năng nhanh và vững chắc
  • So với khi dùng TypeScript hay Python, cấu trúc phụ thuộc của Rust sạch sẽ hơn rất nhiều và quy trình build cũng đơn giản hơn
  • Những đóng góp tận tâm của các tình nguyện viên trong cộng đồng cùng thái độ thận trọng kiểu “không phải lúc này/chưa phải lúc này” đóng vai trò then chốt
  • Tại London, việc tuyển dụng lập trình viên Rust là một lợi thế lớn, và năng lực trung bình của lập trình viên Rust là rất cao

Rust đã trở thành một lựa chọn an toàn (trong một số domain) - Rust has become a safe bet (in some domains)

  • Ở giai đoạn đầu, do thiếu thư viện chuẩn (std), người dùng phải tự viết các hàm tiện ích và patch, nhưng giờ đây phần lớn chức năng đã có sẵn trong std và các crate, khiến mức độ bất định giảm mạnh
  • Khả năng dự đoán của build và nâng cấp, giảm phụ thuộc bên ngoài, tuân thủ semver, cùng sự cải thiện của borrow checker và bộ suy luận đã giúp trải nghiệm dùng Rust ổn định hơn rất nhiều
  • Các crate mới như jiff, polars, tauri được phát triển trên nền những bài học trong quá khứ, còn tokio, hyper, regex đã được kiểm chứng trong thực tế
  • Trước đây việc “phát minh lại bánh xe” gần như là không thể tránh khỏi, còn hiện tại có thể tập trung vào business logic để phát triển ứng dụng hiệu năng cao và vững chắc

Môi trường phát triển mà Rust ngày nay mang lại - Rust today feels like what programming should be

  • Rust là một ngôn ngữ thể hiện sự thấu hiểu với lập trình viên, với hệ thống build gọn gàng và vững chắc, thông báo lỗi và lint hàng đầu, tài liệu xuất sắc, tích hợp IDE tốt cùng CI/kiểm thử hồi quy mạnh mẽ
  • Trong số các dự án mã nguồn mở quy mô lớn, hiếm có ngôn ngữ nào thân thiện với lập trình viên như Rust
  • “Đầu tư dài hạn” từ vô số cộng đồng và người đóng góp là yếu tố cốt lõi tạo nên Rust của ngày hôm nay

Kỳ vọng cho 10 năm tới - What I’m looking forward to over the next 10 years

Build đơn giản hơn và nhanh hơn - Simpler and faster builds

  • Tác giả kỳ vọng công việc thay thế các phụ thuộc phức tạp hoặc chậm bằng những thành phần đơn giản và nhanh hơn sẽ tiếp tục được đẩy mạnh
  • Có thể kỳ vọng vào các thử nghiệm mới như thư viện chuẩn thuần Rust, giảm phụ thuộc vào linker và thư viện hệ thống, mã hóa thuần Rust, BTreeMap bền vững, hay game engine viết bằng Rust
  • Tại Tably, trong vài tháng gần đây, tốc độ biên dịch frontend/backend đã cải thiện 60%

Tăng tính di động và giảm thiểu #[cfg()] - Improved portability and less #[cfg()]

  • Việc kiểm thử trên nhiều tổ hợp nền tảng/tùy chọn rất khó, và #[cfg()] gây ra mã chưa được kiểm chứng, tài liệu không hoàn chỉnh và cả vấn đề với IDE
  • Nếu có thể đưa #[cfg()] vào trong trait system, tác giả kỳ vọng sẽ đạt được đảm bảo theo nền tảng/tùy chọn, giảm thiểu tái biên dịch, có MIR cache và CI nhanh hơn

Mong mọi mã đều trở thành const - Everything being const

  • Thực hiện nhiều công việc hơn ngay tại thời điểm biên dịch có thể giảm mức độ phụ thuộc vào macro/build script, đồng thời ngăn chặn lỗi runtime từ sớm
  • Dù hiện tại còn nhiều giới hạn, Rust trong tương lai được kỳ vọng hướng tới trạng thái “mọi mã đều có thể chạy trong const context”

Đơn giản hóa đồng thời - Simpler concurrency

  • Mô hình async hiện tại của Rust có độ phức tạp cao, với các vấn đề như static bound, cancellation-safety, giới hạn trait... gây khó khăn trong thực tế
  • Cần theo đuổi một mô hình đồng thời đơn giản ở cấp độ ngôn ngữ như user-space green thread (libgreen) trước đây

Cạnh tranh tốt hơn ở nhiều domain hơn - Excelling in more domains

  • Lĩnh vực ứng dụng Rust trong trình duyệt web (đặc biệt là wasm/rustwasm) vẫn còn chưa được khai phá đầy đủ, và vẫn còn nhiều bài toán như stack trace đa trình duyệt
    • Các framework như leptos, sycamore vẫn tiếp tục phát triển, nhưng vẫn còn nhiều chỗ để cải thiện
  • Tác giả cũng kỳ vọng Rust sẽ tiếp tục cải thiện ở các domain mà nó vẫn chưa thực sự bứt phá hoàn toàn, như rapid prototyping, business logic, GUI, machine learning và phát triển game

Kết luận

  • Tương lai tăng trưởng của Rust là rất rõ ràng và đầy hy vọng
  • Càng được áp dụng rộng rãi, năng lực kỹ thuật và kiểm thử càng tăng; từ đó tạo ra một vòng tuần hoàn tích cực dẫn tới mức độ chấp nhận rộng hơn và nhiều cải tiến hơn
  • 10 năm sắp tới sẽ hiện thực hóa biên dịch nhanh hơn, ứng dụng trong nhiều lĩnh vực hơn và trải nghiệm phát triển mượt mà hơn
  • Tác giả mong chờ 10 năm mới của Rust

5 bình luận

 
ndrgrd 2025-06-12

Rust thì tốt ở nhiều mặt, nhưng ngôn ngữ này đòi hỏi quá nhiều thứ.
Khi dùng Rust, đôi lúc tôi có cảm giác mình đang nghiên cứu chính ngôn ngữ Rust hơn là tập trung vào việc hiện thực hóa ý tưởng.

Có lẽ sẽ không thành vấn đề lớn khi chuyển một dự án đã được xây dựng sẵn, chẳng hạn như chuyển từ C++,
nhưng tôi không chắc nó có thật sự tiện để dùng khi hiện thực hóa những ý tưởng mới hay không.

 
felizgeek 2025-06-12

Tôi khuyên dùng Python để tạo nguyên mẫu.

 
ndrgrd 2025-06-12

Cá nhân tôi thích hệ thống kiểu, nên hiện tại đang dùng C#, và tôi nghĩ chừng này là đủ khiến tôi hài lòng.

 
codemasterkimc 2025-06-12

Cá nhân mình nghĩ nếu xét đến môi trường Trái Đất thì là RUST. Code Spring legacy chuyển sang Axum thôi!!!

 
GN⁺ 2025-06-12
Ý kiến Hacker News
  • Đây là một bài viết rất tích cực và cũng khá khớp với trải nghiệm của tôi. Tuy vậy, nếu phải nêu ra một triển vọng u ám thì sẽ là điểm này:
    "async có chi phí độ phức tạp tương đối cao do các ràng buộc static bound, cancellation safety, cùng những hạn chế liên quan đến trait và dyn. Hiện tại chưa thấy dấu hiệu nào cho thấy vấn đề này sẽ được giải quyết. Sự phân tách giữa primitive đồng bộ/bất đồng bộ và đặc tính riêng của hệ sinh thái làm tăng async tax (chi phí phát sinh). Các giải pháp dựa trên Effects cũng không mấy hứa hẹn."
    "Rust trước 1.0 từng có một giải pháp là libgreen. Nó triển khai đồng thời trong không gian người dùng mà không có bifurcation (phân tách), nhưng do chi phí về hiệu năng, tính khả chuyển và bảo trì quá lớn nên cuối cùng đã bị loại bỏ. Tôi nghĩ nếu có đủ năng lực kỹ thuật thì vẫn đáng để cân nhắc lại. Một ngày nào đó tôi muốn làm một PoC zero-cost wrapping std::{fs, net}fiber::{spawn, select} bằng generator"
    • Tôi cho rằng tranh luận kiểu "'static bound làm tăng độ phức tạp" chỉ là một lựa chọn thiết kế của runtime async Tokio, chứ khó xem đó là thiết kế của toàn bộ Rust. Runtime async Embassy vẫn hoạt động mà không cần ràng buộc như vậy, nhưng bù lại phải tự quản lý pinning. Thực ra 'static bound là để giảm độ phức tạp
  • Với tư cách là người bắt đầu mê Rust và học nó từ cuối năm 2022, tôi luôn thấy thú vị khi đọc trải nghiệm của những người học ngôn ngữ này từ thời còn khó khăn hơn, như năm 2015. Tôi cảm thấy may mắn vì được học Rust ở thời điểm nó đã trưởng thành hơn, nên đường cong học tập vốn đã dốc cũng phần nào bớt gắt hơn. Dạo này tôi có cảm giác mình đang trải lại những câu chuyện thời kỳ đầu của Rust với Zig. Zig có vẻ đang ở giai đoạn tương tự Rust thuở ban đầu. Dù vậy, tôi vẫn đang dùng nó rất vui
    • Có một văn hóa rất mạnh là "hãy để lại mọi thứ ở trạng thái tốt hơn lúc bạn tìm thấy". Nếu công cụ hay ngôn ngữ khiến bạn bối rối thì đó không phải lỗi của người dùng. Nếu tôi đã bị nhầm lẫn thì người khác cũng sẽ như vậy, nên cứ mỗi lần phát hiện ra là cải thiện nó sẽ mang lại lợi ích lớn cho mọi người. Câu tục ngữ rằng thời điểm tốt thứ hai để trồng cây là hôm nay rất đúng ở đây. Nhờ văn hóa này mà một người từng thử Rust rồi bỏ cuộc trước đây có thể chỉ sau 1 năm sẽ có trải nghiệm tốt hơn rất nhiều. Vì thế lời khuyên tốt nhất tôi từng dành cho người mới học Rust là "hãy đợi 6 tháng nữa"
    • Nếu một ngôn ngữ được các big tech như MSFT, Google hay các dự án mã nguồn mở lớn như Linux chấp nhận, thì đó đã là bằng chứng hệ sinh thái đủ trưởng thành. Nhưng với Zig thì tôi chưa có được sự tự tin đó, vì nó vẫn chưa cho thấy sự thay đổi nào thật sự lớn so với các công cụ hiện có
  • Tôi có cảm giác Rust khuyến khích lập trình hàm. Ban đầu tôi định viết một parser thay đổi trạng thái nội bộ sau mỗi lần advance, nhưng vì tính khả biến và hệ thống borrowing mà quá vất vả nên cuối cùng phải chuyển sang parser stateless. Tôi đổi từ việc sửa chỉ số bên trong sang cấu trúc trả về chỉ số. Tôi tò mò không biết chuyện cách làm cũ không còn hiệu quả và phải tiếp cận lại từ đầu trong Rust có phổ biến không
    • Tôi cũng có trải nghiệm tương tự. Với các trường hợp đơn giản thì kiểu mutable, mệnh lệnh vẫn ổn, nhưng khi độ phức tạp tăng lên thì tôi chuyển dần sang phong cách hàm và tránh thay đổi trạng thái nhiều nhất có thể. Do borrow checker và lifetime mà các pattern truyền thống trở nên khó áp dụng, nên tự nhiên sẽ đi theo hướng hàm hơn. Nếu chưa quen triển khai theo kiểu hàm thì có thể sẽ thấy khó, nhưng bù lại compiler sẽ khiến bạn hài lòng hơn
  • Async/await là lý do duy nhất khiến tôi không dùng Rust
    • Thật ra tôi nghĩ async/await là một trong những lý do lớn nhất để dùng Rust. Nó làm cho các pattern đồng thời trở nên đơn giản hơn rất nhiều. Ban đầu tôi cũng có cảm giác như một loại dịch bệnh ác tính, khiến mọi đoạn mã cuối cùng đều phải thành async, nhưng khi đã biết cách tương tác với mã async thì mọi thứ trở nên dễ chịu hơn. Thường thì spawn, spawn_blocking, futures::stream chiếm 90% trường hợp sử dụng, và nếu đặt ra "ranh giới" phù hợp thì async cũng không cần lan truyền khắp nơi
    • Tôi cũng phần nào hiểu điều đó. Nhưng với tôi thì async/await trong Rust rất hợp, đến mức trở thành lý do lớn nhất để dùng nó. Tôi thích cả cú pháp và cũng không quá bận tâm đến vấn đề function colouring. Đặc biệt khi dùng tokio, hầu như đều có sẵn phiên bản async của các hàm tiêu chuẩn cần thiết nên cảm giác lời giải rất trơn tru. Điều này có thể tạo ra rào cản với một số người, nhưng tôi vẫn hài lòng vì viết chương trình đồng thời dễ hơn nhiều mà hiệu năng cũng ổn. Những thứ như cancellation đôi lúc vẫn làm tôi loay hoay, nhưng tôi nghĩ đó là do trình độ của mình
    • Bây giờ chẳng phải đã có đủ hết rồi sao?