How I Transitioned from Go to Rust: Lessons Learned

I have been writing Go code for over five years, and my first encounter with Rust came when a colleague built a small tool for flashing Raspberry Pi devices using an A/B partition scheme. I was initially skeptical, wondering why another language was needed.

Why I chose Rust for the rewrite

Two concrete reasons pushed me to rewrite the CLI and the associated services in Rust:

Messaging: Our services communicate via many mpsc and mpmc channels. While Go’s chan handles simple mpsc easily, Rust offers a crate that satisfies the more complex mpmc requirements.

Memory control: The services run on devices with limited RAM. Go’s garbage collector gives little control over when memory is reclaimed, whereas Rust’s compile‑time ownership guarantees let me manage memory explicitly, similar to C/C++ but with safety checks.

Implementation details

To generate code from .proto files I used the prost crate, which worked smoothly. For the command‑line interface I relied on clap, and for asynchronous execution I adopted tokio, which made async code (mostly) manageable.

During the migration I faced several Rust‑specific challenges:

Strict compiler: The compiler emitted many detailed error messages that required time to read and understand.

Missing return : Rust functions return the value of the final expression, so explicit return statements are often unnecessary.

Macros like #[derive(...)] : Understanding how derive macros generate code took some effort.

Borrow checker and lifetimes: Managing lifetimes for async futures and ensuring values are moved or borrowed correctly added a steep learning curve.

Async intricacies: Combining generics with async sometimes produced confusing error messages.

What I gained

No null‑pointer panics: Rust’s Option<T> forces handling of absent values, eliminating a class of bugs I frequently fixed in Go.

Explicit error handling: Result<T, E> makes error propagation clear, e.g. let val = do_thing()?; versus the verbose Go pattern with if err != nil { return err }.

Powerful pattern matching: The match construct provides exhaustive handling of cases.

Rich ecosystem: Cargo, crates.io, and the standard library offered the libraries I needed more readily than I expected.

Built‑in testing: Writing tests alongside source files felt natural.

Remaining drawbacks

Async, borrow checking, and lifetimes can still be hard to manage together.

Features like Box / Pin remain less familiar.

When many dependencies are involved, Rust’s build times can be long, similar to Go’s.

Simple programs are quicker to prototype in Go; Rust often requires more upfront setup.

Team perspective

Introducing Rust into a Go‑centric stack is not trivial, especially for a company that has heavily invested in its existing tooling. Nevertheless, the Rust‑written services proved extremely stable in production, requiring almost no maintenance after deployment. The rise of LLM‑generated code lowers the entry barrier, but solid understanding of the borrow checker, lifetimes, and async executors remains essential.

Would I do it again?

Absolutely—though it isn’t the right choice for every project. If Go can accomplish the task, stick with Go. When memory control, production stability, or low‑level hardware interaction are critical, Rust is the better option.

Practical advice

Before diving in, master Rust’s memory model, the borrow checker, and lifetimes. Learn the async runtime (e.g., tokio) and how Future s work. Read the official book and experiment in the Playground. Then start coding, using your own judgment rather than relying solely on LLM suggestions.

val, err := doThing()
if err != nil {
    return err
}

let val = do_thing()?;