Why I use Odin over Zig for everything

Summary

The speaker explains why they prefer Odin over Zig for their C-like, game-development, and general-purpose work. They consider both languages capable, but find Odin more enjoyable and practical to write. Their comparison is based on personal experience, and they acknowledge that their familiarity with Odin may bias their view.

Style and methods

Odin deliberately avoids methods, which the speaker feels encourages treating data as part of larger groups rather than as isolated objects. That mindset can work well with techniques such as arena allocation and, in their view, makes Odin code easier to translate from C. Zig has methods and other features that can make its code diverge more from C.

Allocators and collections

Both languages have explicit allocator concepts and standard libraries built around them. The speaker prefers Odin’s default of using the allocator in the current context, while allowing explicit allocator parameters when needed. They find Zig’s requirement to pass allocators into many operations—including each dynamic-array or list operation—unnecessarily repetitive and potentially error-prone.

Odin collections retain their allocator, so it cannot be changed accidentally between operations. The speaker also notes that Odin can enforce more explicit allocator passing through a file setting.

Error handling

The speaker dislikes Zig’s special error types, arguing that they can force a dedicated enum even when a Boolean would suffice, or require a separate output parameter for useful error details. They prefer Odin’s error-handling operators, which work with ordinary types such as Booleans, enums, unions, and pointers. Odin can also use if statements for direct error handling and deferred checks.

The speaker acknowledges that Zig’s approach can make error paths more explicit and may help distinguish likely and unlikely paths, but considers that benefit limited in many cases.

Compile-time execution and reflection

The speaker likes Zig’s general idea of arbitrary compile-time execution but thinks it can be overused. For tasks such as printing and serialization, they prefer Odin’s runtime reflection, which provides type information through a compiler-generated table. They argue that this can simplify interfaces and avoid duplicating generic code for each type. Reflection can also be omitted when it is not needed.

Other language design choices

The speaker finds Zig’s variadic arguments and some built-ins less intuitive, and prefers Odin’s use of keywords for certain operations. They also favor Odin’s approach of using few implicit casts, even for integer widening, over Zig’s extensive explicit-cast system.

C interoperability and builds

Zig can directly parse C headers, which the speaker sees as convenient in theory but potentially troublesome in practice. Odin bindings are explicit, allowing developers to rename or hide functions, adjust types, add overloads, and omit declarations. C-header tools can still be used to generate Odin bindings that developers can then edit.

The speaker sees Zig’s build system, written in Zig, as useful for some projects but unnecessary for many, where Odin’s build command or a shell script may be enough.

Where each language may fit

The speaker suggests Zig may be a better fit for some lower-level work, including embedded systems and operating-system development. Odin better suits their own game development, tools, and user-facing software.

They conclude that Zig may make it easier to write correct and safe programs, but Odin better matches their preferred C-like style and workflow.

Reviews, guides, or tutorials

This is a personal language comparison and analysis; it does not present a step-by-step guide or tutorial.

Main speaker/source

The video’s creator, rats159, speaking from their own experience with Odin and Zig.