Odin: A programming language made for me

Original Article ↗ Hacker News Discussion ↗

Zero Initialization (ZII) and Uninitialized Memory

  • Big thread on Odin’s “everything is zero-initialized”: critics say it silently propagates wrong values; they’d prefer compile‑time errors or hard crashes on reads before writes.
  • Defenders argue ZII removes undefined behavior and matches common OS behavior (zeroed pages), improving repeatability and security and fixing a notable fraction of bugs/CVEs linked to uninitialized stack use.
  • Others counter that ZII prevents compilers and analyzers from warning about missing initialization, turning logic errors into “valid” zero cases that are harder to catch.
  • Several comparisons:
    • Rust/C#/Dart do definite‑assignment analysis; Go/Odin/Java zero‑init.
    • Some want “dangerous” behavior (UB, wrapping, uninitialized) to be explicitly opt‑in.
    • Example code and Rust/C UB discussions emphasize that uninitialized variables literally have no value, not just “unknown” ones.
  • Odin still allows explicit uninitialized locals via a special --- syntax, and nil dereferences are defined to panic rather than be UB.

Safety, Ergonomics, and Software Quality

  • One camp wants stricter languages and more compile‑time guarantees, arguing software quality and security are broadly poor and rigor should be default.
  • Another camp pushes back on “everything must be Rust/Ada strict”, stressing many programs are not life‑critical and ergonomics, iteration speed, and test‑based correctness matter.
  • There is disagreement about how much risk in everyday software is acceptable (from calculators asking permissions to system‑wide outages) and whether striving for “better” should always trump practicality.

Odin vs C (and Rust/Zig)

  • Several argue C’s core semantics and type system (arrays, safety, UB) are too broken to “fix” via libraries; attempts to bolt on slices, defer, or better stdlibs hit hard limits.
  • Odin is seen as “what C would be if redesigned now”: tagged unions, slices, better stdlib, allocators, SoA support, generics, distinct types, multiple returns, context system, with C‑like simplicity and fast compilation.
  • Some note you can emulate many patterns in C (custom allocators, arenas, safer wrappers), but ergonomics and defaults are poor, and there’s no agreed replacement stdlib.
  • Rust and Zig are generally respected; Odin fans emphasize Odin’s lower conceptual overhead and familiarity for C‑style workflows rather than safety guarantees.

Data as Bytes vs Higher-Level Abstractions

  • One line of argument: as long as programmers think in “flat bytes and allocators”, abstraction leaks (e.g., painful SoA refactors) are inevitable; data types should be abstract, with layout left to the system except where explicitly constrained.
  • Many push back: in systems domains (games, HPC, compilers) cache locality and layout are the problem; compilers can’t infer intent or universally “figure out the optimal layout”.
  • Data‑oriented design and custom allocators are cited as crucial for performance; skepticism remains about “sufficiently smart compilers” solving layout, SIMD, and parallelism automatically.

Experiences Using Odin

  • Multiple users describe Odin as a “sweet spot” C‑replacement: procedural, low‑level, but with first‑class slices, dynamic arrays, maps, allocators, SoA attributes, and a well‑designed stdlib.
  • Game‑oriented workflows benefit from ZII, arenas, context passing, and SoA; some treat Odin almost like a compiled scripting language (simple syntax, near‑instant builds, Raylib bindings).
  • The implicit “context” feature sparks mixed reactions: powerful for cross‑cutting concerns (e.g., time contexts in games), but some worry about hidden coupling.

Ecosystem, Tooling, and Language Competition

  • Discussion of whether C, Odin, Zig, Jai, etc. will coexist or whether one low‑level language will capture most mindshare; many expect Rust to dominate industry jobs, with others remaining niche.
  • Odin has good C FFI, but still lacks broad tools, tutorials, and AI‑assistant support; LLM autocompletion is reported as weak due to low training exposure.
  • Some worry that many niche languages fragment ecosystems and duplicate effort; others see diversity and domain‑specific trade‑offs as healthy.