Zig notes

Intro to the Zig Programming Language • Andrew Kelley • GOTO 2022

I continue to like what I’m seeing in Zig …

Notes:

  • A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
  • increase the utility of the commons
    • referenced a quote from the author of the mold linker
  • re-examine the fundamental building blocks of software
    • example:memory allocation – we pass allocators around
    • example: dependency on libc
  • raise the standards of software as a craft
    • tooling such as zig cc
    • robust, high-performance open source libraries
      • not only Zig but all languates via the C ABI
    • provide guidance to students in ethics and skills
  • Moto: Maintain It With Zig
    • Level 1: drop in zig cc
      • How Zig is used at Uber
      • good defaults
      • undefined behavior by default
      • cross-compilation
        • zig cc -o hello hello.c -target x86_64-windows
        • zig cc -o hello hello.c -target aarch64-macos
        • zig c++ o hello.cpp
        • zig cc -o hello hello.c -target aarch64-linux-gnu.2.31
        • zic cc -o hello hello.c -target aarch64-linux-musl (statically linked, works on any distro)
        • built-in caching
        • trivial installation
    • Level 2: zig build
      • build.zig file
      • coming soon – package manager, fulfilling C/C++ dependencies
    • Level 3: Write a component in Zig
      • easy to mix C and Zig code
      • LTO (optimizer)
  • How to predict the future
    • Non-Profits vs VC-backed Startups vs Private companies
  • Zig Software Foundation
    • we have achieved financial stability
    • we have released a useful working product
    • happy, talented, self-directed staff
    • ambitious roadmap
    • secure future
    • board or directors is the boss – when Andrew is gone, it will continue to operate
  • Zig in Action
    • Zig is general-purpose, which means it gives you the tools to generate the best possible machine code for the target, whether it is hardware or a virtual machine.
    • This makes it applicable to anything resembling a Vonn Neumann machine
    • But there are some cases where Zig truly excels thanks to its conservative language design choices.
    • Rive Window Manager
    • Bun – javascript runtime
      • Why is Bun fast? An enormous amount of time spent profiling, benchmarking and optimizing things. The answer is different for every part of Bun, but one general theme: Zig’s low-level control over memory and lack of hidden control flow makes it much simpler to write fast software. Sponsor the Zig Software Foundation.
    • Zigler - Elixer – use Zig in Elixer
    • VFX Plugins
    • Digital Audio Workstation
    • Mach game engine and graphics toolkit
    • Zig-Gamedev
    • TigerBeetle
    • Unmanned store in Sillerud
      • reports there were zero bugs
    • Zig Embedded Group
      • MicroZig – hardware abstraction layer
    • BoksOS
    • WASM-4 Games
  • Taste of Zig
    • ArrayList
    • a few orthogonal concepts that work together
    • users don’t spend much time fighting the language
    • Inline Loops
    • InlineLoops
    • AutoArrayHashMap
    • Zig uses generics, meta programming, and reflection a lot
    • unit tests automatically detect memory leaks
    • MultiArrayList
    • C Integration
      • example of cross compiling
      • builds all dependencies like SDL
  • Summary
    • Zig Software Foundation is a non-profit organization dedicated to improving the craft of software engineering as a whole.
    • Zig is a C/C++ compiler toolchain and build system that can be used to simplify maintenance of your existing projects.
    • Zig is a simple, powerful programming language that excels in the most demanding environments.

I love how you can just use Zig as your C/C++ compiler if you want.

Yes, Zig is great for build/testing, etc. I will be using it where I can in the future for C projects.

I saw Ghostty (terminal emulator) is available now, written in Zig.
https://mitchellh.com/writing/ghostty-1-0-reflection

I’m excited to see where Ghostty goes – I tried it a few days back, but does not seem compelling over Alacrity yet.

If you give it a try, let us know what you think!

Will do! I am using Windows Terminal most days with Nushell, but at home I use tilda because I want a “dropdown” terminal.

Zig as a Multi-OS Build System (with Loris Cro)

This is a very interesting discussion that focuses on Zig as a build system.

Also available as podcast: Developer Voices

Notes:

  • Python is basically a nice frontend to a lot of C libraries
  • Docker containers for every OS/Arch are commonly used in CI to build binaries
  • Python Wheels have eliminated a lot of the pain of native code in Python packages, but they are simply pre-built binaries – they still need to be build somewhere.
  • Zig proposed to cross-compile C code from one machine.
  • Zig packages all of the various libc and platform bits required to cross build on any platform (like Go).
  • Discussion of the problems of cross-compiling C code
  • The Python package index size is growing a lot due to all the binaries that are stored for every architecture and version (see graph below).
  • Zig build is declarative, but still creates a build graph.
  • There is no such thing as a clean operation for Zig build – no reason to clean your cache.
  • Zig cache is more than just timestamps: inode, hash of file, etc.
  • Can install Zig using pypi: ziglang · PyPI
  • Zig gets rid of all your build dependencies – one dependency is both your compiler, build system, and package manager.
  • Loris Cro has written a static site generator in Zig. Uses the Zig build system to build the site.

I think we’re seeing the future here. Build systems (including cross-compilation) are moving to the language domain. This has already happened with Go and Rust – it looks like Zig is positioned to make this change for C.

1 Like

A build system for C/C++ is an incredibly ambitious endeavor. I may try using Zig for my cgo build process. I was surprised that even 2 small C dependencies required a few hours of installing compilers and libraries along with debugging environment variable and the like… That’s just one OS / architecture combo.

This YouTube discussion was excellent, by the way

Yeah, I thought this discussion was really good!

Some info on that topic:

1 Like

What’s Zig got that C, Rust and Go don’t have? (with Loris Cro)

Very good overview of Zig, how it is different, and what it can do for you.

Also available as podcast: Developer Voices

Zig 0.14.0 released

https://ziglang.org/download/0.14.0/release-notes.html

x86 Backend

The x86 backend is now passing 1884/1923 (98%) of the behavior test suite compared to the LLVM backend. Although it is not yet selected by default, it is more often than not a better choice than LLVM backend while developing, due to dramatically faster compilation speed, combined with better debugger support.

This backend is nearing completion; it is expected to be selected by default for debug mode early in the next release cycle. Users are encouraged to try it out in this 0.14.0 release. It can be selected with -fno-llvm, or use_llvm = false in a build script.

Zig is breaking all the rules and redoing everything from the ground up. The audacity and courage to do this is amazing. Go did it, but they had Google backing them.

Looks like Zig is gaining momentum. This article is a really good summary of why people are using Zig:

Async I/O

Some good critique - Opinion piece: On Zig (and the design choices within)

That is a very interesting and thorough analysis – hopefully the Zig authors are humble enough to consider some of the points.

It is interesting the different thoughts on safety from “Blueberry Wren”:

First, and very much foremost, Zig is not memory safe. This is, in my opinion, the most egregious thing in this post, by a very large margin. Moreso, Zig does not make any attempt to be memory safe - it can catch some things at runtime, with specific allocators, but so can C these days. Indeed, there are some cases, like use-after-realloc, that asan can catch and Zig cannot.

A language in the modern day that does not make an attempt at memory safety is, in my opinion, not reasonable. It has been shown that in some areas, up to 70% of security bugs are due to memory safety issues (Source).

I subscribe to the idea that the user must be constrained. It is perhaps harsh to say, but for large and complex programs, I believe that there are very few programmers who will write memory-correct code nine times out of ten. When writing code with others, that goes down. I personally do not believe I fit into that category.

The fact that Zig allows the user to write faulty software is supported by various somewhat informal, but still useful, statistics. Notably, the following statistic disregard duplicates, and unreported errors. However, general trends are still of note.

Compared with Joran Dirk Greef’s thoughts (see the pledge article a few posts up):

What I learned is that if you could centralize resource allocation in time and space (the dimensions that prove tricky for humans writing software) then this could not only simplify memory management, to design away some of the need for a borrow checker in the first place, but, more importantly, also be a forcing function for propagating good design, to encourage teams to think through the explicit limits or physics of the software (you have no choice).

Finally, while the borrow checker could achieve local memory safety, TigerBeetle needed more correctness properties. TigerBeetle needed to be always correct, and across literally thousands of invariants. As matklad would say, this is a harder problem! I had also spent enough time in memory safe languages to know that local memory safety is no guarantee of local correctness, let alone distributed system correctness. Per systems thinking, I believe that total correctness is a design problem, not a language problem. Language is valuable. But no human language can guarantee the next Hemingway or Nabokov. For this you need philosophy. Even then it’s not a guarantee but a probability.

There are obviously multiple “good” ways to solve problems on computers, and it probably depends a lot on what type of problem you are solving. Go is still my “go-to” general purpose language - it is memory safe, simple, has great tooling, and is easy to deploy on anything. If I needed to be 20% faster, or 10% safer, then these other languages would make sense, but most problems I solve do not have this constraint. My constraint is that I often need to complete it 30% sooner :slight_smile: .