Ruby.CodeCompared.To/Zig

Every Zig program begins with const std = @import("std"); — there is no automatic prelude. The pub fn main() !void signature declares that main is public and may return an error (the ! prefix means "error union with void"). The try keyword propagates any error that stdout.print might return. Unlike Ruby's puts, Zig's writer does not add a newline automatically — \n must be explicit.

Zig uses only // single-line comments — there is no block comment syntax like /* ... */. The triple-slash /// is a "doc comment" that attaches documentation to the declaration that follows it; it is only valid immediately before a declaration, not inside a function body. The intentional omission of block comments keeps the grammar simpler and avoids ambiguity when commenting out code that itself contains comments.

Zig enforces the var / const distinction at the compiler level — assigning to a const binding is a compile error, not merely a convention. In Ruby, LIMIT = 100 is a constant by convention and the interpreter only warns (not errors) when you reassign it. In Zig, every variable must have an explicit type annotation unless the type can be inferred from a literal (e.g. const x = 42; infers a comptime integer). All local variables must be used; an unused variable is also a compile error.

Zig's stdout.print uses format specifiers inside curly braces: {d} for integers, {s} for strings, {} for the default representation. The argument list is always passed as an anonymous struct literal .{arg1, arg2}. Note that std.debug.print writes to stderr, not stdout — it is intended for debugging and is not suitable for program output that other processes might consume. All stdout.print calls return an error and must be preceded by try.

Zig has no nil — the absence of a value is expressed through the optional type ?T (see the Types section). The undefined keyword is a special initializer that leaves memory uninitialized, telling the compiler "I will fill this in before I read it." In Debug and ReleaseSafe builds, Zig fills undefined memory with 0xaa bytes so that reads before assignment cause obvious corruption rather than silent bugs. Reading from undefined memory is still safety-undefined behavior and will trigger a panic in safe modes.

Zig has explicit-width integer types: i8, i16, i32, i64, i128 (signed) and u8, u16, u32, u64, u128 (unsigned). Unlike Ruby's arbitrary-precision Integer, Zig integers have fixed ranges and will panic on overflow in Debug mode. Zig also supports arbitrary-width types like i7 or u3 — any bit width from 0 to 65535 is valid. The platform-pointer-sized types are usize and isize, equivalent to C's size_t.

Zig provides f16, f32, f64, and f128 floating-point types. Ruby's Float is always a 64-bit IEEE 754 double. In Zig, the precision specifier {d:.2} in a format string controls decimal places directly — there is no equivalent of Ruby's round method. There are no implicit conversions between integer and float types: to assign a f32 value from an i32, you must use @floatFromInt(value).

Zig uses the keywords and, or, and ! for logical operations — there are no && or || operators (those are bitwise in Zig). The boolean type is bool, and its only values are true and false. Unlike Ruby, where any value except nil and false is truthy, Zig requires boolean expressions to be of type bool — an integer 1 is never implicitly truthy in an if condition.

Zig's optional type ?T is similar to Ruby's nilable values, but the compiler forces you to handle the null case before accessing the inner value. The if (maybe) |value| syntax unwraps the optional into value if it is non-null — there is no way to accidentally call a method on null as you can in Ruby. The orelse keyword provides a default: maybe orelse 0 returns 0 if maybe is null. This is the same guarantee that Ruby's &. safe navigation operator tries to provide, but enforced at compile time.

Zig has no implicit type conversions — every conversion must be explicit using a builtin function. @floatFromInt converts an integer to a float, @intFromFloat truncates a float to an integer, and @intCast converts between integer widths (panicking in safe builds if the value does not fit). This is the opposite of Ruby, which converts freely with to_f, to_i, and to_s. The explicit-cast requirement catches a whole class of bugs at compile time that would silently produce wrong values in more permissive languages.

Zig string literals are not objects — they are pointers to null-terminated byte arrays (*const [N:0]u8). They do not have methods; you use functions from std.mem, std.fmt, and std.ascii instead. The ++ operator concatenates two strings at compile time only — runtime concatenation requires a heap allocator. The length is accessed via .len, not a method call. This is fundamentally different from Ruby's String, which is a full object with rich mutation methods and automatic memory management.

Zig's multi-line string syntax uses a \\ prefix on each line instead of delimiters. Each \\ line contributes its content plus a newline character to the string; the \\ itself is not part of the value. This makes it easy to write strings containing double-quote characters without escaping, and the indentation of the \\ markers is arbitrary and not included in the string. The resulting value is still a compile-time constant byte slice — not a runtime heap object.

Zig's format string syntax places the type specifier and options together inside {}: {s} for strings, {d} for decimals, {d:.2} for two decimal places, {s:<10} for left-aligned in a 10-character field. To build a formatted string rather than print it directly, std.fmt.bufPrint writes into a fixed-size stack buffer, while std.fmt.allocPrint allocates on the heap. There is no string interpolation with #{} — formatting is always an explicit function call.

Because Zig strings are byte slices (pointers plus length), the == operator compares memory addresses, not content. To compare string values you must use std.mem.eql(u8, a, b), which performs a byte-by-byte comparison. There are no string methods — all string operations are functions in the standard library: std.mem.indexOf for searching, std.ascii.toUppercase for case conversion, std.mem.startsWith and std.mem.endsWith for prefix/suffix checks.

Zig arrays have a fixed size that is part of the type: [5]i32 and [3]i32 are different types. The size must be known at compile time. Unlike Ruby arrays, Zig arrays cannot grow — they are stack-allocated value types with no associated heap memory. Negative indexing (Ruby's numbers[-1]) does not exist in Zig; the last element is always numbers[numbers.len - 1]. Out-of-bounds access in Debug or ReleaseSafe mode triggers a panic rather than returning nil.

A Zig slice ([]T or []const T) is a fat pointer — a pair of (pointer, length) — that references a contiguous sequence of elements without owning them. Slicing numbers[1..4] creates a view into the original array from index 1 up to (but not including) index 4. Unlike Ruby's Array#slice, a Zig slice does not copy the data. Functions that accept a variable-length collection typically take a slice rather than an array, making them work with any source array of the correct element type.

Zig's for loop iterates over a slice or array by capturing each element in a |capture| block. To get the index simultaneously, pass two iterables — the array and a range starting at 0.. — separated by a comma: for (items, 0..) |item, index|. The [_] syntax lets the compiler infer the array length. There is no equivalent of Ruby's Enumerable — operations like map and filter must be written as explicit loops, though the standard library provides some helpers in std.mem.

Dynamic arrays in Zig require an explicit allocator because there is no garbage collector. std.ArrayList(T) is the standard dynamic array. It must be initialized with an allocator and explicitly freed with deinit(). The defer keyword ensures cleanup happens at scope exit even if an error occurs, which is idiomatic Zig. The underlying slice of items is accessed via .items. Every append call returns an error (if allocation fails) and requires try.

Zig's if is an expression that can appear anywhere a value is expected, similar to Ruby's inline if. When used as an expression, both branches must produce the same type — the compiler will reject a mismatch. Unlike Ruby, the condition must always be of type bool; you cannot write if (count) where count is an integer. There is no ternary ?: operator — the if/else expression fills that role cleanly.

Zig's while loop has an optional "continue expression" in parentheses after the condition: while (condition) : (continue_expr). The continue expression runs at the end of each iteration (including after continue statements, unlike if you put the update inside the body). This is idiomatic for counter-based loops. There is no do...while — use while (true) { ... if (done) break; } instead. Zig also has no loop { ... } keyword; while (true) is the idiom for infinite loops.

Zig's switch is exhaustive — the compiler requires every possible value to be handled, or an else catch-all to be present. This catches the "forgot a case" bug that case/when in Ruby silently ignores by returning nil. A switch is also an expression and can be assigned directly. Enum members are referenced with a leading dot (.monday) when the type is known from context. Multiple values can be matched in one arm by separating them with commas.

Zig's labeled blocks allow breaking out of nested loops and returning a value from any block expression. A label is an identifier followed by a colon placed before the block: search: {. Breaking with break :search value exits the labeled block and provides the block's value. This is more explicit than Ruby's throw/catch mechanism and replaces both labeled next/break from Ruby and the need for helper functions to exit nested loops.

Zig functions require explicit parameter types and a return type — there is no type inference for function signatures. Default parameter values do not exist; optional parameters are typically achieved through an options struct. Every parameter is immutable by default (it is a copy in Zig's value-type world). The _ = name; idiom discards an unused parameter to satisfy the compiler's requirement that all bindings be used. Functions not marked pub are private to their file.

Zig does not have multiple return values in the way Go does. The idiomatic approach is to define a small struct and return it. This is efficient — small structs are often returned in registers — and it gives the fields meaningful names. Anonymous struct literals .{ .minimum = x, .maximum = y } let you construct the return value without repeating the type name. In Ruby, returning an array and destructuring with a, b = func() achieves the same effect more concisely, but at the cost of losing field names.

Zig's defer is similar to Ruby's ensure — the deferred statement runs when the enclosing scope exits, whether normally or due to an error. Multiple defer statements execute in reverse order (last-in, first-out). There is also errdefer, which runs only if the scope exits with an error — useful for rollback logic. Unlike Ruby's ensure, which is a block, Zig's defer takes a single expression, so multi-step cleanup typically uses a block: defer { cleanup1(); cleanup2(); }.

Zig supports recursion in the same straightforward way as Ruby. One important difference is stack size: Zig programs have a fixed stack (typically 8 MB), and deep recursion will overflow it just as in C. There is no tail-call optimization guarantee in Zig. For deeply recursive algorithms, an iterative approach with an explicit stack is preferred. In Debug mode, Zig does include stack overflow detection via guard pages that produces a clear panic message rather than silent corruption.

Zig errors are not exceptions — they are values. An error set is declared with const MyError = error { Foo, Bar };, and a function that can fail returns an error union type written as ErrorSet!ReturnType. The set of possible errors is part of the function's type signature, visible to callers at compile time. Unlike Ruby's exception hierarchy, which uses runtime objects, Zig errors have no payload — they are just enum-like tags. Additional context (a message, a line number) must be passed through other means such as a logging function.

Zig uses two complementary keywords for error handling. try expr is shorthand for expr catch |err| return err — it propagates any error to the caller. expr catch |err| recovery handles the error inline and provides a fallback value. The catch block can be a single expression or a labeled block (blk: { ... break :blk value; }). Unlike Ruby's rescue, there is no stack unwinding — Zig errors are returned through the normal call stack and have zero runtime overhead compared to a successful return.

The special anyerror type is a superset of all error sets — it can hold any error value in the program. Using anyerror!T as a return type accepts errors from any source, similar to how Ruby's rescue StandardError catches most exceptions. However, Zig prefers precise error sets because they document exactly what can go wrong and let the compiler verify exhaustive handling. The anyerror type is best reserved for interfaces and generic code where the exact errors are not known in advance.

Zig structs are value types, not reference types. When you assign a struct to a new variable, the entire struct is copied. This is the opposite of Ruby objects, which are always references — assigning b = a in Ruby gives b a reference to the same object. Struct fields are accessed with dot notation the same way as Ruby. All fields must be named — there are no positional-only fields. Default field values can be provided: const Point = struct { x: i32 = 0, y: i32 = 0 };.

Zig structs can contain functions — when the first parameter is self: TypeName, the function can be called as a method with dot syntax. There is no self magic — it is just a named parameter and could be called anything, though self is the convention. Methods are not inherited; there is no class hierarchy. The pub keyword makes a method accessible outside the file. Zig has no equivalent to Ruby's to_s protocol — custom formatting is done by writing a print-style method or using std.fmt.Formatter.

Zig structs support default field values, making it easy to create "builder"-style patterns. The anonymous struct literal .{} with no field overrides produces a struct where every field takes its default value. Named fields can be selectively overridden: Config{ .port = 9090 } gives a struct with host and timeout at their defaults but port set to 9090. This pattern is common for configuration objects and closely mirrors Ruby's keyword arguments with defaults, but without keyword argument syntax — all fields are always named.

Zig has no garbage collector. Every heap allocation requires an explicit allocator, and every allocation must eventually be freed. The allocator pattern means you can swap allocators without changing the code that uses them — a library that accepts an Allocator parameter can use a general-purpose allocator in production and a fixed-buffer allocator in embedded or testing contexts. This is the fundamental trade-off compared to Ruby: Zig gives you complete control over memory layout and lifetime, but you must manage that lifetime yourself.

The GeneralPurposeAllocator is Zig's debug allocator — in Debug and ReleaseSafe builds it tracks every allocation and reports leaks, use-after-free errors, and double-frees when deinit() is called. In ReleaseFast builds it degrades to a thin wrapper around the OS allocator with no overhead. The standard pattern is to declare it on the stack with var gpa = std.heap.GeneralPurposeAllocator(.{}){} and then call gpa.allocator() to get the allocator interface. For production builds where performance matters more than leak detection, std.heap.c_allocator or a custom allocator may be preferred.

The ArenaAllocator allows many allocations without individual frees — all memory is released at once when arena.deinit() is called. This pattern is ideal for request-scoped work (a web server request, a compiler pass, a game frame) where the lifetime of all temporary allocations is tied to a single event. It is significantly faster than general-purpose allocation for many small objects because it never calls free on individual items. This approximates the way Ruby's GC handles per-request objects in a web application, but with deterministic timing.

Zig's comptime system allows arbitrary computations to run during compilation, not at program startup. Any expression that operates only on compile-time-known values is automatically evaluated at compile time; the comptime keyword forces a block or expression to be evaluated at compile time and causes a compile error if it cannot be. Unlike Ruby's constants, which are evaluated once at load time but still involve runtime code, Zig comptime values have zero runtime cost — they are embedded directly in the binary as immediate values.

Zig achieves generics through comptime type parameters. A parameter declared comptime T: type receives a type as its value at compile time, and the compiler generates a specialized version of the function for each distinct type used. This is similar to C++ templates but with a much simpler mechanism — it is just normal Zig code that happens to run at compile time. Unlike Ruby's duck typing, which resolves method dispatch at runtime, Zig generics are fully resolved at compile time with no runtime cost and with complete type checking.

Zig's @TypeOf(expr) and @sizeOf(T) are builtin functions that execute at compile time. @TypeOf returns the type of an expression, which is useful in generic code to capture and pass along a type. @sizeOf returns the number of bytes a type occupies in memory — information that does not exist in Ruby at all (since Ruby objects are always heap-allocated references with opaque internal structure). These builtins let you write self-describing, portable code without hardcoding platform-specific sizes.

Zig enums are named types with a fixed set of variants, providing stronger guarantees than Ruby's symbol convention. The compiler ensures exhaustive handling in switch expressions — if you add a new variant to the enum, every switch that lacks an else clause becomes a compile error. By default, Zig enums are backed by an integer and can be converted with @intFromEnum and @enumFromInt. Enums can also contain methods and declarations, just like structs.

A tagged union (union(enum)) is Zig's equivalent of a type-safe discriminated union or algebraic data type. It stores exactly one of its variants at a time and carries a tag that identifies which variant is active. A switch on a tagged union is exhaustive and captures the inner value with |capture| syntax. This pattern replaces Ruby's duck typing for "value that can be one of several different shapes" — where Ruby relies on runtime checks, Zig enforces the variant at compile time and eliminates invalid states entirely.

In Debug and ReleaseSafe builds, Zig's default arithmetic operators (+, -, *) panic on integer overflow. This is a deliberate safety feature — silent overflow produces subtly wrong results that are hard to debug. When overflow is intentional (e.g., cryptography, hash functions, wrapping counters), use the wrapping operators: +%, -%, *%. For DSP and saturation arithmetic, use the saturating operators +|, -|, *|. In ReleaseFast mode, overflow detection is removed and the behavior is undefined by the language spec (though in practice wraps on most hardware).

Zig never coerces types silently. Adding an i32 and an f64 is a compile error — you must explicitly convert one type to the other first. There is no + operator for string concatenation (only the comptime ++ for compile-time strings), and no automatic number-to-string conversion. This verbosity is intentional: every type boundary is visible in the source code, making it impossible to accidentally mix units, precision levels, or signed/unsigned values without the compiler catching it.

In Zig, you cannot use a ?T optional value where a T is expected — the compiler rejects it. This eliminates null pointer dereferences at compile time rather than catching them as runtime exceptions. The .? postfix operator (e.g. maybe.?) forcibly unwraps an optional and panics if it is null — use it only when null is a programming error, not a normal condition. This is a fundamental improvement over Ruby's nil, where the error only appears at runtime when the wrong method is called.

Zig treats an unused local variable as a compile error, not a warning. This catches dead code, forgotten return-value checks, and typos where you meant to use a variable but referenced the wrong name. To intentionally discard a value, assign it to the blank identifier _: _ = someFunction();. This also applies to function parameters — if a parameter is not used, you must write _ = parameterName; to silence the error. The same rule applies to unused error return values: calling a function that returns an error without handling it is a compile error.