Đánh giá ngôn ngữ lập trình Rust: Có đáng học không?

Hỏi hai lập trình viên Rust giàu kinh nghiệm xem học Rust có đáng công sức không, và bạn có thể nhận được hai câu trả lời hoàn toàn trái ngược. Một người có thể nói nó chẳng giúp gì cho sự nghiệp của họ; người kia có thể gọi đó là một trong những quyết định kỹ thuật tốt nhất họ từng đưa ra. Cả hai đều có thể đúng.

Sự mâu thuẫn đó chính là nơi câu hỏi “Rust có đáng học không” thực sự nằm, và đó là lý do một câu “có” chung chung chẳng giúp gì cho bạn. Rust là ngôn ngữ biên dịch mà tập con an toàn của nó áp đặt các quy tắc an toàn bộ nhớ ngay lúc biên dịch, không cần garbage collector khi chạy.

Vì vậy tôi sẽ đưa ra một câu trả lời dứt khoát, nêu rõ điều kiện mà nó phụ thuộc vào, và cho bạn thấy điều kiện đó tốn gì.

Phiên bản ngắn gọn

Rust đáng học nếu bạn đang xây dựng thứ gì đó tồn tại lâu dài, nơi việc trình biên dịch bắt được cả một lớp lỗi là đáng để trả giá. Nó là lựa chọn sai nếu bạn cần ra mắt một ứng dụng CRUD trong tháng này, đang học lập trình, hoặc đang đếm tin tuyển dụng. 4 trên 5, bị trừ điểm vì cái giá phải trả trước khi nó sinh lời.

• Thứ bạn mua được: trong Rust an toàn, các quy tắc ownership và borrowing biến lỗi use-after-free, double-free, tham chiếu không hợp lệ và data race thành lỗi lúc biên dịch thay vì sự cố trên production. Đó là toàn bộ lời chào mời, và đó là một lời chào mời tốt.
• Cái giá bạn trả: trình biên dịch bắt bạn viết ra những quyết định về bộ nhớ mà ngôn ngữ hiện tại của bạn đưa ra một cách âm thầm, và lúc đầu cảm giác như công cụ đang làm khó bạn.
• Câu hỏi về độ bền vững đã có lời giải. Các maintainer kernel đã kết thúc thử nghiệm Rust tại Maintainers Summit tháng 12 năm 2025, và nhãn “thử nghiệm” được gỡ bỏ trong Linux 7.0.
• Câu hỏi về độ thịnh hành thì chưa, và đó là một câu hỏi khác. Rust đứng ở #10 trong chỉ số TIOBE tháng 9 năm 2026, tăng từ #18 một năm trước đó.
• Dịch vụ Rust thử nghiệm của tôi cần nhiều bộ nhớ để biên dịch hơn hẳn để chạy: đỉnh gần 1 GB khi build và chỉ khoảng 3,5 MB khi chạy không tải.
• Phù hợp với bạn nếu bạn đã ra sản phẩm bằng một ngôn ngữ khác và đang xây dựng thứ mà một lỗi bộ nhớ sẽ rất tốn kém, hoặc bạn làm việc gần phần mềm hệ thống. Không phù hợp với bạn nếu bạn đang chạy deadline, bắt đầu từ con số không, hoặc đang tìm ngôn ngữ có nhiều vị trí tuyển dụng nhất.

Cách bài đánh giá này được thực hiện: các con số về build và runtime ở đây là của tôi. Tôi cài Rust 1.98.1, viết một dịch vụ web Axum nhỏ, và đo xem biên dịch và chạy nó cần những gì. Việc đó chạy trong một container sandbox, không phải trên phần cứng chuyên dụng, và chỉ là một dự án, nên hãy xem các con số là một điểm dữ liệu chứ không phải quy luật. Mọi thứ khác đến từ nguồn gốc hoặc nguồn có thẩm quyền: bản vá kernel và bài tường thuật của LWN về nó, các bài đăng bảo mật Android của Google, chỉ số của chính TIOBE (kèm bình luận tháng 4 qua bản ghi của Slashdot), Phoronix về merge window của Linux 7.0, hồ sơ CVE của kernel Linux cho lỗ hổng Binder, tuyên bố của chính Canonical, và khảo sát Stack Overflow 2025. Tôi đã đọc bản vá kernel. Tôi không kiểm toán mã Rust trong kernel. Và tôi không phải người đã viết Rust nhiều năm, nên ở những chỗ bài đánh giá này nhận xét về bản thân ngôn ngữ, nó dựa vào những người thực hành đã viết nhiều năm, và nêu tên họ.

Trình biên dịch mua được gì cho bạn

Đưa cho hai thread một tham chiếu mutable tới cùng một vector trong Rust và code sẽ không biên dịch. Không phải cảnh báo. Không phải một lint bạn có thể tắt khi chạy deadline. Nó không build được. Sự từ chối đó là thứ bạn mua được trong Rust an toàn: lỗi use-after-free, double-free, tham chiếu không hợp lệ và data race bị đẩy thành lỗi biên dịch thay vì sự cố trên production. Lối thoát hiểm của Rust (unsafe) có thể vượt qua một số bảo đảm đó, nên đây không phải lời hứa tuyệt đối cho mọi codebase Rust.

Ownership nghĩa là mỗi giá trị có đúng một chủ sở hữu chịu trách nhiệm giải phóng nó. Borrowing nghĩa là bạn có thể cho mượn tham chiếu, nhưng trình biên dịch theo dõi lifetime của chúng và không để một tham chiếu sống lâu hơn thứ nó trỏ tới, hay để một borrow mutable tồn tại cùng lúc với bất kỳ borrow nào khác. Trong Rust an toàn, lỗi use-after-free, double-free, tham chiếu không hợp lệ và data race bị hệ thống ownership và kiểu bắt được trước khi chương trình chạy.

Không có garbage collector, và đó là nửa còn lại của thỏa thuận. Vì ownership đã nói rõ ai giải phóng cái gì và khi nào, không có gì cần phải quét heap của bạn lúc chạy. Bạn ra một binary không có bộ thu gom nào bên trong, và không phải chịu những khoảng dừng mà bạn phải tinh chỉnh xoay quanh.

Cái giá xuất hiện ở đúng chỗ với sự bảo đảm. Mọi quyết định bộ nhớ mà ngôn ngữ hiện tại âm thầm đưa ra thay bạn, Rust đều yêu cầu bạn viết ra: ai sở hữu cái này, tham chiếu kia sống bao lâu, có thứ gì khác nhìn thấy nó không, và nó có vượt qua ranh giới thread không. Trình biên dịch không làm khó bạn. Nó từ chối đoán.

Vậy: đây là lý do bất kỳ ai cũng chịu trả cái giá Rust đòi hỏi, và tôi nghĩ lý do đó đứng vững. Nếu lớp lỗi mà nó loại bỏ không phải lớp lỗi bạn lo ngại, phần còn lại của bài đánh giá này nhiều khả năng sẽ không đổi ý bạn.

Rust vẫn còn là thử nghiệm, hay giờ đã là hạ tầng production?

Rust thôi là thử nghiệm vào tháng 12 năm 2025, và người kết thúc nó chính là các maintainer kernel. Tại Maintainers Summit 2025, họ kết luận rằng Rust đã tự gánh vác được phần của mình trong kernel, cả về kỹ thuật lẫn cộng đồng. Jonathan Corbet của LWN tường thuật sự đồng thuận này vào ngày 10 tháng 12 năm 2025: Rust trong kernel không còn là thử nghiệm.

Rust vào Linux mainline ở v6.1 năm 2022 chính là để chạy thử nghiệm đó. Bản vá của Miguel Ojeda gỡ nhãn này đến ba ngày sau Summit, và được đưa vào merge window của Linux 7.0.

“Nhưng thử nghiệm đã xong, tức là Rust sẽ ở lại.”

Miguel Ojeda, “rust: conclude the Rust experiment”, LKML, ngày 13 tháng 12 năm 2025

Tách biệt, và sớm hơn: bản viết lại bằng Rust của Google cho driver Binder của Android, lớp IPC mà các tiến trình Android dùng để nói chuyện với nhau (liên tục), đã vào Linux 6.18, phát hành ngày 30 tháng 11 năm 2025. Hãy tách cột mốc này khỏi sự đồng thuận ở Summit. Đây là lúc một công ty đặt cược một sản phẩm đang bán vào Rust trong kernel, chứ không phải một nhóm maintainer chúc phúc cho ý tưởng. Rust trong kernel từ đó đã có CVE đầu tiên: CVE-2025-68260, một race condition trong chính driver Binder đó mà Greg Kroah-Hartman công bố ngày 16 tháng 12 năm 2025, xuất hiện ở 6.18 và được sửa ở 6.18.1. Các báo cáo ban đầu tập trung vào crash, nhưng chấm điểm sau đó của nhóm CVE kernel Linux xếp CVE-2025-68260 ở mức 7,8 (Cao) và mô tả một đường leo thang đặc quyền cục bộ thông qua hỏng bộ nhớ kernel. Cùng driver đó (rust_binder) từ đó cũng tích thêm các CVE khác.

Android là nơi bằng chứng thành con số. Blog bảo mật của Google cho biết vào tháng 12 năm 2022 rằng không có lỗ hổng an toàn bộ nhớ nào được phát hiện trong mã Rust của Android, trên khoảng 1,5 triệu dòng Rust trong AOSP và khoảng 21% toàn bộ mã native mới trong Android 13. Đó là tuyên bố năm 2022 với phạm vi năm 2022. Các bài đăng sau này của Google cho thấy xu hướng dài hơn: các vấn đề an toàn bộ nhớ chiếm 76% lỗ hổng của Android năm 2019 và 24% năm 2024, với số lượng tuyệt đối giảm từ hơn 220 xuống mức dự kiến 36. Những con số đó chỉ có ý nghĩa khi so với mức nền mà chúng thay thế, tức là C và C++ được viết bởi những kỹ sư rất giỏi với công cụ rất tốt.

Hai tín hiệu nhỏ hơn cũng chỉ về cùng một hướng. Driver GPU Apple AGX trong Asahi Linux được viết bằng Rust, bởi dự án Asahi Linux như một nỗ lực dịch ngược chứ không phải bởi Apple. Bản cập nhật rust-coreutils của Canonical cho biết Ubuntu 26.04 LTS đi kèm rust-coreutils 0.8.0 cho hầu hết tiện ích. Ba tiện ích vẫn dùng GNU coreutils (cp, mv, rm) vì tám vấn đề TOCTOU vẫn còn mở tính đến ngày 22 tháng 4 năm 2026; Canonical nhắm tới 26.10 cho các tiện ích còn lại.

Đây là trục tôi chấm điểm cao nhất, và lý do là loại cam kết đi kèm. Các maintainer kernel không rút lại kết luận thử nghiệm, Google không tháo bỏ một bản viết lại quy mô như vậy, và Canonical không đưa một bộ coreutils viết lại vào bản LTS chỉ để thử xem sao. Dù độ phổ biến của Rust ra sao, sẽ phải có người bảo trì mã đó trong nhiều năm.

Rust đã chết, hay chỉ đang chững lại?

Không. Rust đã chạm lại vị trí TIOBE cao nhất từ trước tới nay, #13, vào tháng 1 năm 2026. Ba tháng sau nó tụt về #16, và CEO của TIOBE là Paul Jansen viết vào tháng 4 năm 2026, trong bình luận được Slashdot trích dẫn lúc đó, rằng đà tăng độ phổ biến của Rust “dường như đang chững lại” và vị trí top 10 “giờ có vẻ xa hơn trước.”

Ông đang mô tả việc Rust đạt vị trí cao nhất từ trước tới nay trên chính chỉ số của ông, vị trí mà nó giữ lần đầu vào tháng 7 năm 2024, rồi lại đánh mất nó.

Chỉ số TIOBE tháng 9 năm 2026 xếp Rust ở #10, tăng từ #18 một năm trước, và vượt qua mức #13 mà TIOBE gọi là vị trí cao nhất từ trước tới nay hồi tháng 1.

Nhận định của tôi: giai đoạn đi ngang là có thật. Đó là một cú hụt hơi tạm thời, không phải trần nhà. Cách đọc này đúng hơn phiên bản của cả hai phe, vì “Rust đã chững” giờ là sai và “Rust chỉ có đi lên” thì chưa bao giờ đúng.

Lời cảnh báo này đúng theo cả hai chiều, và bài viết của Slashdot đã nêu ra điều đó lúc bấy giờ: liệu thứ hạng có chỉ đang dao động theo nhiễu hằng tháng trong kết quả công cụ tìm kiếm, vốn là thứ chỉ số này đếm? Nếu tụt ba bậc trong một quý là bằng chứng mỏng cho thấy Rust đang chậm lại, thì tăng sáu bậc cũng là bằng chứng mỏng cho thấy nó đang thắng. Hãy xem nó như thời tiết, không phải khí hậu.

Tín hiệu mạnh hơn về cảm nhận là khảo sát Stack Overflow, nơi Rust một lần nữa là ngôn ngữ được ngưỡng mộ nhất trong số các ngôn ngữ lập trình năm 2025 với 72%: những người đã dùng nó trong năm qua và muốn tiếp tục dùng. Đó là ý định tiếp tục sử dụng, không phải mức độ áp dụng, và ở đây nó là tín hiệu hữu ích hơn độ phổ biến thô nếu bạn đang quyết định liệu mình có thích gắn bó với ngôn ngữ này hay không.

Đà tăng trưởng thì không rõ ràng, và tôi đặt nó nhẹ ký hơn độ bền vững ở trên, vì bạn không đầu tư vào một bảng xếp hạng.

Học Rust tốn của bạn những gì

Cái giá đến sớm và ập tới một lúc. Code mà Python, Java hay C# sẵn lòng chạy lại bị từ chối, hết lần này đến lần khác, vì những lý do có vẻ tùy tiện cho đến khi mô hình ownership “thấm”, và không có cách nào hoãn chuyện đó. Bạn không thể cứ ship code để vượt qua borrow checker như cách bạn có thể cứ ship dù chưa hiểu hết ORM của mình.

Đây là phần làm tôi bất ngờ, và nó đi ngược với điều bạn nghĩ. Trong thread r/rust “Struggling to learn Rust”, câu trả lời được hưởng ứng nhiều nhất đã định nghĩa lại vấn đề là sự lạ lẫm chứ không phải độ khó, và thread đó chỉ ra rằng những lập trình viên giàu kinh nghiệm đến từ các ngôn ngữ có garbage collector mới là người gặp khó hơn. u/Voxelman nói thẳng: “Rust không khó. Nó khác.” Trong cùng thread, họ kể lại con đường của mình: C64 Basic, rồi một loạt ngôn ngữ mệnh lệnh, và lần đầu tiếp xúc với Rust “chẳng có gì là WOW cả” vì bỏ thói quen cũ mất một thời gian.

Đó là hình dạng của hóa đơn. Nếu bạn đã viết Python tám năm, bạn không học một bộ quy tắc, bạn đang từ bỏ một bộ giả định về việc ai dọn dẹp sau bạn. Người biết ít hơn thì có ít thứ phải quên hơn.

Còn một khuôn mẫu nữa lặp lại trong thread đó, và nó biến một sai lầm về thứ tự thành vấn đề tự tin: mọi người không bị kẹt ở Rust mà ở việc chọn web framework, cố học ngôn ngữ qua Axum hay Actix trước khi ownership kịp thấm. Như u/jmartin2683 nói, việc đó “giống như cố học ruby bằng cách học rails.”

Tôi thấy phần lớn cảnh báo về cái giá đang chỉ vào sai chỗ. Hãy dành thời gian luyện tập đều đặn, không phải một cuối tuần, và đừng coi sự bực bội ban đầu là phán quyết về năng lực của bạn.

Rust cần máy mạnh hơn để build so với để chạy

Đây là phát hiện tôi không ngờ tới: build dự án Rust này tốn bộ nhớ nhiều hơn chạy nó nhiều bậc độ lớn. Tôi build một dịch vụ Axum nhỏ (Tokio với bộ tính năng full được bật, serde, serde_json, tower, một route JSON, khoảng 60 crate trong cây phụ thuộc) trên rustc và cargo 1.98.1, với strip = true trong release profile, rồi build lại từ đầu hai lần:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Khi giới hạn ở một job biên dịch (--jobs 1), bộ nhớ đỉnh trên toàn bộ cargo, rustc và linker nằm trong khoảng 464 MB đến 527 MB tùy bạn lấy phương pháp đo nào trong hai cách của tôi (tôi đo theo hai cách vì con số đầu tiên trông quá đẹp), và mất 113 giây. Với mức song song mặc định trên bốn vCPU, bộ nhớ đỉnh tăng gần gấp đôi lên khoảng 1 GB và build xong trong khoảng 35 giây. Biến số ở đây là mức song song, không phải dự án. Nhiều job hơn nghĩa là nhiều tiến trình rustc cùng nằm trong bộ nhớ một lúc, đó là lý do trình biên dịch là một trong số ít workload sẽ vui vẻ chiếm mọi core bạn cấp cho nó trong nhiều phút liền.

Chương trình hoàn chỉnh nặng 1,3 MB sau khi strip, và khi chạy không tải dùng khoảng 3,3 đến 3,6 MB bộ nhớ.

Ở mức song song mặc định, đó là lượng bộ nhớ để biên dịch nhiều gấp hai đến ba trăm lần so với để chạy; giới hạn ở một job thì vẫn hơn một trăm lần khá xa. Chọn cỡ server theo đúng nhu cầu của dịch vụ Rust trên production và bạn có thể có một máy không build nổi nó, mà kiểu hỏng hóc cũng không phải một lỗi rõ ràng: đó là OOM killer hạ rustc giữa chừng, hoặc trình biên dịch vật lộn với swap suốt hai mươi phút. Có hai cách hiệu quả. Build ở nơi có dư tài nguyên rồi mang binary đi, giống như cách giữ một máy build riêng cho các công việc Docker nặng. Hoặc build ngay trên máy đó và cho nó đủ chỗ: với một dịch vụ cỡ này, vài gigabyte RAM và hai vCPU là thoải mái. Khi không đủ, lối thoát hiểm là --jobs 1 (đúng, nó chậm hơn; đó là cái giá đánh đổi).

Nếu máy bạn làm việc không có dư tài nguyên như vậy, Linux VPS tự quản lý của chúng tôi cho bạn quyền root với thanh toán theo giờ hoặc theo tháng và một chỗ để đặt việc build rồi trả lại khi xong, dù nó vẫn là server bạn tự vận hành chứ không phải server tự vận hành.

Một dự án, một cấu hình, một máy. Máy đó là một container sandbox dùng chung, không phải server chuyên dụng, với khoảng 2 GB bộ nhớ khả dụng, nên đỉnh không giới hạn đã chạy sát trần của nó hơn so với trên một máy lớn hơn. Đây không phải hằng số chung: nếu cây phụ thuộc của bạn lớn gấp bốn lần hoặc release profile bật link-time optimization, hãy chờ đợi những con số khác. Cây phụ thuộc lớn hơn, link-time optimization và code dùng nhiều generic có thể đẩy bộ nhớ build lên cao hơn, nên đừng coi số đo của tôi là mức trần chung.

Tôi xếp chuyện này vào cách bạn làm việc, không phải vào việc có nên học ngôn ngữ hay không. Hãy biết trước khi bạn gặp phải nó.

Ai nên học Rust

Ba tình huống mà tôi sẽ khuyên bạn bỏ thời gian: phần mềm tồn tại lâu dài nơi một lỗi bộ nhớ rất tốn kém, công việc sát với hệ điều hành, và mong muốn có được sự thay đổi mà việc vật lộn với trình biên dịch mang lại cho cách bạn nghĩ về bộ nhớ. Mỗi tình huống đều có lý do để thời gian đó được đền đáp.

Bạn đã ra sản phẩm bằng một ngôn ngữ khác và đang xây dựng thứ tồn tại lâu dài mà một lỗi bộ nhớ sẽ rất tốn kém. Một dịch vụ phải luôn hoạt động. Một thư viện mà các team khác phụ thuộc vào. Bất cứ thứ gì mà một lỗi use-after-free nghĩa là một buổi review sự cố, chứ không chỉ là một stack trace trong terminal của bạn. Đây là trường hợp mà toàn bộ sự bảo đảm được xây dựng để phục vụ, và những gì bạn trả trước sẽ được khấu hao trong suốt vòng đời của thứ bạn đang xây.

Bạn làm việc gần hoặc bên trong phần mềm hệ thống. Driver, làm việc với thiết bị, tiện ích hệ thống cơ bản, embedded, bất cứ thứ gì nằm bên dưới hệ điều hành thay vì bên trên. Ngành công nghiệp đã cam kết ở đây theo cách chưa từng thấy ở nơi khác, và bằng chứng về an toàn bộ nhớ mạnh nhất ở đây.

Bạn muốn hiệu ứng phụ. Hai người bình luận trong thread r/rust đó bất đồng hoàn toàn về giá trị sự nghiệp của Rust nhưng lại đi đến cùng một chỗ ở đây. u/tyler_church, người nói nó không ảnh hưởng gì đến sự nghiệp, vẫn thừa nhận “có lẽ có ảnh hưởng tinh tế đến cách tôi viết các chương trình khác bằng các ngôn ngữ khác.” u/SirKastic23, người đã được trả lương để viết Rust được hai năm, nói nó mở rộng kỹ năng lập trình của họ theo những cách họ không ngờ tới. Hai người, không phải một nghiên cứu, nhưng đó là lợi ích còn lại ngay cả khi bạn không bao giờ viết Rust chuyên nghiệp: một thay đổi trong cách bạn nghĩ, chứ không phải một dòng trong CV.

Ai không nên học Rust

Ba tình huống mà thời gian đó nên dành cho việc khác: bạn có deadline trong tháng này, bạn mới bắt đầu học lập trình, hoặc bạn chọn ngôn ngữ theo số tin tuyển dụng nhắc đến nó. Tình huống thứ ba là điều mọi người hỏi nhiều nhất.

Bạn có deadline trong tháng này cho một ứng dụng CRUD hoặc một prototype. Rust đến đúng vào lịch trình sai nhất cho công việc phải xong trước thứ Sáu. Go là lựa chọn hiển nhiên thay thế nếu bạn muốn một ngôn ngữ biên dịch có tốc độ build nhanh và quản lý bộ nhớ bằng garbage collector, và bạn không cần các bảo đảm dựa trên ownership của Rust.

Bạn mới bắt đầu học lập trình. Điểm này thực sự chia rẽ những người viết Rust kiếm sống, và bất đồng trong các thread r/rust đi theo cả hai hướng, nên quan điểm của tôi là đưa cho người mới một phép tung đồng xu là lời khuyên tồi, bất kể đồng xu rơi mặt nào. Hãy học cách một cỗ máy hoạt động ở nơi dễ dãi hơn trước, rồi quay lại và để trình biên dịch siết chặt nó.

Bạn chọn ngôn ngữ theo số tin tuyển dụng nhắc đến nó. Tôi sẽ không đưa bạn con số nào ở đây, vì tôi không tìm được số liệu lương hay vị trí tuyển dụng nào cho Rust truy về được một nguồn mà tôi dám bảo vệ. Điều u/crusoe mô tả trong thread r/rust đó là một thị trường với ít vị trí hơn và chuyên sâu hơn. Đó là một người bình luận trong một thread, không phải dữ liệu thị trường lao động, nên tôi sẽ không biến nó thành khẳng định rằng việc làm Rust nhìn chung khan hiếm. Nếu số lượng việc làm là yếu tố quyết định của bạn, hãy xem các tin tuyển dụng hiện tại ở thị trường mục tiêu trước khi chọn ngôn ngữ.

Câu hỏi thường gặp