Rust_vs_Go

In less than a decade, two new programming languages have emerged as major options for enterprise development: Go, which was created at Google, and Rust, which was created at Mozilla.

Both languages offer indispensable features for modern software development: a sophisticated and integrated toolchain, memory safety, an open source development model, and strong communities of users.

Apart from those similarities, Rust and Go are dramatically different. They were built to scratch different itches, fulfill different demands, and write different kinds of programs.

Thus, comparing Rust and Go isn’t about which language is “objectively better,” but about which language is best for a given programming task. With that in mind, let’s look at the main ways Rust and Go differ, and the kinds of work each is best suited for.

Rust vs. Go: Performance

On the list of Rust’s major advantages, performance ranks right at the top with safety and ease, and may be the number-one item. Rust programs are designed to run at or near the speed of C and C++, thanks to Rust’s zero-cost runtime abstractions for memory handling and processing.

It’s always possible to write a slow Rust program, but at least you can be sure that Rust is not preemptively sacrificing performance for safety or convenience. What Rust does cost is an effort on the part of the developer to learn and master the language’s abstractions for memory management. (More on memory management below.)

Go, by contrast, does trade some runtime speed for developer convenience. Memory management is handled by the Go runtime (again, more below), so there is an inevitable amount of runtime-associated overhead. But for many scenarios, this trade-off is negligible. Go is by default many times faster than other languages of convenience (e.g., Python).

In short, Rust is faster overall, but for most workaday use cases the difference in speed between Rust and Go will be marginal. In cases where performance is an absolute requirement, Rust can excel in ways that Go cannot.

Rust vs. Go: Memory management

Memory management in Rust and Go are strongly related to the performance behaviors in both languages.

Rust uses compile-time ownership strategies for memory management by way of zero-cost abstractions. This means the vast majority of memory management issues can be caught before a Rust program ever goes live. If a Rust program isn’t memory safe, then it doesn’t compile. Given how much of our world is built atop software that is routinely found to be unsafe due to bad memory management, the Rust approach is way overdue.

As noted above, this safety comes at the cost of Rust’s more challenging learning curve: Programmers must know how to use Rust’s memory management idioms properly, and that requires time and practice. Developers coming from the worlds of C, C++, C#, or Java must rethink how they write code when they sit down with Rust.

Like Rust, Go is memory safe, but that’s because memory management is handled automatically at runtime. Programmers can write thousands of lines of Go code and never once have to think about allocating or releasing memory. Programmers do have some control over the garbage collector at runtime. You can change garbage collection thresholds or trigger collections manually to prevent garbage collection cycles from interfering with operations.

Programmers can also perform some manual memory management in Go, but the language deliberately stacks the deck against doing so. For instance, you can use pointers to access variables, but you can’t perform pointer arithmetic to access arbitrary areas of memory unless you use the unsafe package, an unwise choice for software that runs in production.

If the programming task at hand requires you to allocate and release memory manually—e.g., for low-level hardware or maximum-performance scenarios—Rust is designed to accommodate those needs. Nevertheless, don’t assume that Go’s automatic memory management disqualifies it from creating robust software for your task.

Rust vs. Go: Development speed

Sometimes development speed is more important than program speed. Python has made a career out of being not-the-fastest language to run, but among the fastest languages to write software in. Go has the same appeal; its directness and simplicity make for a speedy development process. Compile times are short, and the Go runtime is faster than Python (and other interpreted, developer-friendly languages) by orders of magnitude.

In short, Go offers both simplicity and speed. So what’s missing? Some features found in other languages (e.g., generics) have been omitted to make the language easier to learn, easier to master, and easier to maintain. The downside is that some programming tasks aren’t possible without a fair amount of boilerplate.

Rust has more language features than Go, and it takes longer to learn and master. Rust’s compile times also tend to be longer than equivalent Go programs, especially for applications with large dependency trees. This remains true even after a concerted effort by the Rust project to shorten compile times.

If a fast development cycle and the need to bring people on board a project quickly are top priorities, Go is the better choice. If you’re less concerned about development speed, and more concerned with memory safety and execution speed, pick Rust.

Rust vs. Go: Concurrency and parallelism

Modern hardware is multi-core, and modern applications are networked and distributed. Languages that don’t plan for these realities are behind the curve. Programmers need to be able to run tasks independently, whether on a single thread or multiple threads, and to share state between tasks without risking data corruption. Rust and Go both provide ways to do this.

Concurrency was baked into the Go language’s syntax from the beginning, by way of goroutines (lightweight threads) and channels (communication mechanisms for goroutines). These primitives make it easy to write applications (such as network services) that must handle many tasks concurrently without risking common issues like race conditions. Go doesn’t make race conditions impossible, but provides native test mechanisms to warn the programmer if race conditions could occur at runtime.

Rust only recently gained native concurrency syntax, in the form of the async/``.await keywords. Before async/.await, concurrency came by way of a crate or package for Rust called futures. Although Rust’s concurrency lacks the years of consolidated developer experience behind Go’s concurrency, it inherits the advantage of Rust’s memory safety—that is, Rust code that could expose race conditions simply won’t compile. Concurrent or asynchronous operations will be harder to write in Rust, due to Rust’s syntax rules, but it will be durable in the long run.

Rust vs. Go: Interoperability with legacy code

New languages like Rust and Go aim for memory safety and programmer convenience in ways that earlier languages didn’t fathom. But the new always has to co-exist to some degree with the old. To that end, Rust and Go both interoperate with legacy C code, although with different restrictions in each case.

Rust can talk directly to C libraries by way of the extern keyword and the libc “crate” (Rust’s name for a package), but all calls to such libraries have to be tagged as unsafe. In other words, Rust can’t guarantee their memory or thread safety; you need to manually ensure that interfaces to C code are safe. Calling into C++ code, on the other hand, isn’t supported at all (at least, not yet) unless said code has a C-compatible interface. Many examples of how to wrap code with Rust’s FFI (Foreign Function Interface)—for C and other languages—can be found at the Rust FFI Omnibus website.

Go provides the cgo package for working with C. The cgo package allows you to call into C libraries, use C header files in your Go code, and convert common data types between C and Go (e.g., strings). However, because Go is memory-managed and garbage-collected, you have to ensure that any pointers you pass to C are handled correctly.

In short, Rust is slightly friendlier regarding C interop than Go, so anything with major dependencies on existing C may tip the scale toward Rust. In both Rust and Go, though, interoperability with C comes at some cost to the developer: more conceptual overhead, slower compile times, more complex tooling, harder debugging.

Note that Rust and Go can always interface with other code at higher levels—e.g., exchanging data via network sockets or named pipes rather than function calls—but these alternatives come at the cost of speed.

Rust vs. Go: Summing up

Choosing between Rust and Go for a software development project is mainly about picking the language that has the qualities you need most for that project. For Rust and Go, you can sum up those qualities as follows.

Rust advantages:

• Correctness at runtime (common mistakes simply don’t compile)
• Top-tier execution speed
• Memory safety without garbage collection
• Hardware-level code

Go advantages:

• Quick development cycles
• High-tier execution speed
• Memory safety by way of garbage collection
• Developer convenience
• Straightforward code