Zig

Time Spent Compiling Code must compile fast. Use all manner of caching, shared objects, multithreading, whatever must be done in order to produce a binary as soon as possible. Making a release build could take orders of magnitude longer than a debug build and that is acceptable. Runtime Performance Could be order of magnitude slower than release build and that is acceptable. Optimal performance. Aggressive optimizations. Take the time needed to produce a highly efficient runtime efficiency. No compromises here. Undefined Behavior What would be undefined behavior in a release build, is defined behavior in a debug build, and that is for the runtime to trap. That is, crash. This includes things like array bounds checking, integer overflow, reaching unreachable code. Not all undefined behavior can be caught, but a comfortably large amount can. Undefined behavior in release mode has unspecified consequences, and this lets the optimizer produce optimal code. The build mode is available to the source code via the expression @import("builtin").mode . Part of being pragmatic is recognizing C's existing success. Interop with C is crucial. Zig embraces C like the mean older brother who you are a little afraid of but you still want to like you and be your friend. Now this function has the C ABI, and the name shows up in the symbol table verbatim. Likewise, you can declare an external function prototype: This exposes all the symbols in stdio.h - including the define statements - to the zig program, and then you can call puts or printf just like you would in C. One area that Zig provides safety without compromising efficiency or readability is with the optional type. Instead of integers, let's talk about pointers. Null references are the source of many runtime exceptions, and even stand accused of being the worst mistake of computer science . Instead, you can use an optional pointer. This secretly compiles down to a normal pointer, since we know we can use 0 as the null value for the maybe type. But the compiler can check your work and make sure you don't assign null to something that can't be null. Typically the downside of not having null is that it makes the code more verbose to write. But, let's compare some equivalent C code and Zig code. One benefit to this is that functions which take pointers as arguments can be annotated with the "nonnull" attribute - attribute ((nonnull)) in GCC . The optimizer can sometimes make better decisions knowing that pointer arguments cannot be null. Note: when this blog post was written, Zig did not distinguish between Single Item Pointers and Unknown Length Pointers. You can read about this in the documentation . One of the distinguishing features of Zig is its exception handling strategy. An error set is a lot like an enum, except errors from different error sets which share a name, are defined to have the same numerical value. So each error name has a globally unique integer associated with it. The integer value 0 is reserved. Most of the time you will not find yourself using an error set type. Instead, likely you will be using the error union type. Error unions are created with the binary operator ! , with the error set on the left and any other type on the right: ErrorSet!OtherType . Notice the return type is ParseError!u64 . This means that the function either returns an unsigned 64 bit integer, or one of the ParseError errors. Within the function definition, you can see some return statements that return an error set value, and at the bottom a return statement that returns a u64 . Both types implicitly cast to ParseError!u64 . Note: this blog post was written before Zig had the concept of Error Sets vs anyerror , and before Zig had Error Set Inference . Most functions in Zig can rely on error set inference, which would make the prototype of parseU64 look like this: try evaluates an error union expression. If it is an error, it returns from the current function with the same error.