Why Zig When There is Already C++, D, and Rust?<br>Zig Programming Language

Download

Learn

News

Source<br>Join a Community

ZSF

Devlog

← Back to<br>Learn

Why Zig When There is Already C++, D, and Rust?

No hidden control flow<br>If Zig code doesn’t look like it’s jumping away to call a function, then it isn’t. This means you can be sure that the following code calls only foo() and then bar(), and this is guaranteed without needing to know the types of anything:<br>var a = b + c.d;<br>foo();<br>bar();

Examples of hidden control flow:<br>D has @property functions, which are methods that you call with what looks like field access, so in the above example, c.d might call a function.<br>C++, D, and Rust have operator overloading, so the + operator might call a function.<br>C++, D, and Go have throw/catch exceptions (sometimes also called panic/recover), so foo() might throw an exception, and prevent bar() from being called. (Of course, even in Zig foo() could deadlock and prevent bar() from being called, but that can happen in any Turing-complete language.)<br>The purpose of this design decision is to improve readability.<br>No hidden allocations<br>Zig has a hands-off approach when it comes to heap allocation. There is no new keyword or any other language feature that uses a heap allocator (e.g. string concatenation operator[1]). The entire concept of the heap is managed by library and application code, not by the language.<br>Examples of hidden allocations:<br>Go’s defer allocates memory to a function-local stack. In addition to being an unintuitive way for this control flow to work, it can cause out-of-memory failures if you use defer inside a loop.<br>C++ coroutines allocate heap memory in order to call a coroutine.<br>In Go, a function call can cause heap allocation because goroutines allocate small stacks that get resized when the call stack gets deep enough.<br>The main Rust standard library APIs panic on out of memory conditions, and the alternate APIs that accept allocator parameters are an afterthought (see rust-lang/rust#29802).<br>Nearly all garbage collected languages have hidden allocations strewn about, since the garbage collector hides the evidence on the cleanup side.<br>The main problem with hidden allocations is that it prevents the reusability of a piece of code, unnecessarily limiting the number of environments that code would be appropriate to be deployed to. Simply put, there are use cases where one must be able to rely on control flow and function calls not to have the side-effect of memory allocation, therefore a programming language can only serve these use cases if it can realistically provide this guarantee.<br>In Zig, there are standard library features that provide and work with heap allocators, but those are optional standard library features, not built into the language itself. If you never initialize a heap allocator, you can be confident your program will not heap allocate.<br>Every standard library feature that needs to allocate heap memory accepts an Allocator parameter in order to do it. This means that the Zig standard library supports freestanding targets. For example std.ArrayList and std.AutoHashMap can be used for bare metal programming!<br>Custom allocators make manual memory management a breeze. Zig has a debug allocator that maintains memory safety in the face of use-after-free and double-free. It automatically detects and prints stack traces of memory leaks. There is an arena allocator so that you can bundle any number of allocations into one and free them all at once rather than manage each allocation independently. Special-purpose allocators can be used to improve performance or memory usage for any particular application’s needs.<br>[1]: Actually there is a string concatenation operator (generally an array concatenation operator), but it only works at compile time, so it still doesn’t do any runtime heap allocation.<br>First-class support for no standard library<br>As hinted above, Zig has an entirely optional standard library. Each std lib API only gets compiled into your program if you use it. Zig has equal support for either linking against libc or not linking against it. Zig is friendly to bare-metal and high-performance development.<br>It’s the best of both worlds; for example in Zig, WebAssembly programs can both use the normal features of the standard library, and still result in the tiniest binaries when compared to other programming languages that support compiling to WebAssembly.<br>A Portable Language for Libraries<br>One of the holy grails of programming is code reuse. Sadly, in practice, we find ourselves re-inventing the wheel many times over again. Often it’s justified.<br>If an application has real-time requirements, then any library that uses garbage collection or any other non-deterministic behavior is disqualified as a dependency.<br>If a language makes it too easy to ignore errors, and thus hard to verify that a library correctly handles and bubbles up errors, it can be tempting to ignore the library and re-implement it,...