Chuyển đổi từ Go sang Rust: Hướng dẫn toàn diện cho lập trình viên Backend

Chuyển đổi từ Go sang Rust: Hướng dẫn toàn diện cho lập trình viên Backend

Trong số các dự án chuyển đổi ngôn ngữ lập trình mà tôi hỗ trợ, việc chuyển từ Go sang Rust luôn là một trường hợp đặc biệt. Vấn đề không nằm ở câu hỏi "Rust có nhanh hơn không?" hay "Rust có kiểu dữ liệu không?", bởi vì Go đã làm tốt những điều đó rồi. Thảo luận thực sự xoay quanh các đảm bảo về tính đúng đắn (correctness), sự đánh đổi tại runtime và trải nghiệm của nhà phát triển.

Biểu đồ sử dụng ngôn ngữ lập trình

Lưu ý nhỏ trước khi bắt đầu: hướng dẫn này tập trung chủ yếu vào backend. Đây là nơi Go mạnh nhất với các tệp nhị phân nhỏ gọn, thư viện chuẩn tập trung vào mạng và hệ sinh thái phong phú cho HTTP, gRPC, database... Đây cũng là nguồn gốc của các đội ngũ đang cân nhắc Rust, nên đó là sự so sánh thực tế nhất.

So sánh Toolchain: Go vs Rust

Các nhà phát triển Go đã có một trong những chuỗi công cụ (toolchain) sạch sẽ nhất trong ngành. Rust đã làm theo hướng dẫn đó với cargo, và thậm chí còn tích hợp sẵn nhiều tính năng hơn:

• Quản lý dự án: go.mod / go.sum tương đương với Cargo.toml / Cargo.lock.
• Xây dựng & Chạy: go build và go run tương đương với cargo build và cargo run.
• Testing & Linter: go test và go vet có các đối tác là cargo test và cargo clippy. Clippy thậm chí còn có "ý kiến" mạnh mẽ hơn vet.
• Định dạng: Cả hai cộng đồng đều thống nhất về một phong cách định dạng duy nhất để tránh tranh cãi. rustfmt và gofmt giúp loại bỏ các cuộc tranh luận về style trong code review.

Sự khác biệt lớn nhất là trong Go, bạn thường dùng các công cụ bên thứ ba để lấp đầy khoảng trống, trong khi hệ sinh thái đầu tiên của Rust bao phủ nhiều hơn out-of-the-box.

Tại sao các nhà phát triển Go lại quan tâm đến Rust?

Các nhà phát triển Go không chuyển sang Rust chỉ vì Go "quá chậm". Đối với hầu hết các khối lượng công việc backend, Go đã đủ nhanh. Mọi người thường thất vọng với việc xử lý lỗi dài dòng, nguy cơ lỗi phân khúc (segmentation faults) từ con trỏ nil, và sự thiếu hụt các tính năng kiểu dữ liệu tinh vi.

1. Nil Panics trong môi trường Production

Bạn triển khai một dịch vụ Go, nó chạy ổn định trong nhiều tháng, rồi đột nhiên một goroutine bị panic vì ai đó quên kiểm tra xem con trỏ có phải là nil không.

Trong Rust, Option buộc bạn phải xử lý trường hợp None. Bạn không thể hủy tham chiếu một Option mà không thừa nhận trường hợp thiếu dữ liệu. Toàn bộ các sự cố pager-duty thuộc loại này sẽ biến mất.

2. Data Races mà -race không bắt được

go test -race là một công cụ tuyệt vời, nhưng nó là một trình phát hiện tại runtime. Nó chỉ tìm ra các cuộc đua dữ liệu thực sự thực thi trong quá trình kiểm thử của bạn. Trong Rust, việc chia sẻ trạng thái có thể thay đổi (mutable state) giữa các luồng yêu cầu các kiểu dữ liệu triển khai Send và Sync. Nếu cố gắng chia sẻ HashMap thường giữa các luồng, chương trình sẽ không biên dịch. Điều kiện cuộc đua đó trở thành một lỗi kiểu dữ liệu.

3. Xử lý lỗi có thể kết hợp (Composable Error Handling)

Cấu trúc if err != nil { return err } thì ổn trong một thời gian, nhưng nó làm loãng logic thực tế của hàm. Trong Rust, toán tử ? xử lý việc lan truyền lỗi, và #[from] xử lý việc bao bọc lỗi. Một match trên enum lỗi được kiểm tra đầy đủ. Nếu bạn thêm một biến thể mới vào ngày mai, trình biên dịch sẽ chỉ cho bạn mọi nơi cần cập nhật.

4. Generics không bị Boxing

Go có generics từ phiên bản 1.18, nhưng chúng có các ràng buộc. Generics của Rust sử dụng monomorphization - mỗi phiên bản cụ thể tạo ra mã chuyên biệt với chi phí runtime bằng không. Kết hợp với traits, điều này mang lại cho bạn các trừu tượng hóa chi phí bằng thực sự.

So sánh trực tiếp các tính năng

Xử lý lỗi: if err != nil vs Result

Trong Go, việc kiểm tra lỗi là thủ công:

data, err := os.ReadFile(path)
if err != nil {
    return nil, fmt.Errorf("reading config: %w", err)
}

Trong Rust, toán tử ? thực hiện việc đó một cách ngắn gọn:

let data = fs::read_to_string(path)?;
let cfg = serde_json::from_str(&data)?;
Ok(cfg)

Null: nil vs Option

Go sử dụng nil rộng rãi, dẫn đến nguy cơ panic. Rust không có null trong vùng an toàn (safe Rust). Thay vào đó, nó sử dụng Option, buộc bạn phải xử lý trường hợp giá trị không tồn tại một cách rõ ràng.

Concurrency: Goroutines vs Async Tasks

Mô hình đồng thời của Go nổi tiếng là đơn giản với go doWork(). Không có sự phân biệt về mặt cú pháp giữa mã tuần tự và song song. Đây là lợi thế năng suất lớn nhất của Go so với Rust.

Rust sử dụng async/await trên một executor (thường là tokio):

tokio::spawn(async move {
    do_work(input).await;
});

Rust async mạnh mẽ hơn và được kiểm tra kỹ hơn, nhưng nó cũng rõ ràng hơn trong mã của bạn, và tính rõ ràng đó có chi phí ergonomic thực sự.

Thách thức khi chuyển đổi sang Rust

Borrow Checker

Đây là "bức tường" lớn nhất. Trong vài tuần đầu, bạn sẽ viết mã mà bạn nghĩ "rõ ràng là nó chạy được" nhưng trình biên dịch sẽ từ chối nó.

• Tham chiếu dài hạn: Trong Go, bạn có thể giữ *User từ một map bao lâu tùy thích. Trong Rust, việc mượn (borrow) đó sẽ chặn sự thay đổi của map trong suốt vòng đời của nó.
• Tự tham chiếu: Các struct giữ cả dữ liệu và iterator trên nó rất phổ biến trong Go nhưng rất khó trong Rust.

Tuy nhiên, Borrow Checker không phải là người gác cửa khó tính. Nó uncover ra các lỗi thực sự trong mã của bạn. Khi bạn nội hóa việc mượn, nó sẽ ngừng chống lại bạn và trở thành một đồng minh.

Thời gian biên dịch (Compile Times)

Thành thật với đội ngũ của bạn, thời gian biên dịch của Rust là một bước lùi so với Go. Một bản build release sạch của một dịch vụ trung bình có thể mất vài phút. Để giảm thiểu, hãy sử dụng cargo check trong vòng lặp chỉnh sửa và chia nhỏ dự án thành workspace.

Chiến lược tích hợp và Di chuyển

Bạn không cần phải viết lại mọi thứ cùng một lúc. Các chiến lược hiệu quả nhất bao gồm:

1. Tách riêng một Hot Path: Nếu một dịch vụ cụ thể luôn gặp vấn đề về CPU hoặc độ trễ, hãy viết lại chỉ dịch vụ đó bằng Rust, giữ nguyên hợp đồng API.
2. Thay thế Sidecar / Worker Process: Các worker nền, người tiêu dùng hàng đợi là mục tiêu tuyệt vời vì chúng có ranh giới đầu vào/đầu ra rõ ràng.
3. Mô hình Strangler: Nếu bạn có API gateway, hãy định tuyến các điểm cuối cụ thể đến dịch vụ Rust mới trong khi phần còn lại vẫn ở Go.

Khi nào nên giữ Go?

Không phải mọi thứ都应该 được chuyển đổi. Go xuất sắc cho:

• Công cụ gốc Kubernetes: operators, controllers. Hệ sinh thái áp đảo là Go.
• Tiện ích CLI và công cụ dev: Biên dịch nhanh, dễ cross-compilation.
• Dịch vụ keo (Glue services): Các lớp API mỏng. Tỷ lệ mã soạn (boilerplate) trong Rust không đáng giá ở đây.

Kết luận

Go là một ngôn ngữ thực dụng rất tốt, nhưng nó chết vì hàng ngàn vết cắt nhỏ. Ở một kích thước codebase nhất định, các vấn đề bắt đầu tích tụ. Các đội ngũ tìm thấy mình mong muốn nhiều hơn (an toàn hơn, kiểm soát nhiều hơn, biểu cảm hơn) và đó là lúc họ bắt đầu tìm kiếm các lựa chọn thay thế. Một chiến lược kết hợp (hybrid) là hoàn toàn hợp lý và phổ biến: Go cho các dịch vụ "nhàm chán", Rust cho các đường dẫn nóng quan trọng về hiệu suất.