What you need to know about Go, Rust, and Zig

Every language has a life cycle. Sometimes it starts with a relatively narrow use case and escapes its container; sometimes it’s intended as a general-purpose language but finds a powerful niche instead.

Over the last decade-plus, three new languages have emerged as attention getters in the software development space. In this article, we’ll look at what’s so special about each of these languages, and where they may be headed.

Go

With its relatively minimal syntax, simple paradigms, and convenient deployment tooling, the Go language, created by Google, has made it easier to write fast, compact programs that don’t require developers to think heavily about memory safety.

In the decade or so since its introduction, Go has found a few niches where it flourishes. Network or web services, particularly those with asynchronous behaviors, are easy to write in Go. It’s become a powerful alternative to Python in that respect. Go can scale to handle far more traffic than Python does, and with less effort. Applications delivered as standalone binaries, like command-line tools, are another good fit for Go. Compiled Go programs can run without external dependencies and can be built for every major platform.

Go’s biggest obstacles and developer complaints often stem from one of its chief selling points: the deliberate simplicity of the language. Go’s maintainers try to keep its syntax and feature set as unadventurous and unchanging as they can, with a goal of remaining forward-compatible.

But Go’s choices can also feel like a calculated snub of the powerful features that programming languages have gained over the past few decades. Generics were added to Go only very recently, and error handling is closer to C’s way of doing things than anything else. It’s a welcome attitude in a world of moving too fast and breaking too many things. It also enforces constraints on development, which may be difficult to outgrow for projects dependent on Go.

Rust

When a program needs both memory safety and speed, Rust is the language that regularly bubbles to the top of the list. Rust’s whole m.o. is delivering fast, machine-native code that can’t make whole classes of memory-safety errors, as they simply never make it into production.

The explosion of enthusiasm around Rust and its powers has left it with a wide realm of use cases. Most are server-side, cloud-computing, distributed-system, or network-centric apps—things once typically the domain of only Java or C++. It’s also found a strong presence in the WebAssembly world, as it can compile natively to WASM and thus be re-used in many other contexts.

The most newsworthy application of Rust, if not the most widely used, is in replacing C/C++ code in existing “brownfield” projects. The Linux kernel maintainers are working out (albeit with some difficulty) plans for including Rust code strategically in the kernel. This isn’t to edge out the use of C altogether, but rather to employ Rust where it’ll afford the biggest payoffs with the least additional maintenance burden (e.g., device drivers). The goal is to enhance memory safety without forcing Linux kernel C developers to retool in Rust if they don’t want to.

Some Linux kernel developers resist the move, citing common complaints about the language such as its steep learning curve and ahead-of-time complexity. Rust’s memory safety requires programmers to think ahead about how to satisfy the compiler’s demands, and adapting to that mindset is a common rite of passage for Rust newcomers. Plus, Rust projects often require dozens or hundreds of external dependencies that slow down compile times, an echo of similar sprawl in the world of JavaScript.

There’s no question about the demand for memory safety along with speed. The ideal would be a more streamlined version of Rust, or a new language that offered the same benefits without Rust’s conceptual overhead. For now, though, there’s no question Rust has galvanized a generation of developers who want what it offers.

Zig

Andrew Kelley’s one-man programming language project, launched in 2015, is positioned as both a complement and a competitor to C. Zig aims at much the same space as C: the world of low-level, non-garbage-collected, portable languages. Zig also compiles to the same kinds of targets as C, including WebAssembly.

Unlike C, though, Zig has native features to make it easier to write memory-safe low-level code. And unlike Rust—the other major language in this space—Zig does not require programmers to work so hard for the sake of correctness. Memory management is done manually, but the language provides more syntactical tooling than C does for handling memory. One example is Zig’s defer statement, used to clean up resources at the end of a scope. Many common runtime issues like integer overflow are trapped by default and can be granularly overridden (albeit only in a given scope), but the default is toward safety.

One way Zig aims to replace C is by integrating elegantly with it—by sitting side-by-side and even using C’s own libraries. This gives those developing C applications a transition path to Zig that doesn’t require scrapping and redoing everything. The Zig compiler can even function as a C compiler, and can build Zig libraries with C ABIs to allow C to use Zig code.

Zig’s biggest obstacles are typical for any new language. The language itself is in flux (its current version is 0.15), with potential breaking changes at any point along the way. The legacy world it aims to displace—the C “cinematic universe”—is also immensely entrenched, comprising not just the language but the development culture of C.

Another barrier common to new languages—tooling in common editors and IDEs—seems to be dissolving quickly, however. A Zig add-on in Visual Studio Code provides the compiler itself, not just a language server, as an easily integrated component to the editor.