Benki → All Posts

Zig is a strange point in the design space

The Zig programming language is quite strange. I am unsure whether I should like it.

The language is small. There are very few primitives, including for abstraction. On the other hand, one of them is a somewhat Lisp-like compile-time metaprogramming mechanism called comptime, which is very general.

The standard library is small, too. It is very much the opposite of a batteries-included approach. You have to write a lot of code yourself. On the other hand, the standard library is also designed to be complete enough that you can get by without linking against your platform’s C library.

Zig wants to implement everything itself and does not want to rely on C. On the other hand, importing and using C code is easier and more natural in Zig than most languages, arguably more natural than C++ – C++ does not really help you manage C resources whereas Zig provides defer.

Along similar lines, even though Zig wants to be independent of C, even though its standard library wraps syscalls directly (on kernels with a stable syscall API such as Linux), it takes care of building all the C code that you may need, including when cross-compiling to a different target architecture and OS. In theory you can use Zig as a cross-compilation-capable build system and dependency manager for pure C code bases.

There is no compile-time safety. There is neither lifetime tracking nor particularly rich types. On the other hand, when you run your program in debug mode there is no undefined behavior, only crashes, and memory leaks are detected and printed to the console.

The type system is limited. There is no built-in polymorphism, neither universal (read: dynamic dispatch) nor ad-hoc (read: static dispatch). On the other hand, you have tagged unions that look and behave like algebraic data types, you are encouraged to use comptime functions to generate types from templates, and the standard library uses explicit vtable structs under the hood in some places.

Zig is not object-oriented. There is no encapsulation enforcement, and because there is no universal polymorphism there are no interfaces and no inheritance. Yet structs and unions can have methods, and there is a self type that is useful when you create types at comptime.

It seems to me that Zig improves upon C in every respect in which it differs from it save for the number of platforms that it is available for. But the design space for languages that fulfill this criterion is big. It is not clear to me whether Zig is the best point explored in it so far.

Except for the name. There is no doubt that the name is good.