In this chapter, I want to introduce you to the world of Zig. Zig is a very young language that is being actively developed. As a consequence, its world is still very wild and to be explored. This book is my attempt to help you on your personal journey for understanding and exploring the exciting world of Zig.

I assume you have previous experience with some programming language in this book, not necessarily with a low-level one. So, if you have experience with Python, or Javascript, for example, it will be fine. But, if you do have experience with low-level languages, such as C, C++, or Rust, you will probably learn faster throughout this book.

What is Zig?

Zig is a modern, low-level, and general-purpose programming language. Some programmers think of Zig as a modern and better version of C.

In the author’s personal interpretation, Zig is tightly connected with “less is more”. Instead of trying to become a modern language by adding more and more features, many of the core improvements that Zig brings to the table are actually about removing annoying behaviours/features from C and C++. In other words, Zig tries to be better by simplifying the language, and by having more consistent and robust behaviour. As a result, analyzing, writing and debugging applications become much easier and simpler in Zig, than it is in C or C++.

This philosophy becomes clear with the following phrase from the official website of Zig:

“Focus on debugging your application rather than debugging your programming language knowledge”.

This phrase is specially true for C++ programmers. Because C++ is a gigantic language, with tons of features, and also, there are lots of different “flavors of C++”. These elements are what makes C++ so complex and hard to learn. Zig tries to go in the opposite direction. Zig is a very simple language, more closely related to other simple languages such as C and Go.

The phrase above is still important for C programmers too. Because, even C being a simple language, it’s still hard sometimes to read and understand C code. For example, pre-processor macros in C are a frequent source of confusion. Sometimes, they really make it hard to debug C programs. Because macros are essentially a second language embedded in C that obscures your C code. With macros, you are no longer 100% sure about which pieces of the code are being sent to the compiler, i.e. they obscure the actual source code that you wrote.

You don’t have macros in Zig. In Zig, the code you write, is the actual code that gets compiled by the compiler. You also don’t have a hidden control flow happening behind the scenes. And, you also don’t have functions or operators from the standard library that make hidden memory allocations behind your back.

By being a simpler language, Zig becomes much more clear and easier to read/write, but at the same time, it also achieves a much more robust state, with more consistent behaviour in edge situations. Once again, less is more.

Hello world in Zig

We begin our journey in Zig by creating a small “Hello World” program. To start a new Zig project in your computer, you simply call the init command from the zig compiler. Just create a new directory in your computer, then, init a new Zig project inside this directory, like this:

mkdir hello_world
cd hello_world
zig init

info: created build.zig
info: created build.zig.zon
info: created src/main.zig
info: created src/root.zig
info: see `zig build --help` for a menu of options

Understanding the project files

After you run the init command from the zig compiler, some new files are created inside of your current directory. First, a “source” (src) directory is created, containing two files, main.zig and root.zig. Each .zig file is a separate Zig module, which is simply a text file that contains some Zig code.

By convention, the main.zig module is where your main function lives. Thus, if you are building an executable program in Zig, you need to declare a main() function, which represents the entrypoint of your program, i.e., where the execution of your program begins.

However, if you are building a library (instead of an executable program), then, the normal procedure is to delete this main.zig file and start with the root.zig module. By convention, the root.zig module is the root source file of your library.

tree .

.
├── build.zig
├── build.zig.zon
└── src
├── main.zig
└── root.zig

1 directory, 4 files

The init command also creates two additional files in our working directory: build.zig and build.zig.zon. The first file (build.zig) represents a build script written in Zig. This script is executed when you call the build command from the zig compiler. In other words, this file contains Zig code that executes the necessary steps to build the entire project.

Low-level languages normally use a compiler to build your source code into binary executables or binary libraries. Nevertheless, this process of compiling your source code and building binary executables or binary libraries from it, became a real challenge in the programming world, once the projects became bigger and bigger. As a result, programmers created “build systems”, which are a second set of tools designed to make this process of compiling and building complex projects, easier.

Examples of build systems are CMake, GNU Make, GNU Autoconf and Ninja, which are used to build complex C and C++ projects. With these systems, you can write scripts, which are called “build scripts”. They simply are scripts that describes the necessary steps to compile/build your project.

However, these are separate tools, that do not belong to C/C++ compilers, like gcc or clang. As a result, in C/C++ projects, you have not only to install and manage your C/C++ compilers, but you also have to install and manage these build systems separately.

In Zig, we don’t need to use a separate set of tools to build our projects, because a build system is embedded inside the language itself. We can use this build system to write small scripts in Zig, which describe the necessary steps to build/compile our Zig project1. So, everything you need to build a complex Zig project is the zig compiler, and nothing more.

The second generated file (build.zig.zon) is a JSON-like file, in which you can describe your project, and also, declare a set of dependencies of your project that you want to fetch from the internet. In other words, you can use this build.zig.zon file to include a list of external libraries in your project.

One possible way to include an external Zig library in your project, is to manually build and install the library in your system, and just link your source code with the library at the build step of your project.

However, if this external Zig library is available on GitHub for example, and it has a valid build.zig.zon file in the root folder of the project, which describes the project, you can easily include this library in your project by simply listing this external library in your build.zig.zon file.

In other words, this build.zig.zon file works similarly to the package.json file in Javascript projects, or the Pipfile file in Python projects, or the Cargo.toml file in Rust projects. You can read more about this specific file in a couple of articles on the internet23, and you can also see the expected schema for this build.zig.zon file in a documentation file inside the official repository of Zig4.

The file root.zig

Let’s take a look into the root.zig file. You might have noticed that every line of code with an expression ends with a semicolon (;). This follows the syntax of a C-family programming language5.

Also, notice the @import() call at the first line. We use this built-in function to import functionality from other Zig modules into our current module. This @import() function works similarly to the #include pre-processor in C or C++, or, to the import statement in Python or Javascript code. In this example, we are importing the std module, which gives you access to the Zig Standard Library.

In this root.zig file, we can also see how assignments (i.e., creating new objects) are made in Zig. You can create a new object in Zig by using the syntax (const|var) name = value;. In the example below, we are creating two constant objects (std and testing). In Section 1.4 we talk more about objects in general.

const std = @import("std");
const testing = std.testing;

export fn add(a: i32, b: i32) i32 {
return a + b;
}

Functions in Zig are declared using the fn keyword. In this root.zig module, we are declaring a function called add(), which has two arguments named a and b. The function returns an integer of the type i32 as result.

Zig is a strongly-typed language. There are some specific situations where you can (if you want to) omit the type of an object in your code, if this type can be inferred by the zig compiler (we talk more about that in Section 2.4). But there are other situations where you do need to be explicit. For example, you do have to explicitly specify the type of each function argument, and also, the return type of every function that you create in Zig.

We specify the type of an object or a function argument in Zig by using a colon character (:) followed by the type after the name of this object/function argument. With the expressions a: i32 and b: i32, we know that both a and b arguments have type i32, which is a signed 32 bit integer. In this part, the syntax in Zig is identical to the syntax in Rust, which also specifies types by using the colon character.

Lastly, we have the return type of the function at the end of the line, before we open the curly braces to start writing the function’s body. In the example above, this type is also a signed 32 bit integer (i32) value.

Notice that we also have an export keyword before the function declaration. This keyword is similar to the extern keyword in C. It exposes the function to make it available in the library API. Therefore, if you are writing a library for other people to use, you have to expose the functions you write in the public API of this library by using this export keyword. If we removed the export keyword from the add() function declaration, then, this function would be no longer exposed in the library object built by the zig compiler.

The main.zig file

Now that we have learned a lot about Zig’s syntax from the root.zig file, let’s take a look at the main.zig file. A lot of the elements we saw in root.zig are also present in main.zig. But there are some other elements that we haven’t seen yet, so let’s dive in.

First, look at the return type of the main() function in this file. We can see a small change. The return type of the function (void) is accompanied by an exclamation mark (!). This exclamation mark tells us that this main() function might return an error.

It’s worth noting that, a main() function in Zig is allowed to return nothing (void), or an unsigned 8-bit integer (u8) value6, or an error. In other words, you can write your main() function in Zig to return essentially nothing (void), or, if you prefer, you can also write a more C-like main() function, which returns an integer value that usually serves as a “status code” for the process.

In this example, the return type annotation of main() indicates that this function can either return nothing (void), or return an error. This exclamation mark in the return type annotation is an interesting and powerful feature of Zig. In summary, if you write a function and something inside the body of this function might return an error, then, you are forced to:

• either add the exclamation mark to the return type of the function and make it clear that this function might return an error.
• explicitly handle this error inside the function.

In most programming languages, we normally handle (or deal with) an error through a try catch pattern. Zig does have both try and catch keywords. But they work a little differently than what you’re probably used to in other languages.

If we look at the main() function below, you can see that we do have a try keyword on the 5th line. But we do not have a catch keyword in this code. In Zig, we use the try keyword to execute an expression that might return an error, which, in this example, is the stdout.print() expression.

In essence, the try keyword executes the expression stdout.print(). If this expression returns a valid value, then, the try keyword does absolutely nothing. It only passes the value forward. It’s like if this try keyword was never there. However, if the expression does return an error, then, the try keyword will unwrap the error value, then, it returns this error from the function and also prints the current stack trace to stderr.

This might sound weird to you if you come from a high-level language. Because in high-level languages, such as Python, if an error occurs somewhere, this error is automatically returned and the execution of your program will automatically stop even if you don’t want to stop the execution. You are obligated to face the error.

const std = @import("std");

pub fn main() !void {
var stdout_buffer: [1024]u8 = undefined;
var stdout_writer = std.fs.File.stdout().writer(&stdout_buffer);
const stdout = &stdout_writer.interface;
try stdout.print("Hello, {s}!\n", .{"world"});
try stdout.flush();
}

Another thing that you might have noticed in this code example, is that the main() function is marked with the pub keyword. It marks the main() function as a public function from this module. Every function in your Zig module is by default private to this Zig module and can only be called from within the module. Unless, you explicitly mark this function as a public function with the pub keyword.

If you think about it, this pub keyword in Zig does essentially the opposite of what the static keyword do in C/C++. By making a function “public” you allow other Zig modules to access and call this function. A calling Zig module imports another module by using the @import() built-in function, which makes all public functions from the imported module visible to the calling Zig module.

Compiling your source code

You can compile your Zig modules into a binary executable by running the build-exe command from the zig compiler. You simply list all the Zig modules that you want to build after the build-exe command, separated by spaces. In the example below, we are compiling the module main.zig.

zig build-exe src/main.zig

Since we are building an executable, the zig compiler will look for a main() function declared in any of the files that you list after the build-exe command. If the compiler does not find a main() function declared somewhere, a compilation error will be raised, warning about this mistake.

The zig compiler also offers a build-lib and build-obj commands, which work the exact same way as the build-exe command. The only difference is that, they compile your Zig modules into a portable C ABI library, or, into object files, respectively.

In the case of the build-exe command, a binary executable file is created by the zig compiler in the root directory of your project. If we take a look now at the contents of our current directory, with a simple ls command, we can see the binary file called main that was created by the compiler.

ls

build.zig  build.zig.zon  main  src

If I execute this binary executable, I get the “Hello World” message in the terminal , as we expected.

./main

Hello, world!

Compile and execute at the same time

In the previous section, I presented the zig build-exe command, which compiles Zig modules into an executable file. However, this means that, in order to execute the executable file, we have to run two different commands. First, the zig build-exe command, and then, we call the executable file created by the compiler.

But what if we wanted to perform these two steps, all at once, in a single command? We can do that by using the zig run command.

zig run src/main.zig

Hello, world!

Important note for Windows users

First of all, this is a Windows-specific thing, and, therefore, does not apply to other operating systems, such as Linux and macOS. In summary, if you have a piece of Zig code that includes some global variables whose initialization rely on runtime resources, then, you might have some troubles while trying to compile this Zig code on Windows.

An example of that is accessing the stdout (i.e., the standard output of your system), which is usually done in Zig by using the expression std.fs.File.stdout(). If you use this expression to instantiate a global variable in a Zig module, then, the compilation of your Zig code will very likely fail on Windows, with an “unable to evaluate comptime expression” error message.

This failure in the compilation process happens because all global variables in Zig are initialized at compile-time. However, on Windows, operations like accessing the stdout (or opening a file) depend on resources that are available only at runtime (you will learn more about compile-time versus runtime in Section 3.1.1).

For example, if you try to compile this code example on Windows, you will likely get the error message exposed below:

const std = @import("std");
var stdout_buffer: [1024]u8 = undefined;
// ERROR! Compile-time error that emerges from
// this next line, on the `stdout` object
var stdout_writer = std.fs.File.stdout().writer(&stdout_buffer);
const stdout = &stdout_writer.interface;

pub fn main() !void {
_ = try stdout.write("Hello\n");
try stdout.flush();
}

t.zig:2107:28: error: unable to evaluate comptime expression
break :blk asm {
^~~

To avoid this problem on Windows, we need to force the zig compiler to instantiate this stdout object only at runtime, instead of instantiating it at compile-time. We can achieve that by simply moving the expression to a function body.

This solves the problem because all expressions that are inside a function body in Zig are evaluated only at runtime, unless you use the comptime keyword explicitly to change this behaviour. You will learn more about this comptime keyword in Section 12.1.

const std = @import("std");
pub fn main() !void {
// SUCCESS: Stdout initialized at runtime.
var stdout_buffer: [1024]u8 = undefined;
var stdout_writer = std.fs.File.stdout().writer(&stdout_buffer);
const stdout = &stdout_writer.interface;
_ = try stdout.write("Hello\n");
try stdout.flush();
}

Hello

You can read more details about this Windows-specific limitation in a couple of GitHub issues opened at the official Zig repository. More specifically, the issues 17186 7 and 19864 8.

Compiling the entire project

Just as I described in Section 1.2.1, as our project grows in size and complexity, we usually prefer to organize the compilation and build process of the project into a build script, using some sort of “build system”.

In other words, as our project grows in size and complexity, the build-exe, build-lib and build-obj commands become harder to use directly. Because then, we start to list multiple and multiple modules at the same time. We also start to add built-in compilation flags to customize the build process for our needs, etc. It becomes a lot of work to write the necessary commands by hand.

In C/C++ projects, programmers normally opt to use CMake, Ninja, Makefile or configure scripts to organize this process. However, in Zig, we have a native build system in the language itself. So, we can write build scripts in Zig to compile and build Zig projects. Then, all we need to do, is to call the zig build command to build our project.

So, when you execute the zig build command, the zig compiler will search for a Zig module named build.zig inside your current directory, which should be your build script, containing the necessary code to compile and build your project. If the compiler does find this build.zig file in your directory, then, the compiler will essentially execute a zig run command over this build.zig file, to compile and execute this build script, which in turn, will compile and build your entire project.

zig build

After you execute this “build project” command, a zig-out directory is created in the root of your project directory, where you can find the binary executables and libraries created from your Zig modules accordingly to the build commands that you specified at build.zig. We will talk more about the build system in Zig later in this book.

In the example below, I’m executing the binary executable named hello_world that was generated by the compiler after the zig build command.

./zig-out/bin/hello_world

Hello, world!

How to learn Zig?

What are the best strategies to learn Zig? First of all, of course this book will help you a lot on your journey through Zig. But you will also need some extra resources if you want to be really good at Zig.

As a first tip, you can join a community with Zig programmers to get some help , when you need it:

• Reddit forum: https://www.reddit.com/r/Zig/;
• Ziggit community: https://ziggit.dev/;
• Discord, Slack, Telegram, and others: https://github.com/ziglang/zig/wiki/Community;

Now, one of the best ways to learn Zig is to simply read Zig code. Try to read Zig code often, and things will become more clear. A C/C++ programmer would also probably give you this same tip. Because this strategy really works!

Now, where can you find Zig code to read? I personally think that, the best way of reading Zig code is to read the source code of the Zig Standard Library. The Zig Standard Library is available at the lib/std folder9 on the official GitHub repository of Zig. Access this folder, and start exploring the Zig modules.

Also, a great alternative is to read code from other large Zig codebases, such as:

1. the Javascript runtime Bun10.
2. the game engine Mach11.
3. a LLama 2 LLM model implementation in Zig12.
4. the financial transactions database tigerbeetle13.
5. the command-line arguments parser zig-clap14.
6. the UI framework capy15.
7. the Language Protocol implementation for Zig, zls16.
8. the event-loop library libxev17.

All these assets are available on GitHub, and this is great, because we can use the GitHub search bar to our advantage, to find Zig code that fits our description. For example, you can always include lang:Zig in the GitHub search bar when you are searching for a particular pattern. This will limit the search to only Zig modules.

Also, a great alternative is to consult online resources and documentation. Here is a quick list of resources that I personally use from time to time to learn more about the language each day:

• Zig Language Reference: https://ziglang.org/documentation/master/;
• Zig Standard Library Reference: https://ziglang.org/documentation/master/std/;
• Zig Guide: https://zig.guide/;
• Karl Seguin Blog: https://www.openmymind.net/;
• Zig News: https://zig.news/;
• Read the code written by one of the Zig core team members: https://github.com/kubkon;
• Some livecoding sessions are transmitted in the Zig Showtime Youtube Channel: https://www.youtube.com/@ZigSHOWTIME/videos;

Another great strategy to learn Zig, or honestly, to learn any language you want, is to practice it by solving exercises. For example, there is a famous repository in the Zig community called Ziglings18 , which contains more than 100 small exercises that you can solve. It’s a repository of tiny programs written in Zig that are currently broken, and your responsibility is to fix these programs, and make them work again.

A famous tech YouTuber known as The Primeagen also posted some videos (on YouTube) where he solves these exercises from Ziglings. The first video is named “Trying Zig Part 1”19.

Another great alternative, is to solve the Advent of Code exercises20. There are people that already took the time to learn and solve the exercises, and they posted their solutions on GitHub as well, so, in case you need some resource to compare while solving the exercises, you can look at these two repositories:

• https://github.com/SpexGuy/Zig-AoC-Template;
• https://github.com/fjebaker/advent-of-code-2022;

Creating new objects in Zig (i.e., identifiers)

Let’s talk more about objects in Zig. Readers that have past experience with other programming languages might know this concept through a different name, such as: “variable” or “identifier”. In this book, I choose to use the term “object” to refer to this concept.

To create a new object (or a new “identifier”) in Zig, we use the keywords const or var. These keywords specify if the object that you are creating is mutable or not. If you use const, then the object you are creating is a constant (or immutable) object, which means that once you declare this object, you can no longer change the value stored inside this object.

On the other side, if you use var, then, you are creating a variable (or mutable) object. You can change the value of this object as many times you want. Using the keyword var in Zig is similar to using the keywords let mut in Rust.

Constant objects vs variable objects

In the code example below, we are creating a new constant object called age. This object stores a number representing the age of someone. However, this code example does not compile successfully. Because on the next line of code, we are trying to change the value of the object age to 25.

The zig compiler detects that we are trying to change the value of an object/identifier that is constant, and because of that, the compiler will raise a compilation error, warning us about the mistake.

const age = 24;
// The line below is not valid!
age = 25;

t.zig:10:5: error: cannot assign to constant
age = 25;
~~^~~

So, if you want to change the value of your object, you need to transform your immutable (or “constant”) object into a mutable (or “variable”) object. You can do that by using the var keyword. This keyword stands for “variable”, and when you apply this keyword to some object, you are telling the Zig compiler that the value associated with this object might change at some point.

Thus, if we come back to the previous example, and change the declaration of the age object to use the var keyword, then, the program gets compiled successfully. Because now, the zig compiler detects that we are changing the value of an object that allows this behaviour, because it’s a “variable object”.

However, if you take a look at the example below, you will notice that we have not only declared the age object with the var keyword, but we also have explicitly annotated the data type of the age object with the u8 type this time. The basic idea is, when we use a variable/mutable object, the Zig compiler ask for us to be more explicit with what we want, to be more clear about what our code does. This translates into being more explicit about the data types that we want to use in our objects.

Therefore, if you transform your object into a variable/mutable object, just remember to always annotate the type of the object explicitly in your code. Otherwise, the Zig compiler might raise a compilation error, asking you to transform your object back into a const object, or, to give your object an “explicit type”.

var age: u8 = 24;
age = 25;

Declaring without an initial value

By default, when you declare a new object in Zig, you must give it an initial value. In other words, this means that we have to declare, and, at the same time, initialize every object we create in our source code.

On the other hand, you can, in fact, declare a new object in your source code, and not give it an explicit value. But we need to use a special keyword for that, which is the undefined keyword.

It’s important to emphasize that, you should avoid using undefined as much as possible. Because when you use this keyword, you leave your object uninitialized, and, as a consequence, if for some reason, your code uses this object while it’s uninitialized, then, you will definitely have undefined behaviour and major bugs in your program.

In the example below, I’m declaring the age object again. But this time, I do not give it an initial value. The variable is only initialized at the second line of code, where I store the number 25 in this object.

var age: u8 = undefined;
age = 25;

Having these points in mind, just remember that you should avoid as much as possible to use undefined in your code. Always declare and initialize your objects. Because this gives you much more safety in your program. But in case you really need to declare an object without initializing it… the undefined keyword is the way to do it in Zig.

There is no such thing as unused objects

Every object (being constant or variable) that you declare in Zig must be used in some way. You can give this object to a function call, as a function argument, or, you can use it in another expression to calculate the value of another object, or, you can call a method that belongs to this particular object.

It doesn’t matter in which way you use it. As long as you use it. If you try to break this rule, i.e., if your try to declare a object, but not use it, the zig compiler will not compile your Zig source code, and it will issue a error message warning that you have unused objects in your code.

Let’s demonstrate this with an example. In the source code below, we declare a constant object called age. If you try to compile a simple Zig program with this line of code below, the compiler will return an error as demonstrated below:

const age = 15;

t.zig:4:11: error: unused local constant
const age = 15;
^~~

Everytime you declare a new object in Zig, you have two choices:

1. you either use the value of this object;
2. or you explicitly discard the value of the object;

To explicitly discard the value of any object (constant or variable), all you need to do is to assign this object to a special character in Zig, which is the underscore (_). When you assign an object to a underscore, like in the example below, the zig compiler will automatically discard the value of this particular object.

You can see in the example below that, this time, the compiler did not complain about any “unused constant”, and successfully compiled our source code.

// It compiles!
const age = 15;
_ = age;

Now, remember, everytime you assign a particular object to the underscore, this object is essentially destroyed. It’s discarded by the compiler. This means that you can no longer use this object further in your code. It doesn’t exist anymore.

So if you try to use the constant age in the example below, after we discarded it, you will get a loud error message from the compiler (talking about a “pointless discard”) warning you about this mistake.

// It does not compile.
const age = 15;
_ = age;
// Using a discarded value!
std.debug.print("{d}\n", .{age + 2});

t.zig:7:5: error: pointless discard
of local constant

This same rule applies to variable objects. Every variable object must also be used in some way. And if you assign a variable object to the underscore, this object also gets discarded, and you can no longer use this object.

You must mutate every variable objects

Every variable object that you create in your source code must be mutated at some point. In other words, if you declare an object as a variable object, with the keyword var, and you do not change the value of this object at some point in the future, the zig compiler will detect this, and it will raise an error warning you about this mistake.

The concept behind this is that every object you create in Zig should be preferably a constant object, unless you really need an object whose value will change during the execution of your program.

So, if I try to declare a variable object such as where_i_live below, and I do not change the value of this object in some way, the zig compiler raises an error message with the phrase “variable is never mutated”.

var where_i_live = "Belo Horizonte";
_ = where_i_live;

t.zig:7:5: error: local variable is never mutated
t.zig:7:5: note: consider using 'const'

Primitive Data Types

Zig has many different primitive data types available for you to use. You can see the full list of available data types at the official Language Reference page21.

But here is a quick list:

• Unsigned integers: u8, 8-bit integer; u16, 16-bit integer; u32, 32-bit integer; u64, 64-bit integer; u128, 128-bit integer.
• Signed integers: i8, 8-bit integer; i16, 16-bit integer; i32, 32-bit integer; i64, 64-bit integer; i128, 128-bit integer.
• Float number: f16, 16-bit floating point; f32, 32-bit floating point; f64, 64-bit floating point; f128, 128-bit floating point;
• Boolean: bool, represents true or false values.
• C ABI compatible types: c_long, c_char, c_short, c_ushort, c_int, c_uint, and many others.
• Pointer sized integers: isize and usize.

Arrays

You create arrays in Zig by using a syntax that resembles the C syntax. First, you specify the size of the array (i.e., the number of elements that will be stored in the array) you want to create inside a pair of brackets.

Then, you specify the data type of the elements that will be stored inside this array. All elements present in an array in Zig must have the same data type. For example, you cannot mix elements of type f32 with elements of type i32 in the same array.

After that, you simply list the values that you want to store in this array inside a pair of curly braces. In the example below, I am creating two constant objects that contain different arrays. The first object contains an array of 4 integer values, while the second object, an array of 3 floating point values.

Now, you should notice that in the object ls, I am not explicitly specifying the size of the array inside of the brackets. Instead of using a literal value (like the value 4 that I used in the ns object), I am using the special character underscore (_). This syntax tells the zig compiler to fill this field with the number of elements listed inside of the curly braces. So, this syntax [_] is for lazy (or smart) programmers who leave the job of counting how many elements there are in the curly braces for the compiler.

const ns = [4]u8{48, 24, 12, 6};
const ls = [_]f64{432.1, 87.2, 900.05};
_ = ns; _ = ls;

It’s worth noting that these are static arrays, meaning that they cannot grow in size. Once you declare your array, you cannot change the size of it. This is very common in low level languages. Because low level languages normally wants to give you (the programmer) full control over memory, and the way in which arrays are expanded is tightly related to memory management.

Selecting elements of the array

One very common activity is to select specific portions of an array you have in your source code. In Zig, you can select a specific element from your array, by simply providing the index of this particular element inside brackets after the object name. In the example below, I am selecting the third element from the ns array. Notice that Zig is a “zero-index” based language, like C, C++, Rust, Python, and many other languages.

const ns = [4]u8{48, 24, 12, 6};
try stdout.print("{d}\n", .{ ns[2] });
try stdout.flush();

12

In contrast, you can also select specific slices (or sections) of your array, by using a range selector. Some programmers also call these selectors of “slice selectors”, and they also exist in Rust, and have the exact same syntax as in Zig. Anyway, a range selector is a special expression in Zig that defines a range of indexes, and it has the syntax start..end.

In the example below, at the second line of code, the sl object stores a slice (or a portion) of the ns array. More precisely, the elements at index 1 and 2 in the ns array.

const ns = [4]u8{48, 24, 12, 6};
const sl = ns[1..3];
_ = sl;

When you use the start..end syntax, the “end tail” of the range selector is non-inclusive, meaning that, the index at the end is not included in the range that is selected from the array. Therefore, the syntax start..end actually means start..end - 1 in practice.

You can for example, create a slice that goes from the first to the last elements of the array, by using ar[0..ar.len] syntax In other words, it’s a slice that accesses all elements in the array.

const ar = [4]u8{48, 24, 12, 6};
const sl = ar[0..ar.len];
_ = sl;

You can also use the syntax start.. in your range selector. Which tells the zig compiler to select the portion of the array that begins at the start index until the last element of the array. In the example below, we are selecting the range from index 1 until the end of the array.

const ns = [4]u8{48, 24, 12, 6};
const sl = ns[1..];
_ = sl;

More on slices

As we discussed before, in Zig, you can select specific portions of an existing array. This is called slicing in Zig (Sobeston 2024), because when you select a portion of an array, you are creating a slice object from that array.

A slice object is essentially a pointer object accompanied by a length number. The pointer object points to the first element in the slice, and the length number tells the zig compiler how many elements there are in this slice.

Slices can be thought of as a pair of [*]T (the pointer to the data) and a usize (the element count) (Sobeston 2024).

Through the pointer contained inside the slice you can access the elements (or values) that are inside this range (or portion) that you selected from the original array. But the length number (which you can access through the len property of your slice object) is the really big improvement (over C arrays for example) that Zig brings to the table here.

Because with this length number the zig compiler can easily check if you are trying to access an index that is out of the bounds of this particular slice, or, if you are causing any buffer overflow problems. In the example below, we access the len property of the slice sl, which tells us that this slice has 2 elements in it.

const ns = [4]u8{48, 24, 12, 6};
const sl = ns[1..3];
try stdout.print("{d}\n", .{sl.len});
try stdout.flush();

2

Array operators

There are two array operators available in Zig that are very useful. The array concatenation operator (++), and the array multiplication operator (**). As the name suggests, these are array operators.

One important detail about these two operators is that they work only when both operands have a size (or “length”) that is compile-time known. We are going to talk more about the differences between “compile-time known” and “runtime known” in Section 3.1.1. But for now, keep this information in mind, that you cannot use these operators in every situation.

In summary, the ++ operator creates a new array that is the concatenation, of both arrays provided as operands. So, the expression a ++ b produces a new array which contains all the elements from arrays a and b.

const a = [_]u8{1,2,3};
const b = [_]u8{4,5};
const c = a ++ b;
try stdout.print("{any}\n", .{c});
try stdout.flush();

{ 1, 2, 3, 4, 5 }

This ++ operator is particularly useful to concatenate strings together. Strings in Zig are described in depth in Section 1.8. In summary, a string object in Zig is essentially an arrays of bytes. So, you can use this array concatenation operator to effectively concatenate strings together.

In contrast, the ** operator is used to replicate an array multiple times. In other words, the expression a ** 3 creates a new array which contains the elements of the array a repeated 3 times.

const a = [_]u8{1,2,3};
const c = a ** 2;
try stdout.print("{any}\n", .{c});
try stdout.flush();

{ 1, 2, 3, 1, 2, 3 }

Runtime versus compile-time known length in slices

We are going to talk a lot about the differences between compile-time known and runtime known across this book, especially in Section 3.1.1. But the basic idea is that a thing is compile-time known, when we know everything (the value, the attributes and the characteristics) about this thing at compile-time. In contrast, a runtime known thing is when the exact value of a thing is calculated only at runtime. Therefore, we don’t know the value of this thing at compile-time, only at runtime.

We have learned in Section 1.6.1 that slices are created by using a range selector, which represents a range of indexes. When this “range of indexes” (i.e., both the start and the end of this range) is known at compile-time, the slice object that gets created is actually, under the hood, just a single-item pointer to an array.

You don’t need to precisely understand what that means now. We are going to talk a lot about pointers in Chapter 6. For now, just understand that, when the range of indexes is known at compile-time, the slice that gets created is just a pointer to an array, accompanied by a length value that tells the size of the slice.

If you have a slice object like this, i.e., a slice that has a compile-time known range, you can use common pointer operations over this slice object. For example, you can dereference the pointer of this slice, by using the .* method, like you would do on a normal pointer object.

const arr1 = [10]u64 {
1, 2, 3, 4, 5,
6, 7, 8, 9, 10
};
// This slice has a compile-time known range.
// Because we know both the start and end of the range.
const slice = arr1[1..4];
_ = slice;

On the other hand, if the range of indexes is not known at compile time, then, the slice object that gets created is not a pointer anymore, and, thus, it does not support pointer operations. For example, maybe the start index is known at compile time, but the end index is not. In such case, the range of the slice becomes runtime known only.

In the example below, we are reading a file, and then, we try to create a slice object that covers the entire buffer that contains the contents of this file. This is obviously an example of a runtime known range, because the end index of the range is not known at compile time.

In other words, the end index of the range is the size of the array file_contents. However, the size of file_contents is not known at compile time. Because we don’t know how many bytes are stored inside this shop-list.txt file. And because this is a file, someone might edit this file tomorrow and add more lines or remove lines from it. Therefore, the size of this file might vary drastically from one execution to another.

Now, if the file size can vary from one run to another, then, we can conclude that the value of the expression file_contents.len exposed in the example below can also vary from one run to another. As consequence, the value of the expression file_contents.len is runtime-known only, and, as a consequence of that, the range 0..file_contents.len is also runtime-known only.

const std = @import("std");
const builtin = @import("builtin");

fn read_file(allocator: std.mem.Allocator, path: []const u8) ![]u8 {
var reader_buffer: [1024]u8 = undefined;
var file_buffer = try allocator.alloc(u8, 1024);
@memset(file_buffer[0..], 0);

const file = try std.fs.cwd().openFile(path, .{});
defer file.close();

var reader = file.reader(reader_buffer[0..]);
const nbytes = try reader.read(
file_buffer[0..]
);
return file_buffer[0..nbytes];
}

pub fn main() !void {
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
const allocator = gpa.allocator();
const path = "../ZigExamples/file-io/shop-list.txt";
const file_contents = try read_file(allocator, path);
const slice = file_contents[0..file_contents.len];
_ = slice;
}

Blocks and scopes

Blocks are created in Zig by a pair of curly braces. A block is just a group of expressions (or statements) contained inside of a pair of curly braces. All of these expressions that are contained inside of this pair of curly braces belongs to the same scope.

In other words, a block just delimits a scope in your code. The objects that you define inside the same block belongs to the same scope, and, therefore, are accessible from within this scope. At the same time, these objects are not accessible outside of this scope. So, you could also say that blocks are used to limit the scope of the objects that you create in your source code. In less technical terms, blocks are used to specify where in your source code you can access whatever object you have in your source code.

So, a block is just a group of expressions contained inside a pair of curly braces. And every block have its own scope separated from the others. The body of a function is a classic example of a block. If statements, for and while loops (and any other structure in the language that uses the pair of curly braces) are also examples of blocks.

This means that, every if statement, or for loop, etc., that you create in your source code has its own separate scope. That is why you can’t access the objects that you defined inside of your for loop (or if statement) in an outer scope, i.e., a scope outside of the for loop. Because you are trying to access an object that belongs to a scope that is different than your current scope.

You can create blocks within blocks, with multiple levels of nesting. You can also (if you want to) give a label to a particular block, with the colon character (:). Just write label: before you open the pair of curly braces that delimits your block. When you label a block in Zig, you can use the break keyword to return a value from this block, like as if it was a function’s body. You just write the break keyword, followed by the block label in the format :label, and the expression that defines the value that you want to return.

Like in the example below, where we are returning the value from the y object from the block add_one, and saving the result inside the x object.

var y: i32 = 123;
const x = add_one: {
y += 1;
break :add_one y;
};
if (x == 124 and y == 124) {
try stdout.print("Hey!", .{});
try stdout.flush();
}

Hey!

How strings work in Zig?

The first project that we are going to build and discuss in this book is a base64 encoder/decoder (Chapter 4). But in order for us to build such a thing, we need to get a better understanding on how strings work in Zig. So let’s discuss this specific aspect of Zig.

Strings in Zig work very similarly to strings in C, but they come with some extra caveats which adds more safety a