Vì sao Rust được chọn để hiện thực hội nghị video 3K, 60fps, 130ms

Chia sẻ về quá trình hiện thực hội nghị video "thời gian thực" của Tonari

→ Độ trễ của Zoom và WebRTC là 315-500ms

Thay vì động vào 750 nghìn dòng của stack WebRTC để đạt mức độ trễ 130ms gần như thời gian thực, họ quyết định thiết kế toàn bộ stack từ đầu theo đúng phần cứng mong muốn và hiện thực lại

→ Chọn Rust vì bảo mật, hiệu năng và khả năng bảo trì

Các crate được dùng chủ yếu

→ Những thứ tốt hơn thư viện chuẩn: crossbeam, parking_lot, bytes, socket2

→ Làm log và CLI đẹp hơn: fern, structopt

→ Công cụ hỗ trợ cargo: cargo-release, cargo-udeps, cargo tree, cargo-geiger, cargo-flamegraph

Những điểm khó của Rust

• Thời gian biên dịch dài

• Độ bao phủ của thư viện còn thiếu

• Yêu cầu viết mã chính xác và rõ ràng ngay từ đầu

• Bộ suy luận kiểu quá mạnh, đôi khi tạo cảm giác như đang dùng ngôn ngữ kiểu động

• Ngôn ngữ vẫn đang tiếp tục phát triển

Kết quả của việc chọn Rust

• Không gặp downtime liên quan đến phần mềm

• Có thể dễ dàng viết mã hiệu năng tốt nhờ sử dụng tài nguyên hiệu quả

• Mức sử dụng CPU và bộ nhớ đều có thể dự đoán và nhất quán

• Bảo đảm độ trễ và tốc độ khung hình ổn định

• Trải nghiệm bảo trì codebase cũng rất tốt

• Cuối cùng đã tạo ra được một sản phẩm đáng tin cậy, có thể bảo trì, với hiệu năng nhanh về tốc độ khung hình, độ trễ và hiệu quả tài nguyên

→ Nếu không có Rust thì có lẽ rất khó làm được