Go.CodeCompared.To/Zig

Zig has no implicit prelude or runtime — const std = @import("std"); is always the first line, and there is no garbage collector or scheduler started behind the scenes. The main(init: std.process.Init) !void signature receives an I/O context, and the ! makes the return an error union. Where Go's fmt.Println adds a newline, Zig requires the explicit \n.

Both zig run and go run compile and execute in one step, and both produce a single static binary with no runtime to ship. Zig's cross-compilation is a standout: -target aarch64-linux needs no separate toolchain because Zig bundles libc for every target — closer to Go's GOOS/GOARCH than to a C cross-compiler.

Zig has only line comments: // for ordinary comments and /// for documentation that attaches to the following declaration. There is no /* ... */ block-comment form at all — unlike Go, which supports both. To comment out a region you prefix every line, which keeps comments from nesting incorrectly.

@import("std") is a built-in that returns the standard library as an ordinary struct value bound to a const; you then reach into it with std.ascii, std.mem, and so on. There is no separate import statement or package list as in Go — a module is just a value, and you can @import("other.zig") your own files the same way.

Zig writes the type after the name with a colon, and like Go it rejects unused local variables — but Zig goes further: an unused var that is never mutated is also an error (use const), and every variable must be initialised (write = undefined to opt into uninitialised memory). Discard a value you must keep but not use with _ = value;.

Zig infers the type of a const from its initialiser, but integer and float literals get the special compile-time types comptime_int and comptime_float, which coerce to any concrete numeric type at the point of use. A mutable runtime var usually needs an explicit type so the compiler knows its storage size — unlike Go's :=, which always infers from the right-hand side.

Zig integer types are i/u plus the exact bit width, the same scheme as Go's int8/uint64 — but Zig allows any width up to 65535 bits, so u3, i128, and u1024 are all real types. There is no platform-dependent int like Go's; if you want a pointer-sized integer you name it usize or isize explicitly.

Both languages forbid silent lossy conversions, but they draw the line differently. Go requires an explicit conversion even for guaranteed-safe widening (int64(count)). Zig allows implicit widening when the value provably fits (i32 into i64) yet requires a dedicated builtin — @floatFromInt, @intFromFloat, @intCast — for any conversion that could lose information.

Like a Go string, a Zig string is a slice of bytes ([]const u8) and indexing yields a byte, not a character. The length is a field — greeting.len, not len(greeting). A string literal is actually a pointer to a null-terminated array that coerces to a slice, so the terminator is available for C interop while Zig code works with the length-carrying slice.

Where Go's fmt.Sprintf allocates a fresh string on the heap, Zig's std.fmt.bufPrint formats into a caller-provided stack buffer and returns a slice of it — no allocation, and it returns an error if the buffer is too small. The format placeholders differ from Go's verbs: {s} for strings, {d} for integers, {d:.2} for fixed-point floats.

Go's == compares string contents. In Zig, == on two slices compares the pointer and length, not the bytes, so comparing string values requires std.mem.eql(u8, first, second). This is a common surprise coming from Go — the language keeps == meaning "the same memory" and makes content comparison an explicit standard-library call.

Both languages have true fixed-size arrays whose length is part of the type — Go's [5]int and Zig's [5]i32. In Zig the size must be known at compile time, so out-of-bounds indexing with a constant is a compile error, and [_]i32{ ... } lets the compiler count the elements for you. The {any} placeholder formats a whole array.

A Zig slice []T is a pointer-plus-length pair, exactly like a Go slice, and array[1..4] takes a half-open sub-slice. The difference is ownership: a Go slice keeps its backing array alive through the garbage collector, while a Zig slice merely borrows memory whose lifetime you manage — so you must ensure the underlying array outlives the slice.

Zig's for iterates a slice or array directly, binding each element between |...| — no index arithmetic, much like Go's for _, value := range. The element comes first, with no throwaway index to ignore. For a counting loop with no collection, Zig uses while instead.

To get an index alongside each value, Zig adds a second range to the for: for (fruits, 0..) |fruit, index| iterates the slice and a counter in lockstep. Note the order is the reverse of Go's range, which yields index, value — in Zig the value comes first and the index is the trailing capture.

In Zig if is an expression that yields a value, so you bind its result directly and there is no ternary operator — if (score >= 60) "pass" else "fail" replaces both. Go's if is a statement, requiring the declare-then-assign pattern, and Go likewise has no ternary. Zig requires parentheses around the condition; Go forbids them.

Go folds every loop into for; Zig keeps both for (for collections) and while (for conditions). Zig's while has a distinctive continue-expression: while (count < 3) : (count += 1) runs the : (...) part after each iteration, which keeps the increment visible even when the body uses continue.

Both stop after the first match with no fall-through, but Zig's switch is an expression that returns a value and is exhaustive: every possible input must be covered or the code will not compile. Over an integer that means an else arm is required; over an enum, the compiler instead forces you to list every variant — so adding a variant later flags every switch that forgot it.

A Zig block can be labelled and used as an expression: break :search value exits the labelled block and makes it evaluate to that value. This removes the Go pattern of declaring a mutable variable before a loop just to capture a result computed inside it — the block itself becomes the value, and every exit path must produce the same type.

A Zig fn declares each parameter as name: Type and the return type before the body — no func keyword. Parameters are immutable values; to let a function modify the caller's data you pass a pointer (*i32), which Go would instead express by passing a pointer or returning the new value. Only pub fn declarations are visible outside the file.

Go returns several values as a tuple-like list and unpacks them with multiple assignment. Zig has no multiple return; instead a function returns an anonymous struct (.{ .low = ..., .high = ... }) whose type can be written inline. The caller reads named fields (result.low) rather than destructuring positionally, which avoids accidentally swapping the two values.

Zig passes functions as pointers typed *const fn(i32) i32, taking a function's address with &double. Unlike Go's func literals, a Zig function pointer cannot capture surrounding variables — there are no closures. When you need behaviour plus captured state, you define a struct holding the state and give it a method, passing the struct instead.

A Zig struct is bound to a const name (const Point = struct { ... }) — types are values. Struct literals must name every field (.x = 3); positional initialisation is not allowed, which prevents the bug of silently swapping fields. Like Go, there are no zero values you can rely on implicitly — each field gets a value at construction unless the struct declares a default.

Zig methods are functions declared inside the struct body whose first parameter is self, called with dot syntax (corner.distance()). It maps closely to Go's method receiver, but self is an ordinary explicit parameter — you choose self: Point to read, self: *Point to mutate — rather than declaring the receiver in a separate position before the method name.

A method that mutates takes self: *Counter, the direct parallel to Go's pointer receiver (counter *Counter). Zig auto-takes the address when you call a *self method on a mutable value, just as Go does. Note the field default count: i32 = 0, which lets Counter{} construct with no fields named — Zig's version of a usable zero value, but opt-in rather than automatic.

A Zig enum is a real distinct type, not an integer — where Go uses iota to make named int constants, Zig values are Color.green (or just .green when the type is inferred). A switch over an enum must cover every variant, so no else is needed here, and the compiler will reject the code if you add a colour and forget a branch.

Go expresses "one of a fixed set" with an interface and a method per type. Zig uses a union(enum) — a tagged union whose tag is an enum, so a value is exactly one variant and a switch pulls out the payload with |radius|. It is checked for exhaustiveness like an enum, and reading the wrong variant panics in debug mode instead of returning a nil interface or garbage.

Go's iota enums genuinely are integers, so int(heading) is a plain conversion and arithmetic on them compiles. A Zig enum is a separate type with no implicit integer value; you must ask for the underlying number with @intFromEnum (and convert back with @enumFromInt). This prevents accidentally doing arithmetic on a category that has no meaningful numeric order.

Zig encodes "maybe absent" in the type itself: ?usize holds a usize or null. Where Go uses a (value, ok) pair or a nil pointer that you might forget to check, Zig's if (optional) |value| unwraps the value only when it is present, and the compiler will not let you use a ?T as a plain T without unwrapping it first.

The orelse operator returns the optional's value if present, or the right-hand fallback if it is null — configured orelse "8080" in one expression. It is the concise replacement for Go's nil-check-then-assign. orelse can also run a block (orelse return, orelse unreachable), making the absent case explicit at the use site.

The if (optional) |value| { ... } else { ... } form is Zig's equivalent of Go's comma-ok idiom: the |value| capture binds only on the present branch. When you are certain a value is there, optional.? force-unwraps it and panics on null in safe builds — the deliberate, visible counterpart to dereferencing a Go nil pointer, which instead crashes unpredictably.

Zig replaces Go's (value, error) pair with an error union: PortError!u16 is "either an error from PortError or a u16." Errors are values of an error set, not strings or integers, so you cannot compare one to -1 or ignore it silently. The if (expr) |value| else |err| form handles both arms, and @errorName gives the error's name.

try expr is exactly Go's if err != nil { return ..., err } compressed into one keyword: it unwraps a success value or returns the error from the enclosing function. The function's return type !i32 infers the error set from everything it can propagate. This keeps the happy path uncluttered while still forcing every error to be handled or passed up.

Where try propagates, catch handles an error right where it happens: expr catch -1 supplies a fallback value, and expr catch |err| { ... } runs a block with the captured error. It is the symmetric partner to orelse for optionals, and it replaces Go's inline if err != nil block when you want to recover rather than propagate.

Zig adds errdefer alongside defer: it runs its cleanup only when the function returns an error, not on a normal return. This solves the "free on every error path but not on success" problem that Go can only express by duplicating the cleanup or restructuring the function — defer always runs, errdefer runs on the error path, and together they replace manual goto-cleanup logic.

There is no garbage collector and no global malloc in Zig. A function that allocates takes an std.mem.Allocator parameter, so the caller chooses the strategy, and every allocation is paired with an explicit free (here guaranteed by defer). The DebugAllocator even reports leaks at deinit. Go's make and the GC hide all of this; Zig makes ownership and lifetime your responsibility.

Both languages have defer for cleanup that runs as the scope exits, in last-in-first-out order. The key difference is scope: Go's defer always runs at function return, while Zig's runs at the end of the enclosing block. That makes Zig's defer usable for tightly scoped cleanup inside a loop body without deferring it until the whole function ends.

Go's append grows a slice transparently, reallocating behind the scenes. Zig's growable array is std.ArrayList(T): in 0.16 it is "unmanaged", so the allocator is passed to each call (append(allocator, value)) rather than stored. Growth can fail with an out-of-memory error — hence the try — and defer items.deinit(allocator) frees the backing storage. The elements live at items.items.

A FixedBufferAllocator hands out memory from a stack array with no heap involved — allocation is just a pointer bump, and reset() frees everything at once. Because it satisfies the same Allocator interface, any code written against std.mem.Allocator works with it unchanged. Go gives you no such control: dynamic memory always goes through the heap and the garbage collector.

Zig has no preprocessor and no separate constant-expression sublanguage: any top-level const can run arbitrary code at compile time — arithmetic, @sizeOf, calling functions, even building types. A comptime-known value can size an array ([max_items]i32). Go constants are restricted to a small set of constant expressions and cannot, for example, call a function.

Zig has no separate generics syntax — a generic function simply takes a comptime T: type parameter, because types are ordinary values at compile time. The compiler generates a specialised copy per type, like Go's monomorphised generics, but there is no constraint list: any type that supports the operations used in the body works, and a mismatch is reported at the call site.

Go inspects types at runtime through the reflect package, which carries a cost and defeats some optimisations. Zig does it at compile time: @TypeOf(value) yields the type as a value and @typeName turns it into a string, all resolved before the program runs. Combined with @typeInfo, this is how Zig generates code and validates structure with no runtime reflection at all.

Go's go launches a lightweight goroutine multiplexed onto its runtime scheduler. Zig has no runtime and no goroutines: std.Thread.spawn starts a real OS thread and returns a handle you join() to wait on. There is no built-in channel either — threads communicate through shared memory you pass in (here a *i32), which you must synchronise yourself.

For a shared counter, Go reaches for sync/atomic or a sync.Mutex plus a WaitGroup. Zig's std.atomic.Value(i32) is the direct parallel: fetchAdd(1, .monotonic) increments atomically with an explicit memory ordering. Zig makes the ordering visible at every operation rather than defaulting it, reflecting its general preference for spelling out exactly what the hardware will do.

Go silently wraps integer overflow, so uint8(255) + 1 quietly becomes 0. Zig treats overflow as a bug: the ordinary + panics in Debug and ReleaseSafe builds, and you must opt into wrapping with the explicit +% operator (or @addWithOverflow to detect it). The intent — wrap, saturate, or trap — is always visible in the code.

Here Go and Zig agree where most languages do not: both reject an unused local variable at compile time. Zig is even stricter — it also rejects an unused function parameter and a var that is never mutated — and the escape hatch is _ = value; to explicitly discard something you must keep but not use. Go, similarly, rejects unused imports outright.

Go's + on strings allocates a fresh backing array behind the scenes — convenient, but the cost is invisible. Zig has no hidden allocations: joining strings takes an explicit allocator via std.mem.concat, so memory use is always visible at the call site. Zig also has no operator overloading and no exceptions, so + is always a primitive and control flow never jumps to code you did not write.