Odin, a pragmatic C alternative with a Go flavour

Language role and target audience

• Widely perceived as a pragmatic, game-dev–oriented C successor: simple, fast, data‑oriented, with “just enough” modern features.
• Several commenters say it feels closer to a “better Pascal” than a direct C replacement, but intentionally designed to be comfortable for C programmers.
• Compared to Zig/Rust, Odin is viewed as less ambitious in safety and metaprogramming, more focused on straightforward manual control.

Features and day‑to‑day ergonomics

• Praised for “batteries included” standard/vendor libraries (e.g. Raylib integration with no external setup).
• Positive reports from multi‑kLOC projects: feels higher-level than C while retaining low-level control; attractive for game and graphics work.
• Absence of OOP and methods is framed as a feature; structs + parametric polymorphism, procedure overloading, and data‑oriented design are emphasized.
• Some missing/annoying points: no namespaces (workarounds via prefixes), no official package manager, explicit context handling in callbacks, and banned conditional imports.

RTTI, compile-time reflection, and imports

• One thread criticizes mandatory RTTI and asks for pure compile-time introspection; Odin does have compile-time reflection but deliberately makes it less trivial to use.
• The language author argues for RTTI as a fixed, predictable cost versus template/CTTI approaches that generate lots of specialized code and bloat binaries.
• Conditional imports were removed because they interacted poorly with package/platform features and type-checking order; some users miss them and resort to #load hacks or when-based aliasing.

Metaprogramming and comparisons (Zig, Go, D, C3, etc.)

• Debate over whether Zig truly “embraces metaprogramming for everything”: several commenters distinguish generic/comptime use from true meta over types/AST, and say heavy meta is used sparingly in serious Zig code.
• C macros and AST macros are discussed as powerful but hard to debug; others counter that Lisp-style macro debugging is relatively tractable.
• D is generally characterized as a C++ alternative or “kitchen sink” language, not in the spirit of C; BetterC is seen by some as a migration aid rather than a true C replacement.
• C3, Hare, Nim, Go, Jai, V, Ada are all mentioned as alternative points in the “C successor” design space, with differing trade‑offs in complexity and philosophy.

Memory safety and allocation model

• Odin is explicitly not memory safe in the Rust sense and does not prevent use‑after‑free.
• It is described as “safer than C” via default bounds checks, slices (ptr+len), proper enums, tagged unions, distinct types, and more compile‑time checks (e.g. switch exhaustiveness).
• Strong encouragement to use arena or lifetime‑based allocation instead of ad‑hoc malloc/free-style patterns, as a pragmatic way to reduce lifetime bugs.

Maturity, marketing, and adoption

• Language surface is said to be essentially “done”; ongoing work is mainly libraries (notably a replacement core:os), tooling, and vendor packages.
• No formal roadmap or 1.0 date is promised; development is mostly volunteer‑driven, with an emphasis on not over‑promising.
• Odin is in production in some commercial/embedded contexts, but one commenter questions its long‑term viability and contrasts its perceived direction and “seriousness” with Zig’s marketing and toolchain.
• The project intentionally avoids hype; several note that this makes it harder to market compared to languages with a single “killer feature”.

Style, naming, and ecosystem notes

• Odin itself is agnostic about naming; house style is snake_case for procedures/variables and Ada_Case for types, while foreign bindings retain their original conventions.
• Discussion of capitalization conventions across C, Pascal, Go, etc., and how they shape a language’s “feel”.
• GUI work is being done via libraries like Dear ImGui; desktop GUI ecosystem beyond that is unclear from the thread.