23 điểm bởi GN⁺ 2025-08-20 | 15 bình luận | Chia sẻ qua WhatsApp
  • Rust kỷ niệm 10 năm trong năm nay và đang dần khẳng định vị thế là ngôn ngữ chủ chốt cho việc phát triển phần mềm nền tảng (Foundational) trong tương lai
  • Phần mềm nền tảng là lớp làm nền cho mọi thứ, bao gồm kernel hệ điều hành, nền tảng đám mây, thiết bị nhúng, công cụ CLI, v.v.
  • Rust hạ thấp rào cản nhờ hệ thống kiểu bảo đảm an toàn bộ nhớ, trong khi vẫn cung cấp hiệu năng và độ tin cậy ở mức C/C++
  • Sứ mệnh của Rust không chỉ giới hạn ở lớp nền tảng mà còn lan tỏa sang phát triển ứng dụng cấp cao hơn thông qua các dự án như Dioxus, Tauri, Leptos
  • Trong thời gian tới, các lĩnh vực đầu tư trọng tâm sẽ bao gồm khả năng tương tác ngôn ngữ, mở rộng hệ thống kiểu và củng cố hệ sinh thái

Tầm nhìn của Rust: phần mềm nền tảng

  • Tầm nhìn cốt lõi của Rust là giúp việc viết và bảo trì phần mềm nền tảng trở nên dễ dàng hơn
    • Phần mềm nền tảng bao gồm kernel hệ điều hành, hạ tầng đám mây, thiết bị nhúng, công cụ CLI và những thành phần khác làm nền cho mọi hệ thống
    • Rust đã được áp dụng ở nhiều nơi như kernel Windows và Linux, công cụ tìm kiếm của VSCode là ripgrep, Deno, trình quản lý gói Python uv, v.v.
  • Với loại phần mềm này, hiệu năng, độ tin cậy và năng suất đều quan trọng đồng thời
    • Nếu lớp nền bị sụp đổ thì toàn bộ các tầng phía trên đều bị ảnh hưởng, nên tính ổn định là điều bắt buộc
    • Suy giảm hiệu năng sẽ dẫn tới giới hạn hiệu năng của các tầng phía trên, vì vậy cần mức overhead thấp nhất có thể

Hiệu năng, độ tin cậy và năng suất của phần mềm nền tảng

  • Phần mềm nền tảng cũng có nhiều yêu cầu như mọi loại phần mềm khác, nhưng ở đây mọi yếu tố đều quan trọng hơn
    • Độ tin cậy là ưu tiên hàng đầu. Nếu nền móng sụp đổ thì mọi thứ bên trên cũng thất bại theo
    • Overhead hiệu năng quyết định giới hạn hiệu năng của các tầng trên, nên phải được giảm thiểu
  • Trước đây, có hai lựa chọn để đáp ứng các yêu cầu này
    • C/C++: mang lại nhiều tự do, nhưng đồng thời đòi hỏi mức độ hoàn thiện tương xứng
    • Các ngôn ngữ cấp cao như Java, Go: cần cách viết mã đặc biệt để duy trì hiệu năng, và bị hạn chế trong việc sử dụng tính trừu tượng cùng sự tiện lợi
  • Rust thay đổi cách tiếp cận truyền thống bằng sự kết hợp giữa zero-cost abstractionhệ thống kiểu bảo đảm an toàn bộ nhớ
  • Nó trở thành công cụ giúp viết mã cấp cao một cách an toàn, đồng thời đạt được hiệu năng cấp thấp và tính ổn định bộ nhớ

Hạ thấp rào cản gia nhập và tăng cường năng lực cho lập trình viên

  • Trong các bài giới thiệu về Rust, hệ thống kiểu và kiểm tra tĩnh thường được ví như "rau bina": tốt cho bạn nhưng không phải lúc nào cũng muốn ăn
  • Nhưng trên thực tế, hệ thống kiểu là một vũ khí rất mạnh với lập trình viên
  • Người mới có thể học được cách xây dựng cấu trúc phần mềm thành công thông qua việc học hệ thống kiểu
  • Người có kinh nghiệm có thể phát hiện sai sót trong thiết kế cấu trúc của chính mình nhanh hơn
  • Phát biểu của Yehuda Katz, “Những abstraction được tạo ra trong trạng thái tập trung sẽ giúp cho tương lai mệt mỏi của tôi”, cũng tóm lược rất tốt điều này

Những lĩnh vực ngoài phần mềm nền tảng

  • Dù sứ mệnh của Rust tập trung vào phần mềm nền tảng, điều đó không có nghĩa các lĩnh vực khác bị xem nhẹ
  • Các dự án như Dioxus, Tauri, Leptos đang mở rộng Rust sang cả các lĩnh vực ứng dụng cấp cao như GUI và trang web
  • Điểm mạnh cốt lõi của Rust về bản chất vẫn tập trung vào phần mềm nền tảng, nhưng những nỗ lực này cũng không nên bị xem nhẹ

Mục tiêu kéo giãn và tăng trưởng

  • Vì phần mềm nền tảng cần khả năng kiểm soát chi tiết ở mức thấp, nên người ta thường cho rằng khả năng tiếp cận và tính tiện dụng (ergonomics) không quá quan trọng
  • Nhưng chính vì cần mức độ kiểm soát chi tiết đó, tính tiện dụng lại càng quan trọng hơn
  • Nếu có thể giúp lập trình viên chỉ tập trung vào những phần thực sự quan trọng, năng suất sẽ tăng lên đáng kể
  • Các dự án thúc đẩy việc áp dụng Rust ở tầng cao hơn mang lại cơ hội cải thiện để việc lập trình Rust trở nên thuận tiện hơn
  • Những cải tiến đó cũng sẽ được phản ánh nguyên vẹn vào phát triển phần mềm nền tảng
  • Cốt lõi là nâng cao tính tiện dụng mà không đánh mất quyền kiểm soát và độ tin cậy

Tầm quan trọng của việc hỗ trợ toàn bộ stack

  • Một lý do khác khiến phát triển ứng dụng cấp cao trên Rust trở nên hấp dẫn là có thể xây dựng toàn bộ stack bằng một công nghệ duy nhất
  • Ban đầu, nhiều lập trình viên chỉ định dùng Rust cho một phần như dịch vụ data plane, nhưng sau đó thường mở rộng ra toàn bộ phạm vi
  • Lý do là Rust có năng suất cao và cho phép chia sẻ thư viện cũng như mã nguồn trong cùng một ngôn ngữ
  • Về bản chất, mã đơn giản thì được viết bằng ngôn ngữ nào cũng vẫn đơn giản

Trải nghiệm đào sâu dần từng bước (Iterative Deepening)

  • Lý tưởng nhất là trải nghiệm đầu tiên của người dùng Rust phải đơn giản, và khi dự án tiến triển, họ có thể dần mở rộng thêm mức độ kiểm soát một cách cục bộ
  • Điều này nghe có vẻ đơn giản nhưng trên thực tế là một bài toán rất khó
  • Nhiều dự án thất bại vì hoặc rào cản nhập môn quá lớn, hoặc việc học các mức kiểm soát cao hơn đòi hỏi quá nhiều kiến thức
  • Rust không phải lúc nào cũng làm tốt điều này, nhưng cộng đồng vẫn đang liên tục nỗ lực để cải thiện

Kế hoạch sắp tới

  • Bài viết này là phần đầu của loạt bài, và trong bốn bài tiếp theo sẽ trình bày các lĩnh vực đầu tư cần thiết để Rust phù hợp hơn nữa với phần mềm nền tảng
    • Khả năng tương tác ngôn ngữ mượt mà (smooth language interop)khả năng mở rộng (extensibility)
    • Làm rõ mục tiêu thông qua hệ thống kiểu (clarity of purpose)
    • Củng cố hệ sinh thái: hướng dẫn tốt hơn, công cụ tốt hơn và tận dụng Rust Foundation
    • Bài cuối sẽ bàn về cách vận hành tổ chức mã nguồn mở của Rust, để việc đóng góp và bảo trì trở thành hoạt động dễ tiếp cận và thú vị nhất có thể

15 bình luận

 
yeorinhieut 2025-08-23

Có cảm giác Rust trông cũng khá ổn, nhưng đây có lẽ là ngôn ngữ duy nhất khiến tôi ngại vì fandom độc hại(?).

 
aer0700 2025-08-22

Ước gì C hay C++ có một trình quản lý gói tiêu chuẩn. Mỗi lần nhìn Cargo tôi lại luôn nghĩ như vậy.

 
cosine20 2025-08-21

Rau bina ngon thế mà....

 
t7vonn 2025-08-21

Dạo này hầu như không có nơi nào mà Rust không được sử dụng.

 
lostid 2025-08-21

Tôi cũng làm ở một công ty lớn theo cách riêng của mình, nhưng không có lĩnh vực nào dùng Rust cả. Xin đừng tô hồng quá mức.

 
t7vonn 2025-08-21

Đừng gây sự.

 
bobross0 2025-09-03

Ôi trời ơi;;

 
crawler 2025-08-21

Đừng kiếm chuyện nhé, run run

 
shakespeares 2025-08-22

Ghê thật ;;

 
qwas5544 2025-08-22

Trời ơi;;;

 
lostid 2025-08-21

Bỏ qua mọi chuyện khác thì dạo này tôi phát điên vì đám cuồng Rust. Ngoài đời thì trong số các nhóm thiểu số còn thuộc hàng siêu thiểu số, nhưng trên mạng thì gần như ISIS... Ước gì họ tụ lại một chỗ nào đó rồi chỉ tự chơi với nhau thôi...

 
ifmkl 2025-08-21

Nhiều khi những người kiểu “Rust giáo” ấy cũng khiến người ta tự hỏi liệu chính họ có thực sự dùng nó cho ra hồn hay không.

 
skageektp 2025-08-21

Dù sao thì... bạn vẫn yêu Rust chứ?
Có thể ghét giáo phái Rust, nhưng xin hãy yêu Rust thôi hu hu

 
taeunlee99 2025-08-21

Dù từng bị FFmpeg vả cho tơi tả thì vẫn cứ bảo phải viết toàn bộ code bằng Rust hay gì đó.

 
GN⁺ 2025-08-20
Ý kiến trên Hacker News
  • Khi bàn về phần mềm cốt lõi, điểm đáng tiếc nhất của Rust theo ý kiến này là ABI. Nếu muốn xây dựng OS bằng Rust và cung cấp dịch vụ phong phú, thì ngay cả khi OS được nâng cấp, ứng dụng vẫn phải dùng được mà không cần biên dịch lại thư viện. Windows giải quyết việc này bằng COM, Apple trước đây dùng dynamic dispatch của ObjC (và giờ là Swift ABI), Android thì dùng JVM và bytecode. Rust trên thực tế gần như chỉ hỗ trợ extern "C", nên việc tận dụng thư viện động bị hạn chế. Cung cấp ABI mà không có một lớp VM như JVM hay .NET là cực kỳ khó, và vì một khi đã chốt chi tiết triển khai thì gần như không thể thay đổi nữa, nên việc này bị xếp ưu tiên thấp cũng là điều dễ hiểu. Trên thực tế, những mô hình kiểu này thành công được cũng chỉ có Swift và COM. Nếu Rust có một ABI hoàn chỉnh thì nó sẽ gần như là một ngôn ngữ hoàn hảo. (Quản lý phụ thuộc ở dạng nhị phân cũng sẽ giúp giảm mạnh thời gian biên dịch)

    • Giải thích rằng lý do Rust về cơ bản chỉ muốn đưa vào tính ổn định ABI theo kiểu opt-in là vì theo đuổi zero-cost abstraction. ABI ổn định đi kèm suy giảm hiệu năng, điều này được minh họa qua trường hợp của C++ (giải thích về C++ ABI). Để nạp động plugin giữa các chương trình Rust với nhau (dlopen), đã có các công cụ như stabby, abi_stable và chúng hoạt động khá tốt. Với mục tiêu tương tác liên ngôn ngữ tổng quát hơn, crABI (đề xuất crABI) có thể là một phương án tương lai. Tuy vậy đây không phải vấn đề Rust có thể tự giải quyết, mà cần sự ủng hộ và hợp tác từ nhiều cộng đồng khác, như các ngôn ngữ khác và các bản phân phối Linux. Cũng có nhắc rằng vì Rust là ngôn ngữ buộc phải lựa chọn tường minh cách làm I/O và cấp phát bộ nhớ, nên cấu trúc kiểu Swift, nơi mọi thứ được giải quyết chỉ bằng shared library, có thể không phù hợp
    • Người ta đang gần như cố giải quyết chính vấn đề này bằng Wasm Components. Nếu WebAssembly là định dạng lệnh có tính di động, thì WebAssembly Components là định dạng thực thi/liên kết có tính di động. Nó không đơn giản hoàn toàn như repr(wasm)/extern "wasm", nhưng nếu dùng wit-bindgen hoặc target wasm32-wasip2 thì không quá khó để sử dụng. Video giới thiệu Wasm Components
    • Có người bày tỏ nghi ngờ liệu điều này có thực sự cần thiết không. Dù đúng là sẽ tiện hơn nếu có thể truyền nhiều “thứ” đa dạng hơn qua interface, như slices hay trait objects, nhưng trên thực tế chỉ với ABI extern "C" cũng đã làm được mọi thứ cần thiết. Và cũng từng thấy các đề xuất mở rộng extern ABI sang nhiều kiểu hơn
    • Có người nói từng xem một bài trình bày ở hội nghị Rust về chủ đề này, trong đó cách tiếp cận của Swift được tham khảo rất mạnh. Dự đoán là sau này có thể Rust sẽ phát triển theo hướng đó
    • Thực ra cái đó đã tồn tại rồi. Nó có tên là "C"
  • Rất thích Rust, nhưng mong rằng một số vấn đề cố hữu gây khó chịu khác sẽ được quan tâm nhiều hơn

      1. Có vấn đề về self-referencing struct. Ví dụ, muốn chứa cả source file và AST đã parse vào cùng một struct nhưng hiện tại không dễ. Sẽ tốt hơn nếu có thứ như offset reference
      1. orphan rule (quy tắc trait mồ côi). Dù hiểu lý do tồn tại, nó vẫn là một quy tắc phiền phức. Có thể giải quyết bằng các tính năng mới (đôi khi phải bọc 2-3 lớp!), nhưng vẫn tự hỏi liệu có nhất thiết phải như vậy không
      1. Muốn có thời gian biên dịch hợp lý thì phải chẻ dự án thành rất nhiều crate nhỏ. Dù hiểu nguyên nhân, kết quả thì không hay. Crate được xem là một đơn vị biên dịch duy nhất, vì cho phép phụ thuộc vòng. Nhưng phần lớn code thực tế không có phụ thuộc vòng, nên sẽ tốt hơn nếu đây là thứ opt-in, hoặc nếu các item/file bên trong crate có thể tự động được chia thành đơn vị biên dịch theo đồ thị phụ thuộc
    • Chỉ ghi ra những gì nghĩ tới trước mắt, nhưng chắc còn nhiều nữa. Dù vậy Rust vẫn là ngôn ngữ tuyệt vời nhất đời tôi, và đây là phê bình mang tính xây dựng
      • Chỉ ra rằng Rust không cho phép phụ thuộc vòng giữa các crate, nhưng lại cho phép phụ thuộc vòng giữa các module trong cùng một crate. Dù cho rằng đa số code không có phụ thuộc vòng, nhưng chẳng hạn bất kỳ module nào có test submodule cũng sẽ rơi vào trường hợp có vòng phụ thuộc. Nếu muốn tách test cho đúng nghĩa thì phải định nghĩa mọi hàm test ở crate root, điều này ngoài thực tế rất kém hiệu quả
      • Hoàn toàn đồng ý với ý 1 và 2. Cũng bổ sung ý 4 là mong có partial self borrows, tức cho phép method chỉ borrow một phần của struct. Với ý 3 thì cho rằng trước hết cần hỗ trợ tốt hơn cho việc phát hành nhiều crate cùng lúc
      • Về orphan rule, có người muốn nghe giải thích rõ hơn là đang nói Rust cần đưa vào một phương án tốt hơn thay thế quy tắc này, hay chỉ cần có những tính năng có thể thay thế tác dụng của nó là đủ
      • Hoàn toàn đồng ý về orphan rule. Sẽ tốt hơn nếu ở application crate có thể tắt quy tắc này, hoặc nới lỏng nó khi đã có đủ bảo đảm về hygiene, chẳng hạn thông qua proc macro
  • Khi ngẫm về cụm từ “Smooth, iterative deepening”, có người cho rằng Rust đang quá coi trọng khả năng tương thích liên ngôn ngữ, và điều đó có nguy cơ chỉ làm tăng độ phức tạp cũng như làm hại tính an toàn. Trong trường hợp này, họ cho rằng cách hữu ích hơn là thay thế phần nền tảng thấp nhất của hệ thống như libc. Go gần như không gọi xuyên ngôn ngữ. Google tự phát triển các thư viện lõi để làm nền móng vững chắc, còn với Rust thì đang tồn tại rất nhiều phiên bản thư viện nền tảng khác nhau và nhiều thứ vẫn chưa hoàn thiện

    • Có người nói rằng một trong những bài toán cốt lõi của khoa học máy tính suốt 20 năm qua là làm sao để nhiều chương trình trên cùng một máy giao tiếp hiệu quả với nhau. Đa số hoặc là tìm cách lách mô hình DLL của Microsoft bằng source và state, hoặc là như CORBA, các object request broker đã thất bại trong việc bám rễ. RPC kiểu qnx cũng tương tự. Vì thế đến giờ người ta vẫn chỉ lặp đi lặp lại việc cố buộc những thứ vốn không khớp nhau phải hoạt động chung
    • Thực ra mọi thứ đều có thể xử lý bằng socket, nhưng socket là luồng byte thô nên là một abstraction sai, dù vậy vì tính tiện dụng nên vẫn phải dùng
      • Theo một ý kiến, điều bài viết đang nói tới không phải là muốn tạo ra một thứ thật sự thay thế shared library liên ngôn ngữ như DLL/COM/Wasm components, mà là xuất phát từ nhu cầu thực tế muốn di trú dần từ C++ sang Rust. Để cải thiện tổng thể tính an toàn bộ nhớ, câu hỏi lớn là “các chương trình hiện có sẽ ra sao”, nhưng mức tương tác hiện tại giữa Rust và C++ vẫn còn thiếu. Nếu hai ngôn ngữ có thể phối hợp trơn tru ở cấp độ source, thì khả năng thực tế để Rust thay thế phần lớn phạm vi của C++ sẽ tăng lên đáng kể
      • Đôi khi chỉ cần socket và giao thức là đã gần như abstraction liên ngôn ngữ tốt nhất rồi. Vậy nên cũng tò mò abstraction gọi xuyên ngôn ngữ nào mới thực sự được xem là lý tưởng
  • Có người nhấn mạnh rằng “tránh cấp phát, đừng để GC bị kích hoạt” là một quan niệm không còn phù hợp với GC và JIT hiện đại. GC hiện đại trong nhiều trường hợp gần như không có stop-the-world latency, và tổng CPU dùng cho GC chủ yếu phụ thuộc vào tỷ lệ giữa resident set và kích thước heap. JIT có nhiều cơ hội tối ưu hơn AOT, và có thể khám phá tích cực hơn nhờ speculative optimization. Điều thực sự quan trọng không phải là hiệu năng tệ nhất, hay độ trễ khởi động/warm-up và overhead bộ nhớ, mà là hiệu năng trung bình. Hơn nữa, quản lý bộ nhớ thủ công cũng không nhất thiết hiệu quả hơn, và ngay cả khi lượng RAM dùng thực tế tăng gấp 3 thì chênh lệch chi phí có thể vẫn bằng 0. Cũng giới thiệu bài trình bày tại hội nghị ISMM nói khá hay về chủ đề này

    • Có người muốn hỏi cụ thể câu nói JIT có nhiều cơ hội tối ưu hơn là có ý gì, vì JIT rốt cuộc cũng chỉ là phần bổ sung cho AOT
    • Có câu hỏi rằng “GC hiện đại” ở đây đang chỉ những triển khai nào
  • Có ý kiến cho rằng các bình luận và thảo luận bị gắn cờ đã chạm đúng trọng tâm. Những câu hỏi thực tế quan trọng như “hãy tạo một chuẩn ngôn ngữ có đặc tả chính thức” hay “cần nhiều hiện thực” đều rất đáng bàn. Đặc biệt, @infogulch đã chỉ ra đúng rằng nếu một ngôn ngữ muốn trở thành nền tảng của ngành công nghiệp thì đặc tả chính thức là điều bắt buộc (bình luận tham khảo)

    • Có người đáp lại một cách dí dỏm rằng không chỉ không rõ vì sao bình luận đó bị gắn cờ, mà trên thực tế cũng có rất nhiều ngôn ngữ trở thành nền tảng công nghiệp dù không có đặc tả chuẩn hoặc không có nhiều hiện thực. Ví dụ Ruby đúng là có một chuẩn ISO cũ, nhưng nó chỉ áp dụng cho phiên bản đó; Python thì trên thực tế chính implementation là tiêu chuẩn. Rust cũng vậy, và từ góc nhìn người dùng phổ thông thì không ai nghĩ mình sẽ đổi ngôn ngữ chỉ vì chuyện này
    • Có người tò mò về “chuẩn ngôn ngữ chính thức” nên đi tìm và thấy có tài liệu tham chiếu rust-lang/reference. Dự án Rust đang rất nghiêm túc với việc đặc tả ngôn ngữ. Bài blog giới thiệu tầm nhìn đặc tả gần đây giải thích khá chi tiết tiến độ. Công việc đặc tả rất lớn và khó, nhưng vẫn đang được thúc đẩy tích cực đến mức cuối tuần vẫn có PR được merge vào nhánh master
    • Việc cần nhiều implementation cũng có thể đã được hỗ trợ phần nào, vì các trình biên dịch Rust thay thế như gccrs đã và đang được phát triển một cách chính thức
    • Có góc nhìn hoài nghi rằng cả LLM lẫn Rust về bản chất đều chỉ làm hài lòng một bộ phận và mang lại chút cải thiện về năng suất. Tuy vậy, người này không đồng tình với thái độ muốn gia tăng ảnh hưởng một cách thiếu trách nhiệm trong cộng đồng
    • Có người muốn được giải thích rõ “published language standard” chính xác là gì và trên thực tế nó giúp ích như thế nào
    • Có người nói bản thân không bất mãn với Rust, nhưng lại thấy tiếc vì một số người dùng không hiểu tầm quan trọng của formal specification. Mọi hệ thống tính toán đều có tuổi thọ và độ tin cậy phụ thuộc vào việc tiếp cận đặc tả một cách formal đến đâu. Nếu không có đặc tả rõ ràng, ta buộc phải phụ thuộc hoàn toàn vào chuyện “một implementation nào đó tình cờ chạy được với đầu vào nào đó”, và xây dựng hệ thống trên một nền tảng mong manh như vậy là rất nguy hiểm. Trong điện toán, đặc tả chính là hệ thống (implementation chỉ là phần tối ưu phụ)
  • Có người thường đặt câu hỏi liệu Rust có cần đặc tả hay không, và điều này theo một ý kiến lại cho thấy software engineering đang thiếu tính engineering thực sự

    • Có người cho rằng software engineering không phải engineering thật sự. Khác với cầu hay nhà cao tầng, nơi không thể xây đi xây lại ba lần mới ra đúng, thì với phần mềm điều đó lại thường là một cách tiếp cận tốt
  • Trước bình luận rằng Rust là “ngôn ngữ chỉ dành cho những người muốn trông như lập trình viên”, có người nói rằng bản thân họ thực sự yêu việc lập trình và Rust từng là một cú sốc mới mẻ. Họ không hề muốn quay lại quá khứ nơi C++ gây đau khổ tột độ. Và họ cũng không nghĩ tiêu chuẩn ngôn ngữ (Ferrocene hiến tặng đặc tả) hay số lượng implementation là điều quan trọng. Python và Java vẫn vận hành tốt dù hầu như ai cũng dựa vào một implementation trung tâm. C++ thì vì cố hỗ trợ nhiều compiler mà cuối cùng chỉ làm phình to các vấn đề phức tạp theo từng nền tảng. Họ cũng không rõ cụ thể cargo “hỗn loạn” ở điểm nào, và cho rằng phía C++ bất tiện hơn nhiều

    • Có người hỏi cụ thể cargo có vấn đề ở điểm nào
    • Cũng có người băn khoăn liệu chuyện chuẩn hóa ngôn ngữ/công cụ và đa dạng implementation có thực sự quan trọng hay không, có phải là quá sớm hay không, và nếu Rust từ rất sớm đã đổ năng lượng vào các việc này thì liệu nó có đạt được thành công như hiện tại không. Bài viết dường như không chủ trương một sự thay thế toàn diện, mà muốn nhấn mạnh sự hỗ trợ/phù hợp cho các mục tiêu cụ thể
    • Có người cho rằng cargo hiện là package manager tốt nhất trong số các ngôn ngữ lớn trên thế giới. Nó đã học rất tốt từ những thất bại của các package manager trước đó, nên vừa tinh vi vừa có hạ tầng ở đẳng cấp cao. Có thể vẫn cần một số cải tiến như namespace hay repeatable build hoàn chỉnh, nhưng việc mang cargo hiện tại sang ngôn ngữ khác gần như là bất khả thi. Rất ít ngôn ngữ có được mức hạ tầng như vậy