Việc Ubuntu dùng Rust có ý nghĩa gì?

• Sự đưa Rust vào của Ubuntu cho thấy Rust đang vượt qua chasm từ nhóm người dùng sớm (early adopter) để đi vào giai đoạn chính thống trong vòng đời tiếp nhận công nghệ
• Canonical đang áp dụng Rust làm ngôn ngữ nền tảng mặc định cho phần mềm nền tảng mới, thay thế C, C++, và một phần Python, đồng thời đầu tư tài chính và uy tín vào việc phát triển tiện ích an toàn bộ nhớ
• Người dùng trong nhóm Early Majority muốn tiêu chuẩn ngành và khả năng tương thích với quy trình làm việc hiện có, vì vậy việc thay thế tiện ích theo kiểu drop-in là chiến lược then chốt để vượt qua chasm
• Vấn đề mở rộng thư viện chuẩn của Rust lại được nhấn mạnh, và khái niệm “Rust Platform” bị bác bỏ năm 2016 đang được nhìn nhận lại, có thể lại phù hợp với nhóm Early Majority hơn
• Việc biến mở rộng áp dụng thành mô hình đầu tư và khả năng bao dung dựa trên sự đồng cảm trong cộng đồng mã nguồn mở là điều cần thiết cho giai đoạn phát triển tiếp theo của Rust

---

Việc "vượt qua chasm" của Rust khác nhau ở từng lĩnh vực

• Có hay không việc Rust đã vượt qua chasm trong Technology Adoption Life Cycle phụ thuộc vào từng lĩnh vực
• Trong Amazon, Rust đã trở nên rất vững chắc trong các data plane quy mô lớn hoặc việc xây dựng các resource-aware agent, nhưng vẫn bị xem là quá nặng đối với phát triển thông thường
• Trong lĩnh vực Safety Critical Software, đã có các trường hợp thành công, nhưng hầu hết ngành công nghiệp vẫn đang ở chế độ "quan sát"

Vai trò của "khách hàng tham chiếu"

• Yếu tố then chốt để vượt qua chasm là việc có được khách hàng tham chiếu (reference customers)
• Người dùng sớm mua công nghệ như một tác nhân thay đổi (change agent), trong khi Early Majority lại muốn cải thiện năng suất vận hành hiện có và giảm thiểu tối đa sự gián đoạn
• Việc nhìn thấy các tổ chức tương tự đã thành công là động lực thuyết phục nhất để chấp nhận công nghệ mới
• Thành công của đội S3 trong Rust rất thuyết phục với nhóm đội dịch vụ quy mô lớn, nhưng không đủ sức thuyết phục trực tiếp các đội dịch vụ CRUD, đó là một ví dụ

Chiến lược đưa Rust vào Ubuntu (Canonical)

• Tại Rust Nation, VP of Engineering của Canonical, Jon Seager, đã trình bày keynote "Rust Adoption At Scale with Ubuntu"
• Canonical trước đây chỉ dùng các ngôn ngữ tự phát triển là Python, C/C++, Go, nhưng gần đây đã bổ sung Rust và chọn nó làm ngôn ngữ gốc cho các công việc nền tảng mới
• Tương tự như keynote về Rust tại Google của Lars Bergstrom, đây là cách tiếp cận kết hợp tầm nhìn và tính thực tế
  • Đây là những đặc tính chính xác cần thiết để chuyển từ người dùng đầu tiên sang Early Majority

Đầu tư vào tiện ích an toàn bộ nhớ

• Jon Seager nói rằng Ubuntu nên hỗ trợ việc xây dựng các tiện ích an toàn bộ nhớ từ nền tảng theo hướng "pay it forward"
• Canonical đang tái cấp vốn cho việc phát triển sudo-rs và ntpd-rs của Trifecta Tech Foundation cũng như công việc coreutils của uutils
• Ubuntu thử nghiệm và kiểm chứng trước, rồi để các bản phân phối khác được hưởng lợi từ đó
• Các tiện ích drop-in tích hợp trực tiếp vào luồng làm việc hiện tại đáp ứng yêu cầu của Early Majority về "giảm thiểu sự gián đoạn"

Nhu cầu mới của người dùng mới: mở rộng thư viện chuẩn

• Trong buổi tiệc tối, Jon Seager cho rằng cần xem xét lại chính sách thư viện chuẩn nhỏ của Rust
• Đây là yêu cầu đã lặp đi lặp lại suốt nhiều năm, và họ đang lên kế hoạch một phương án thay thế không phải đơn thuần là cung cấp một thư viện chuẩn lớn, theo mô hình dự án "Battery Packs"
• Khái niệm Rust Platform được đề xuất năm 2016 (công nhận một số crate cụ thể như phần mở rộng của thư viện chuẩn) trước đây bị người dùng đầu tiên từ chối, nhưng có thể phù hợp hơn với Early Majority theo đánh giá lại
  • Khi đó, quan điểm phổ biến là chỉ cần thêm dependency vào Cargo.toml là đủ

Cần thay đổi để phát triển

• Để chuyển từ người dùng đầu tiên sang Early Majority, cần truyền thông thông điệp về "ngành chuẩn (industry standard)" thay vì "tiên tiến nhất" (state-of-the-art)
• Rust đã thành công trong việc xây dựng nhận diện trong ngành, và giờ phải trở thành lựa chọn tối ưu dựa trên "nó thực sự là gì" thay vì "nó có thể trở thành gì"
  • Hai cách nhìn này đôi khi có thể đối nghịch
• Để marketing cho nhóm thực dụng cần có sự kiên nhẫn, hiểu biết về các vấn đề của ngành đó và tham gia các hội nghị ngành

Kết nối việc áp dụng với đầu tư

• Mở rộng việc áp dụng Rust kéo theo nhu cầu tăng lên cho Rust project và hệ sinh thái của nó
• Với các tổ chức mã nguồn mở như Canonical, mối quan hệ liên tổ chức và đóng góp quan trọng hơn tiền mặt
  • Ban đầu, các nhà phát triển Rust for Linux nhận hỗ trợ từ maintainer chính của Rust, nhưng dần dần họ sửa lỗi trực tiếp, còn maintainer chuyển sang vai trò người hướng dẫn
• Một xu hướng thú vị là vốn thường đến từ các công ty đang cân nhắc triển khai Rust hơn là các công ty đã triển khai Rust
  • Người dùng đầu tiên bên trong tổ chức thúc đẩy việc triển khai toàn bộ tổ chức, và phân bổ ngân sách cho các chức năng "table stakes"
• Theo Alexandru Radovici trong danh bạ Rust Foundation Silver Member Directory, nhiều công ty phát triển phần mềm bắt buộc an toàn có ngân sách để bù đắp khoảng trống của Rust nhưng chưa biết cách sử dụng

Vai trò của mã nguồn mở và tầm quan trọng của sự đồng cảm

• Mã nguồn mở là nền tảng tốt để vượt qua chasm, nhưng cliques và "truyền miệng truyền thống" có thể trở thành rào cản gia nhập
• Một thuật ngữ sai có thể khiến ý tưởng bị bác bỏ, hoặc một phản hồi thô lỗ có thể khiến người đóng góp mới rời đi
• Điều tối cần thiết cho giai đoạn tăng trưởng tiếp theo của Rust là sự đồng cảm trong mã nguồn mở (Empathy in Open Source)
• Cốt lõi là đi đến chỗ Rust có thể giúp mọi người, hỗ trợ và trao quyền cho họ

[GN⁺]

Ý kiến trên Hacker News

• Việc Ubuntu dùng userland với giấy phép không phải GPL có nghĩa là trong hệ sinh thái Linux có thể cho phép thêm TiVoization.
  Nếu kết hợp với hướng đi mà Amutable trong hệ sinh thái systemd đang theo đuổi, có thể xuất hiện các bản phân phối Linux đóng mà người dùng không thể chỉnh sửa.
  Từ góc nhìn doanh nghiệp, một môi trường đóng kín với khả năng kiểm chứng chữ ký hoàn chỉnh có thể rất hấp dẫn. Ý tưởng thế giới mà ngay cả ls hay cd cũng là mã đóng tạo cảm giác rất khó lường, gần như tận thế.

  • util-linux hay BSD sẽ không biến mất. Không thích Ubuntu thì chỉ cần không dùng thôi. Debian đã ổn định hơn nhiều.
  • Thực ra có lý do để gọi là GNU/Linux. Android/Linux cũng không có userland theo GPL, và phần lớn đối thủ nhúng cũng không phải GPL. Cuối cùng, Linux chỉ là kernel.
  • Nhìn về lịch sử, có lẽ tôi hơi ngây thơ, nhưng tôi không cho rằng sự thay đổi này nhất thiết là xấu. Tôi thích tiện ích mã nguồn mở, song cũng thấy chấp nhận được nếu có giải pháp đóng nhưng tuân thủ thông số kỹ thuật tồn tại. Doanh nghiệp có thể đóng góp nhiều tiền hơn cho các dự án mã nguồn mở theo cách đó.
  • Thành thật mà nói, Ubuntu giống như Apple của Linux với cách đánh bằng marketing hơn là chất lượng. Với bản phân phối Debian, chi phí bảo trì thấp hơn nên tôi dùng; còn riêng tôi thấy tương lai thuộc về Fedora hoặc OpenSUSE.
  • Nếu thay đổi này khiến 95% người dùng Linux dùng cùng một hệ điều hành, có thể cũng không phải chuyện tệ.

• Rào cản thực sự Rust cần vượt qua là hỗ trợ liên kết động với ABI an toàn.
  Cần đảm bảo ngay cả khi sửa một thư viện thì tính an toàn vẫn được giữ, và đạt được độ ổn định ABI cấp C thì giới C/C++ mới có thể chấp nhận Rust.

  • Rust đã có thể giao tiếp bằng C ABI. Nó đã cung cấp chức năng liên kết động tương đương C++.
  • Sự ổn định ABI của C++ lại là một trong những nguyên nhân kìm hãm tiến hóa ngôn ngữ. Không thể thay đổi layout lớp của STL, và template cài trong header cũng khó tối ưu hóa sau này. Rust cần không nên hỗ trợ “stable ABI” kiểu này.
  • Hiệu năng của Rust dựa vào monomorphization tại thời điểm biên dịch. Muốn có ABI thì phải cân nhắc tối ưu hóa thời điểm liên kết. Không chỉ là chuyển việc sinh mã sang linker, mà phải xử lý cẩn thận “hình dạng (shape)” của tham số hàm.
  • Liên kết động cũng có lợi cho việc rút ngắn thời gian biên dịch trong bản debug; thư viện không đổi không cần build lại và overhead runtime cũng rất nhỏ.
  • Tôi thấy tiếc vì cộng đồng Rust thích MIT hơn GPL. GPL thân thiện với người dùng, còn MIT thân thiện với doanh nghiệp. Tôi nghĩ vấn đề nằm ở chỗ phong trào “Rewrite-it-in-Rust” tập trung quá nhiều vào việc lan truyền ngôn ngữ, hơn là bảo vệ người dùng.

• Điều đáng lo hơn việc Ubuntu đưa Rust vào là việc vẫn xử lý build quan trọng bằng script curl|bash.
  Rõ ràng từ snapcraft.yaml của firefox-snap.

  • Nhắc tới “curl|bash” thì thường liên tưởng đến chỉnh sửa cấu hình bừa bãi hoặc sửa .bashrc, nhưng lần này chỉ là chạy một script cài toolchain tĩnh. Cách làm kiểu những năm 90 nhưng tương đối an toàn.
  • Có rất nhiều bản phân phối đang có Rust quá cũ. Rust trong Debian hoặc Ubuntu LTS là phiên bản lạc hậu, nên có vẻ chúng không thích static linking.
  • Dù có chạy gì đó bằng curl, miễn kiểm tra hash kỹ càng thì vẫn ổn.

• Việc dự án Rust Coreutils là giấy phép MIT khiến tôi băn khoăn.
  Dù triết lý của FSF có thể bị chỉ trích, GPL bảo vệ mã nguồn mở. Không rõ nếu Canonical đổi toàn bộ Ubuntu sang MIT thì chuyện gì sẽ xảy ra.

  • GPL từng mạnh, nhưng giờ đây nhờ các hệ thống rửa quyền tác giả tự động, nhiều nơi lại chuyển sang mã MIT/BSD hoặc mã thương mại. FSF cũng không có giải pháp.
  • Tranh luận về giấy phép không bao giờ có hồi kết. GPL có thể hạn chế mức độ chấp nhận, nhưng MIT linh hoạt hơn. Cuối cùng tùy mục tiêu là gì — liệu bạn muốn một OSS cho mọi người dùng, hay muốn ngăn doanh nghiệp thu lợi mà không đóng góp.
  • Tôi tò mò khi Coreutils chuyển sang MIT thì cụ thể những “ác hành” nào trở nên khả thi hơn.

• Tôi không thể cài được CUDA Toolkit do rust-coreutils. Issue liên quan nằm ở NVIDIA Forum.

  • Luồng liên kết có vẻ là vấn đề của gzip; có vẻ không phải do dd.
  • Thành thực mà nói, rust-coreutils dường như không có lý do tồn tại. Việc đầu tiên sau khi cài Ubuntu là cài lại coreutils thật và sudo.

• Khái niệm “Crossing the chasm” rất thú vị. Ngoài ví dụ coreutils của Ubuntu còn nhiều khoảng cách khác mà Rust đang cố vượt qua.
  Rust cho Linux hay Rust cho ngành ô tô đều đang có, nhưng có vẻ vẫn dừng ở mức driver.

  • Rust đang mở rộng theo nhiều hướng. pyo3 (thay thế module Python), Dioxus (framework web kiểu React), Ferrocine (trình biên dịch cho ô tô) là những ví dụ điển hình. Dự án DARPA TRACTOR cũng đang thúc đẩy việc chấp nhận Rust.
  • Nhìn vào tài liệu Project Goals của Rust (liên kết), bạn sẽ thấy cộng đồng tập trung đầu tư vào đâu.
  • Rust tự thân thì xuất sắc, nhưng vấn đề là một số người trong cộng đồng chỉ “viết lại” phần mềm đã ổn định bằng Rust theo kiểu chiếm đoạt thương hiệu. Ubuntu dường như cũng sa vào kiểu tín hiệu hóa đức hạnh (virtue signaling) như vậy.

• Lập luận rằng chuẩn hóa lại chuẩn thư viện chuẩn sau này là nguy hiểm. Người dùng muốn hệ thống ổn định, chất lượng cao hơn là chỉ nói về “khoảng cách”.

  • Với Rust, việc thêm vào stdlib không khó như “thay đổi”. Mỗi 6 tuần có release mới, và mỗi lần thêm hơn 10 tính năng. Đã có sẵn hàng trăm tính năng trong stdlib.

• Sự chưa trưởng thành của hệ sinh thái Rust là yếu tố cản trở việc chấp nhận. Nhiều crate còn pre-1.0 hoặc chỉ ở mức wrapper đơn giản cho C. Mảng mã hóa thì ổn, nhưng các thứ như SAML thì khó tìm.

  • Các phiên bản pre-1.0 không phải lo lắm. Vì văn hóa thực thi nghiêm ngặt SemVer, nên nhiều dự án cố tình trì hoãn mốc 1.0. Những crate gắn rất sâu vào API như libc thì nâng version cũng khó. Cá nhân tôi thường tham khảo các danh sách được tuyển chọn như blessed.rs.
  • gettext cũng chỉ đạt 1.0 sau 30 năm.
  • Module cryptography của Python đòi Rust toolchain khiến cài đặt trên môi trường Termux không thể thực hiện. Khi dự án Python nặng thêm phụ thuộc Rust, việc vận hành trở nên bất tiện hơn.

• Có xu hướng dịch “cảm giác” mã C++ sang Rust chỉ để đổi giấy phép. Ví dụ, sudo-rs thực tế có hồ sơ an toàn tệ hơn phiên bản C.

  • Rust, AI và an toàn đang bị quá thổi phồng thành tuyên truyền (propaganda). Ban đầu tôi yêu thích Rust, nhưng dần dần những tranh cãi về MIT và PR thái quá khiến tôi thấy mệt mỏi.

• Standard library khổng lồ của .NET thực sự dễ chịu. Hầu hết công việc đều làm được theo cách chuẩn, và nếu có implementation kỳ quặc thì đa số sẽ đẩy để chuẩn hóa.

  • stdlib nhỏ của Rust là sai lầm, theo tôi. Vì stdlib là dependency duy nhất luôn tồn tại, nên dù chưa hoàn hảo thì nên có nhiều công cụ hơn bên trong.
  • Nhưng ở góc độ lập trình hệ thống, stdlib lớn lại có thể là vấn đề. .NET thì dựa trên GC nên không sao, còn Rust hay C++ thì phải chạy được cả trong môi trường bare-metal. stdlib lớn sẽ gây gánh nặng ở môi trường bị giới hạn bộ nhớ (<64K). std/core của Rust đã quá lớn, nên trên microcontroller phải dùng các mẹo như weak symbol. Một stdlib nhỏ có lợi cho việc duy trì ổn định API và giảm gánh nặng bảo trì. Vì C++ từng khổ sở vì chuyện này nên Rust phải thận trọng.