Git: công bố đưa Rust vào và bắt buộc trong hệ thống build

• Dự án Git đã chính thức công bố rằng trong thời gian tới sẽ đưa Rust vào phần lõi, và từ Git 3.0, Rust sẽ trở thành yêu cầu bắt buộc để build
• Loạt bản vá lần này được triển khai với tính chất thử nghiệm ban đầu (test balloon) tương tự như việc từng đưa các tính năng C99 vào trước đây, với mục tiêu từng bước chuẩn bị hạ tầng cho việc áp dụng Rust
• Ở bước đầu, mô-đun varint.c gần như không có phụ thuộc được chuyển sang Rust để kiểm chứng khả năng tương tác C-Rust và công cụ build
• Hiện tại mới chỉ hỗ trợ build bằng Meson; trong tương lai dự kiến sẽ bổ sung hỗ trợ Makefile và trong CI sẽ thêm kiểm chứng build Rust cùng kiểm tra tính nhất quán định dạng dựa trên cargo format
• Đây là một thay đổi quan trọng giúp cộng đồng Git và các nhà phân phối có thời gian thích nghi với yêu cầu mới về toolchain Rust, đồng thời về lâu dài nâng cao tính an toàn và khả năng mở rộng của mã nguồn

---

Bối cảnh đưa Rust vào

• Git đã xem xét sự tiến hóa về ngôn ngữ để phục vụ tính ổn định và khả năng bảo trì
• Việc đưa Rust vào mang ý nghĩa tăng cường an toàn bộ nhớ, tận dụng toolchain hiện đại và mở ra khả năng tối ưu hiệu năng
• Đồng thời, dự án cũng muốn xây dựng một codebase vững chắc hơn thông qua việc áp dụng ngôn ngữ hiện đại
• Mục tiêu là thông báo trước rằng đến thời điểm phát hành Git 3.0, Rust sẽ trở thành yêu cầu bắt buộc để hệ sinh thái có thời gian chuẩn bị
• Phạm vi áp dụng mã Rust sẽ được mở rộng theo từng giai đoạn, và về lâu dài một số chức năng cốt lõi cũng sẽ được tái triển khai bằng Rust

Loạt bản vá thử nghiệm

• varint.c được chọn làm mô-đun đầu tiên áp dụng Rust
  • Rất đơn giản và không có phụ thuộc
  • Có thể kiểm chứng interop C ↔ Rust
  • Có thể thử nghiệm mà không ảnh hưởng đến toàn bộ chức năng của Git
• Tất cả các bài kiểm thử đều đã vượt qua với phiên bản varint.rs

Thay đổi trong hệ thống build

• Hiện tại, hỗ trợ Rust mới chỉ được thêm vào hệ thống build Meson
• Trong tương lai có kế hoạch bổ sung hỗ trợ Rust cho Makefile
• Công việc liên quan đến CI cũng cần được chuẩn bị
  • Kiểm chứng build Rust và hoạt động thực tế
  • Đảm bảo tính nhất quán về style mã bằng cargo format
  • Tự động hóa các tác vụ toolchain và bảo trì khác

Kế hoạch sắp tới

• Công việc lần này tập trung vào thử nghiệm quy trình áp dụng hơn là bản thân tính năng Rust
• Sau đó, nhiều chức năng nội bộ khác của Git, bao gồm mô-đun xdiff, có thể được viết lại bằng Rust
• Dự án dự kiến sẽ dần mở rộng phạm vi áp dụng Rust để toàn bộ hệ sinh thái thích nghi với môi trường build dựa trên Rust

Hàm ý

• Git đang chuẩn bị cho bước chuyển đổi ngôn ngữ quan trọng nhất trong lịch sử của mình
• Việc bắt buộc Rust có thể giúp đảm bảo tính an toàn, khả năng bảo trì và tiềm năng phát triển dài hạn
• Các nhà phân phối và nhà phát triển trong hệ sinh thái Git sẽ cần thiết lập môi trường phát triển Rust trong tương lai

[GN⁺]

Ý kiến trên Hacker News

• Về cuộc thảo luận ở luồng khác xoay quanh việc đưa Rust thành yêu cầu bắt buộc, người viết cho rằng thay vì bắt buộc ngay Rust thì nên đưa vào như một phụ thuộc tùy chọn trước, rồi sau này khi gcc có thêm hỗ trợ Rust thì hãy chuyển sang bắt buộc
  Liên kết thảo luận liên quan
  • Nhấn mạnh rằng trình biên dịch gcc thiếu tính nhất quán, ví dụ gcj (gcc cho Java) hầu như chẳng ai dùng
    Vì Rust cũng là một ngôn ngữ không có chuẩn chính thức, nên có nghi ngờ rằng theo thời gian các bản triển khai sẽ bị tụt hậu đáng kể, giống như Java trước đây
• Thắc mắc vì sao lại muốn đưa Rust vào Git
  Git vốn đã có vẻ là một công cụ rất hoàn thiện, có lẽ chỉ cần bảo trì hay cải tiến dần dần, chứ không có vẻ cần lượng mã mới lớn đến mức phải đưa thêm một ngôn ngữ mới vào
  Khác với Linux, nơi liên tục cần thêm driver mới, Git dường như không có lý do tương tự
  Mong ai đó giải thích xem liệu mình có đang bỏ sót điều gì không
  • Git vẫn liên tục được bổ sung tính năng, dù không quá dễ nhận ra
    Có thể xem các thay đổi của Git trong RelNotes, hoặc xem dễ hơn tại chuyên mục Git trên blog GitHub
  • Nếu dùng thử các công cụ như jj hay git-branchless thì sẽ bớt nghĩ rằng git đã hoàn thiện xong
    Riêng git-branchless có những tính năng như merge trong bộ nhớ được viết bằng Rust
  • Có nhiều câu trả lời trong bài viết này nên rất đáng tham khảo
    Nếu muốn tìm nội dung liên quan đến Rust thì có thể tìm thêm trong mailing list đó
    (Không trực tiếp đánh giá ủng hộ hay phản đối, chỉ nói rằng sẽ có người khác làm việc đó)
  • Các dự án C lâu năm đang ngày càng khó thu hút thêm lập trình viên mới
    Hầu như không có ai muốn phát triển Git bằng C, trong khi những lập trình viên quan tâm đến việc viết lại bằng Rust lại rất hào hứng tham gia
  • C không an toàn
• Thắc mắc vì sao Rust cứ liên tục được đưa vào nhiều nơi
  Git có vẻ đã khá hoàn thiện nên lượng mã mới được thêm vào có lẽ cũng không nhiều
  Rust phức tạp hơn C rất nhiều
  Nếu thực sự cần tính năng hướng đối tượng thì chỉ cần dùng mức C++98 thôi cũng đã đơn giản và dễ hiểu hơn nhiều so với C++ hiện đại hay Rust
• Tiêu đề có phần dễ gây hiểu lầm
  Rust không phải sẽ là bắt buộc cho các bản vá sau này, mà sẽ là yêu cầu bắt buộc trong hệ thống build
  • Bày tỏ cảm ơn và nói rằng đã phản ánh nội dung đó vào tiêu đề
    Nếu vẫn sai thì có thể sửa lại
  • Sau đó có câu hỏi tiếp rằng điều này thực ra có nghĩa là gì
    Không rõ là cần để build chính hệ thống build, hay là cũng bắt buộc khi build ứng dụng
• Có ý kiến rằng mình cũng có tuổi rồi nên hiểu là cần chấp nhận thay đổi, nhưng trước đây chỉ cần biết C là đã có thể tham gia phát triển Git hay kernel, còn giờ lại phải biết thêm Rust, và việc toolchain ngày càng phức tạp đang làm tăng rào cản gia nhập
  Đã đầu tư rất sâu vào Git và tạo ra nhiều dự án xung quanh nó, nên không muốn Git mất đi tính dễ hack
  • Cho rằng thái độ không muốn học cái mới là không phù hợp với ngành này
    Trên thực tế Rust còn dễ học hơn C thông thường (đặc biệt là C dễ sinh lỗi), và chắc chắn dễ hơn việc làm quen với mã nguồn Git hay Linux
  • Dù có tự làm Git client hay web server đi nữa, định dạng kho lưu trữ Git cũng không thay đổi nên khả năng hack sẽ không bị ảnh hưởng
  • Nhân tiện, Git vốn đã dùng nhiều ngôn ngữ khác nhau
    Theo GitHub thì C chiếm 50%, Shell 38%, Perl 4%, còn lại là TCL/Python v.v.
    Perl/TCL mới là ngoại lệ hơn
    Khi dự án lớn lên, có rất nhiều đoạn mã kiểu “vá chằng vá đụp” được thêm vào khắp nơi, và giờ là lúc cần cải thiện an toàn/hiệu năng cũng như dọn dẹp những đoạn mã kiểu đó
    Rust được cho là phù hợp với việc này
  • Nếu là kỹ sư phần mềm thì việc thành thạo nhiều ngôn ngữ là chuyện bình thường, nên việc thêm một ngôn ngữ nữa không phải vấn đề lớn
  • Bản thân tôi và nhiều lập trình viên trẻ thích Rust hơn và không muốn học C
    Việc Git dùng một phần Rust cũng sẽ không cản trở tôi tự phát triển Git client hay server
• Có yêu cầu giải thích thêm về nhận định rằng việc đưa Rust vào là không thể trên một số nền tảng và khó khăn trên những nơi khác
  • Trên hệ Linux, thư viện nào cũng phải được dùng như thư viện hệ thống, nhưng Rust không có ABI ổn định nên không thể dùng như thư viện chia sẻ thực sự
    Ghi chú phát hành của Debian cũng nêu rõ các vấn đề liên quan đến gói Rust/Go
    Khi build gói Rust thường phải rebuild nhiều lần do vấn đề liên kết tĩnh, nên gây bất tiện trong thực tế sử dụng
    Nếu phía Rust tiếp tục phớt lờ vấn đề ABI ổn định/thư viện chia sẻ vốn là yêu cầu bắt buộc của Linux OS, thì thậm chí có thể tạo ra nhiều lời phàn nàn hơn cả C
    Với kiến trúc phần mềm quy mô lớn, cần thận trọng hơn
  • Trên một số nền tảng độc quyền ít được nhắc đến, họ có hỗ trợ trình biên dịch C riêng nhưng không thể hỗ trợ LLVM
    Có thể tìm từ khóa NonStop trong bài viết này để xem ví dụ
  • Lý do là trình biên dịch Rust không hỗ trợ một số nền tảng nhất định (tổ hợp OS/kiến trúc)
    Ở RESF và những nơi tương tự, người ta nói rằng “nền tảng không hỗ trợ Rust”, nhưng thực tế phải là trình biên dịch Rust hỗ trợ thì mới chạy được thật sự
  • Rust dựa trên LLVM nên bị giới hạn hơn các nền tảng mà GCC hỗ trợ
  • Có người hướng dẫn tham khảo mục 'Tier 3' trong danh sách hỗ trợ nền tảng của tài liệu Rust chính thức
• Tò mò không biết git 3.0 sẽ có thay đổi gì
  git có cảm giác đã ổn định ở dòng 2.x nên dường như không có lý do gì để phá vỡ tương thích
  • Có câu trả lời dẫn đến tài liệu git 3.0 Breaking Changes
  • Hàm băm mặc định sẽ được đổi sang SHA-256
• Trước đây, trong môi trường cross-compile, chuyện build, chạy và chỉnh sửa mã nằm ở các nơi khác nhau gần như là giả định cơ bản
  Có người thắc mắc liệu văn hóa phát triển gần đây có đang rời xa kiểu dùng toolchain như vậy không
  Môi trường source control, build và chạy tách biệt nhau nên cần sao chép từ xa hay chạy từ xa, và trong quy tắc build cũng bắt buộc phải phát hiện nền tảng đích
  • Ngược lại, có cảm nhận rằng toolchain Rust giúp cross-compile dễ hơn bất kỳ ngôn ngữ biên dịch nào khác
    Chỉ với cờ --target là có thể build cho khoảng hơn 100 nền tảng mà hầu như không gặp vấn đề gì đáng kể
    Vấn đề thực sự có lẽ là một số nhà phát triển Git vẫn khăng khăng bám vào các máy phát triển cũ/cố định của riêng họ
  • Có người cho rằng đa số lập trình viên thực ra chưa từng học cross-compile một cách nghiêm túc
    Cross-compile lúc nào cũng là công dân hạng hai, và ở các dự án bên ngoài thì người ta gần như chẳng kỳ vọng nó hoạt động đúng
    Ngay cả các bản phân phối Linux đôi khi cũng để những thứ như Raspberry Pi phải build ngay trên phần cứng thật
    Vì thế không ai thực sự nỗ lực hỗ trợ chuyện này cho đúng nghĩa
  • Dù có Rust hay không thì tình trạng cross-compile ngày nay vẫn gần như là “thảm họa”
    Linux đặc biệt nghiêm trọng vì cấu trúc glibc đã quá cũ, khiến việc nhắm tới một mức glibc tối thiểu trên mọi phần cứng trở nên khó khăn
    Phần lớn dự án thậm chí còn không thử hỗ trợ cross-compile
    Zig đang cố gắng cải thiện điều đó
• Có ý kiến cho rằng nên hoãn việc áp dụng cho đến khi frontend Rust liên quan đến gcc đủ trưởng thành
  Git là công cụ cốt lõi của dự án, nên thay đổi như vậy mang rủi ro lớn, và việc biến nó thành phụ thuộc bắt buộc chỉ trong thời gian ngắn như 6 tháng là quá mạo hiểm
• Rust có đường cong học tập lớn và phức tạp, giống các ngôn ngữ hàm
  Sự phức tạp này nhằm bắt được nhiều lỗi hơn ở thời điểm biên dịch, nhưng hệ quả là bản thân ngôn ngữ trở nên khá phức tạp
  Vì điểm này nên không khuyến nghị áp dụng
  Theo hiểu biết của người viết thì kernel cũng đã từ chối Rust vì lý do tương tự
  Nếu đưa thêm vào một kernel vốn đã phức tạp cả hệ thống kiểu ở mức Haskell lẫn hệ thống macro kiểu Lisp thì độ phức tạp sẽ còn tăng hơn nữa
  Việc lần theo mã Rust qua serde cũng khó
  Trong khi đó Unmarshal của Go dễ lần theo hơn nhiều
  • Tôi lại cảm thấy các ngôn ngữ hàm và Rust rõ ràng hơn C hay Go
    Vì có thể đưa nhiều thông tin hơn vào trình biên dịch
    Chưa từng gặp vấn đề lớn với Serde, ngược lại còn phải debug Unmarshal của Go nhiều hơn
    Còn chuyện kernel từ chối Rust thì thực ra chỉ là xung đột giữa hai nhà phát triển về vị trí lưu header
  • C thì đơn giản, nhưng C vừa an toàn vừa hiệu năng cao thì cực kỳ phức tạp
    Rust có rào cản nhập môn cao hơn C, nhưng khoảng cách giữa “Rust tối thiểu” và “Rust nhanh và an toàn” nhỏ hơn C rất nhiều
  • Có người chỉ ra rằng dù nói Rust phức tạp, C cũng phức tạp không kém
  • Chính sự tiện lợi của các kiểm tra ở thời điểm biên dịch là điểm khác biệt của Rust
    Thậm chí được xem quan trọng ngang với borrow checker
  • Nếu đã có kinh nghiệm với Typescript, quen với việc dùng linter để xử lý tham chiếu hay unwrap Result/xử lý lỗi, thì Rust khá dễ học
    Cú pháp cũng khá dễ chịu
    Linux kernel thực tế không hề từ chối Rust