Đã đăng vào khoảng 3 giờ trước 10 phút đọc

Go có thay thế được Rust không? Nhìn từ “khoảng cách vật lý” ở tầng runtime

Trong thế giới backend, tranh luận Go vs Rust chưa bao giờ hết nhiệt. Nhiều người hỏi: với hiệu suất đủ tốt và tốc độ phát triển nhanh như Go, còn cần gì tới Rust với đường cong học tập gắt như vậy? Thậm chí có người tin rằng khi phần cứng ngày càng mạnh, Go sẽ “bao” luôn vùng sinh thái của Rust.

Nhưng nếu bóc hết cú pháp và sugar bên ngoài, đi sâu vào compiler và runtime, sẽ thấy Go và Rust có một hố ngăn vật lý không thể bước qua. Vấn đề không phải ở “ngôn ngữ nào mạnh hơn”, mà là chúng sinh ra để giải quyết các lớp bài toán khác nhau.

Garbage Collector: bức tường vô hình của Go

Go được thiết kế để giải quyết bài toán software engineering ở quy mô Google: build service nhanh, code dễ đọc, dễ bảo trì. GC (garbage collector) là một phần cốt lõi của triết lý đó:

Tự động quản lý cấp phát/giải phóng bộ nhớ.
Giảm rất nhiều gánh nặng mental cho dev backend, viết web service cực “ngọt”.

Nhưng chính GC cũng là giới hạn cứng của Go:

Dù thuật toán có tối ưu mấy, GC vẫn phải quét heap định kỳ, tiêu tốn CPU.
Điều này luôn kéo theo độ trễ dao động (latency jitter) ở mức micro–millisecond.
Với web service bình thường, vài ms jitter không phải vấn đề; với hệ thống hard real‑time lại là chuyện khác.

Trong các scenario như:

Điều khiển robot công nghiệp.
Hệ thống high‑frequency trading.
Kernel, hypervisor, hoặc engine cực nhạy với timing.

…việc runtime thỉnh thoảng “ghé qua dọn rác” là điều không thể chấp nhận.

Rust chọn con đường hoàn toàn khác:

Dùng ownership + borrow checker để giải quyết vòng đời dữ liệu ngay ở compile time.
Binary Rust không có GC, không cần pause để dọn rác.
Dev có thể kiểm soát bộ nhớ và chu kỳ CPU gần như C/C++.[web:356][web:359][web:364]

Chính sự xác định (determinism) này khiến Rust đặt chân vào những vùng mà GC – và theo đó là Go – rất khó bước vào, bất kể GC có “nhanh và real‑time” tới đâu.[web:361][web:365]

Runtime cồng kềnh & nỗi đau FFI

Go binary thường khá “béo” vì phải mang theo một runtime tương đối phức tạp:

Scheduler cho goroutine.
Bộ cấp phát bộ nhớ và GC.
Quản lý stack, signal, và nhiều dịch vụ runtime khác.

Khi toàn bộ hệ thống đều viết bằng Go, đây là món quà: dev không phải tự build scheduler hay allocator.
Nhưng khi bạn muốn:

Đóng gói code Go thành shared library cho C/C++/Python gọi.
Embed Go vào một hệ thống native đã có từ trước.

…thì runtime lại trở thành gánh nặng:

Thủ tục init phức tạp.
Mô hình concurrency của Go có thể vênh với threading model của host.
cgo phải switch giữa goroutine stack và OS thread stack, rất tốn kém nếu call trong tight loop.

Rust đi theo triết lý zero‑cost abstractions:

Hàm Rust có thể compile thành machine code “trần trụi” giống C.
Giao tiếp FFI với C có thể gần như không overhead nếu thiết kế đúng.
Không drag theo runtime nặng nề, nên embed Rust vào C/Python/Node.js khá tự nhiên.

Vì vậy Rust cực hợp để:

Viết hạ tầng lõi (database engine, storage, compute engine…).
Viết module hiệu năng cao cho Python/Node.js mà không phải chấp nhận “thuế runtime” lớn.

Góc nhìn code: concurrency của Go vs Rust

Giả sử cần chạy một tác vụ đơn giản: tạo 3 đơn vị chạy song song, mỗi cái sleep một chút rồi in ra ID.

Go: trực quan, tối ưu cho service

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    var wg sync.WaitGroup

    for i := 0; i < 3; i++ {
        wg.Add(1)
        // Truyền i vào arg để tránh vấn đề capture biến vòng lặp
        go func(id int) {
            defer wg.Done()
            time.Sleep(100 * time.Millisecond)
            fmt.Printf("Go goroutine [%d] finished\n", id)
        }(i)
    }

    wg.Wait()
    fmt.Println("Main flow finished")
}

Ưu điểm:

Cú pháp gọn, rất “backend friendly”.
Kết hợp goroutine + channel + WaitGroup → code concurrency dễ đọc, dễ scale.

Rust: tường minh, ưu tiên an toàn & xác định

use std::thread;
use std::time::Duration;

fn main() {
    let mut tasks = vec![];

    for i in 0..3 {
        // move chuyển ownership của i vào thread
        let handle = thread::spawn(move || {
            thread::sleep(Duration::from_millis(100));
            println!("Rust thread [{}] finished", i);
        });
        tasks.push(handle);
    }

    // Join tất cả thread
    for task in tasks {
        task.join().unwrap();
    }

    println!("Main flow finished");
}

Rust bắt bạn:

Luôn nghĩ về ownership khi spawn thread.
Rõ ràng về nơi dữ liệu sống và chết, loại bỏ data race từ compile time.[web:359][web:364]

Tóm lại:

Go tối ưu tốc độ triển khai và throughput cho service thường.
Rust tối ưu kiểm soát & an toàn cho những phần low‑level, nơi lỗi nhỏ cũng trả giá đắt.

Kiến trúc lai: Go + Rust cùng tồn tại

Chính vì thế mạnh bổ sung, kiến trúc hiện đại thường không “chọn 1 bỏ 1” mà dùng cả 2:

Dùng Go cho: API gateway, service layer, job worker – nơi tốc độ build và maintain quan trọng nhất.
Dùng Rust cho: module xử lý nặng (ảnh, video, mã hóa), engine lưu trữ, task yêu cầu latency cực thấp.

Mặt kỹ thuật thì hợp lý, nhưng nó kéo theo một nỗi đau mới: môi trường dev hỗn loạn.

Trên một máy dev:

Vừa cần Go cũ (1.16) cho microservice legacy, vừa cần Go mới (1.22) cho dự án mới.
Vừa cần rust environment với stable, lại vừa muốn thử nightly cho feature experimental.
Thêm vào đó là PostgreSQL, Redis, MongoDB… cho integration test.

Tự xoay bằng:

Sửa PATH thủ công.
Cài/uninstall compiler, toolchain.
Giải quyết dependency & linker error lặt vặt.

…rất dễ phá vỡ flow, và khi đã “phá môi trường” rồi, khôi phục lại tốn rất nhiều thời gian.

Để công cụ chịu phức tạp, dev giữ sự tập trung

Với bối cảnh multi‑language, multi‑version, có một trình quản lý local dev environment tử tế gần như là bắt buộc.

ServBay được thiết kế đúng cho kiểu bài toán này:

Nó không phải VM, cũng không đơn thuần là container, mà là một bộ quản lý môi trường dev cục bộ tích hợp nhiều ngôn ngữ và dịch vụ.
Mục tiêu là: cài xong là chạy, không làm bẩn hệ điều hành.

Ba điểm chạm quan trọng:

1. Một click dựng môi trường Go + Rust

Không cần tải installer riêng, không phải mò PATH hay config compiler:

Tạo nhanh môi trường Go đầy đủ toolchain.
Bật luôn một rust environment với rustc, cargo, và dependency cần cho dự án.

2. Cách ly và cho nhiều version cùng sống

Đây là điểm “ăn tiền”:

Có thể chạy song song Go 1.18 và Go 1.22 trên cùng máy, mỗi project map vào bản riêng.
Rust cũng có thể tách theo project, tránh chuyện cập nhật toolchain cho dự án A làm hỏng dự án B.

Không còn cảnh “nâng version cho một service, ba service khác gãy theo”.

3. Quản lý thống nhất cho ngôn ngữ + dịch vụ

Ngoài Go và Rust, ServBay còn:

Hỗ trợ Node.js, PHP, Python… và nhiều runtime khác.
Tích hợp database như PostgreSQL, MySQL, MongoDB, Redis trong cùng UI.
Cho phép xem log, bật/tắt service, chỉnh port ở một nơi.

Tóm lại: nó biến những thứ “mùi infra” thành một phần yên lặng trong nền, để dev quay lại việc viết code.

Kết

Quay lại câu hỏi ban đầu: tại sao Go không thể thay thế Rust?

Vì:

Go sinh ra để giải quyết bài toán năng suất và đơn giản hóa backend.
Rust sinh ra để giải quyết bài toán kiểm soát cực chi tiết và an toàn ở tầng thấp.

Chúng không đứng trên cùng một trục để “hơn/thua”, mà nằm ở hai lớp khác nhau trong hệ thống. Tương lai hợp lý không phải “pick one”, mà là “Go và Rust cùng tồn tại”.

Trong bức tranh đó:

Dùng Go nơi cần ship nhanh, scale tốt, latency “hợp lý là đủ”.
Dùng Rust nơi từng microsecond và từng byte bộ nhớ đều quan trọng.
Dùng một công cụ quản lý local dev environment tốt, với rust environment được cấu hình sẵn, để bạn có thể chuyển qua lại giữa Go và Rust mà không lo “chân mình đứng trên cát lún”.

Công nghệ nên là nền móng chắc chắn để bạn xây ý tưởng, không phải là thứ khiến bạn mất nửa ngày để sửa lỗi môi trường rồi… quên mất mình định làm gì lúc đầu.