Odin: the C alternative whose compiler is still in development

A switch over a string, with no return value and no error checks

The example program in this repository is short enough to read in one pass, and its inner loop is the clearest statement the project makes about itself:

main :: proc() {
	accumulator := 0

	for token in program {
		switch token {
		case '+': accumulator += 1
		case '-': accumulator -= 1
		case '*': accumulator *= 2
		case '/': accumulator /= 2
		case: // Ignore everything else
		}
	}

main takes no arguments and returns nothing, so there is no error path to handle anywhere in the program. The switch has a bare case: arm that swallows the spaces in the input string, and the compiler never asks you to say what happens next. Iteration over a string yields characters rather than bytes, which is why the program string in the example can hold an emoji as its own case. The README's tagline calls this the Data-Oriented Language for Sane Software Development.

Monthly dev tags with letter suffixes, and no stated support window

Releases are named by month rather than by version number. The three most recent are dev-2026-10, published on 2026-10-06, dev-2026-09 on 2026-09-01, and dev-2026-08 on 2026-08-06. Nothing in the release names promises compatibility across them. A separate Nightly Builds channel sits alongside the monthly tags. Under both channels sits the project's own warning, the last line of the README: the Odin compiler is still in development. The repository is not idle either, its last push was on 2026-11-02. Consequence for a team that pins a toolchain: you choose between a monthly tag and a nightly that changes continuously, and neither carries a compatibility guarantee, so a compiler upgrade belongs in its own branch rather than inside a dependency bump.

No install command here, only build_odin.sh and a compiler that runs its own examples

No install command appears anywhere in this repository. Downloading and installing the compiler and libraries is delegated to the Getting Started page at odin-lang.org/docs/install, nightly builds have their own page, and package documentation for the core and vendor collections lives at pkg.odin-lang.org. What the repository does carry is the source build. The first Makefile target is all, which depends on default, and default is the debug build:

./build_odin.sh debug

Two further targets put the compiler to work on itself. One runs the bundled example with the -file flag:

./odin run examples/demo/demo.odin -file

the other invokes a report subcommand:

./odin report

Consequence: there is nothing to copy from this page for a quick install, and your real choice is a platform-specific installer found off-site or compiling the compiler yourself. When you do compile, the examples are run by the binary you just built, so a regression in the compiler surfaces first as a failing demo target.

Four build variants, two script front ends, and an LLVM DLL in the tree

build_odin.sh exposes four entry points, and the Makefile gives each one a target: debug, release, release-native (also reachable as release_native), and nightly. Nothing in the repository explains what release-native changes relative to release, so anyone choosing between them does so on guesswork. Windows has its own script set, build.bat, build_vendor.bat and check_all.bat, mirroring build_odin.sh and check_all.sh on the Unix side, with shell.nix covering the Nix path. At the top level sits LLVM-C.dll, a Windows dynamic library committed next to the source, which is the visible sign that the compiler links against LLVM. Consequence: take the variant from build_odin.sh rather than from the Makefile alias, and expect to solve the LLVM dependency yourself on any platform where that committed DLL is not what your toolchain already provides.

core, vendor and base live in the tree with no dependency manifest

The source tree is arranged in layers: src/ for the compiler, base/, core/ for the core library collection, vendor/ for the vendor library collection, shared/, then tests/, ci/, misc/ and bin/. Third-party libraries are not resolved at build time. They are checked in, and build_vendor.bat exists to rebuild them. No manifest of pinned versions appears anywhere in the top level entries. Consequence: adding a dependency means editing vendor/ by hand, and upgrading one means merging somebody else's pinned version into your compiler tree by hand. You also inherit whatever license and staleness the checked-in copy happened to have at the commit you took, with nothing in the build to tell you that it drifted.

PROPOSAL-PROCESS.md and odin.ebnf keep the rules in version control

Two root files change how you evaluate the project. PROPOSAL-PROCESS.md sits at the repository root, which suggests language changes go through a proposal process, and the announcement channel beside it is the project blog at odin-lang.org/news with the Discord as the support surface. odin.ebnf is an EBNF grammar of Odin kept in the tree, so you can diff the language surface between two compiler versions instead of trusting release notes to tell you what moved. Around them sit codecov.yml, ci/ and check_all.sh, which is the test and coverage scaffolding. Consequence: the language you can write is the grammar in that file, and the route to changing it runs through the process document. For a team that is a clear answer about who decides. For a solo project it is a waiting list.

The README is an index, and the normative text is four other places

What this page does not contain is most of what a reader needs. The overview of the language, the FAQ, the install instructions, the nightly builds and the general documentation are all separate pages on odin-lang.org. Package documentation for the core and vendor collections is generated at pkg.odin-lang.org. Idiomatic code lives in a separate repository, odin-lang/examples, which is a different cadence from the compiler itself, while examples/README.md, examples/all/ and examples/demo/ here cover the in-tree cases. Consequence: this page cannot be used as a specification, and pinning a compiler tells you nothing about which docs you are reading, because the pages on the site move with the language while your tag does not. If you are adopting Odin, read the overview page and the FAQ before reading this repository, and treat the examples repository rather than the release tag as your compatibility reference.

Editorial conclusion

Odin fits a team that wants C-shaped performance work with data-oriented types in the language and is willing to own the toolchain: build the compiler from src/, vendor dependencies by hand, and give every compiler upgrade its own branch. It does not fit a team that needs a stable language contract today, because the project states the compiler is still in development and the three most recent releases are monthly dev tags rather than versioned ones. Verify two things first: whether release-native gives you something you need that release does not, since the repository does not distinguish them, and whether the vendor/ tree already holds the library versions your build expects, since nothing here records them for you.

Frequently asked questions

Official sources

1. License: Zlib
2. odin-lang/Odin on GitHub
3. Project website
4. README
5. Releases