Odin References & Tooling

Every entry below is free except the book, which is a paid digital edition, and every one was checked against the official Odin site or the project's own repository. The shortest path remains your own machine: install the compiler from the official guide, and everything in this track — including all seventeen lab examples — runs with one command.

Official Documentation

One rule about Odin's documentation is worth adopting now: when a claim on a blog, a video, or a forum post disagrees with these pages, these pages win. They are written by the language's author and kept in step with the compiler, so the version that matches your installed toolchain is the version that matters.

The Truth Sources

Two of those deserve a habit attached. Read the FAQ once, from beginning to end: it explains the absence of a garbage collector, the decision to have no classes, and the other choices that new arrivals trip over. And keep the Package Documentation open while you write code — the quickest way to learn Odin's standard library is to look for the procedure you were about to write yourself.

Tools Worth Installing

The compiler is the only tool you strictly need. The others remove work you would otherwise do by hand, and the first one — the language server — pays for itself on the first afternoon.

Editor Support and Everyday Tools

The OLS project also answers the question the setup lesson raised, and it turns out the answer is more interesting than "there is one style, take it or leave it". The formatter is installed with the language server, on Windows with ./odinfmt.bat and elsewhere with ./odinfmt.sh, and it reads a small odinfmt.json at the root of your project. Quoted from the project's own file, the whole configuration is three settings:

{
	"character_width": 120,
	"tabs": true,
	"tabs_width": 4
}

Those defaults are the style the standard library and the official examples are written in — which is exactly why arguing about them is pointless. If you use OLS, formatting is on by default: its enable_format option, quoted from the project's list, "Turns on formatting with odinfmt" and is enabled unless you turn it off.

One more thing OLS offers that is worth knowing before you need it: the language server is configured by an ols.json in the workspace, and among its settings are checker_path and defines. The defines entry is where you tell the server about the same compile-time constants you pass to odin build — so your editor's diagnostics match the build you are actually making.

Learning Beyond This Track

One book carries the Odin name, and it is written by somebody who ships programs in the language. It is the natural next step when a chapter here felt too short.

The Book and the Blog

The blog is worth a specific recommendation, because two of its posts cover ground this track only summarises: one on the temporary allocator and arenas, and one on the mistakes people make when combining arena allocators with dynamic arrays. Both are the sort of article that makes Phase 4's allocator rules feel obvious in hindsight — and the second one is a warning about the exact combination this track told you to think carefully about.

Practice

Reading builds recognition; writing builds fluency. The best practice material for Odin is the language's own example collection, because the examples are required to pass a strict style gate before they are accepted.

Exercises That Teach

One detail from the examples repository tells you what the community expects of code, and it is a good target to aim at. Quoted from the contribution guide, an example must compile with these flags before it is accepted:

-vet -strict-style -vet-tabs -disallow-do -warnings-as-errors

That is the whole of Odin's style argument in one line: extra diagnostics on, a strict style check, tabs enforced, a banned construct, and warnings treated as errors. Turn the same set on for your own project and your code will be welcome anywhere — including in a pull request to the language itself.

Reading Shipped Code

Every language has a moment when reading other people's code becomes more instructive than reading a tutorial. Odin makes that moment easy to reach, because the standard library is ordinary Odin source sitting in your installation.

Repositories and Real Programs

The showcase is worth a look for a different reason than the source code: it answers "is this language for real?" with a list. Among the entries are EmberGen, LiquiGen, IlluGen and GeoGen — real-time simulation and procedural asset tools by JangaFX — along with Blick, a native video editor, Vigil, a source navigation workspace, Todool, an editor, and the two tools from the previous section, OLS and Spall. These are not demonstrations; they are products that people use.

Community and Help

Asking a good question is a skill, and Odin's community makes it easy to practise, because the channels are clearly divided by purpose.

Where to Ask

A Practical Ladder

A track ends, but learning does not, and the gap between "I finished the tutorial" and "I can build something" is crossed by doing things in the right order. This ladder is short on purpose.

The Six Steps After This Page

1. Run all seventeen lab examples on your own machine, one per sitting. Type the harder ones instead of downloading them.
2. Build the three study projects and then change them: make the linked list generic, give the stack a test that fails, make the word counter read from somewhere else.
3. Work through absolute_beginners, then the folders whose topics you have not touched — json, simd, arena_allocator, command_line_arguments. These are folders I confirmed exist in the official repository, and each is a single concept done well.
4. Read core in your installation, starting with the packages this track used. Standard-library code is where you see the style and the idioms applied without compromise.
5. Write a program you actually want. A tool, a game, a converter — anything with a reason to be finished. This is the step that turns knowledge into skill, and the only one with no shortcut.
6. Give something back. Fix a documentation mistake, answer a question in Discord or on the forum, or pick up an issue labelled help wanted.

Notice what is not on the ladder: rushing to a framework, or collecting a list of libraries. Odin rewards understanding the machine underneath — memory layout, allocators, the cost of a copy — and every step above builds that understanding rather than borrowing it.

Closing Words

You began this track with a program that printed a line of text and an unfamiliar idea: that a language could be simple and honest at the same time. Twenty-one lessons later you have written structs that copy, slices that view, dynamic arrays that own; you have named allocators, deferred releases, propagated errors without exceptions, and made one body work for many types. You have run work on several threads and asked the compiler to decide things while building instead of while running.

None of that was learned by reading. It was learned by typing, breaking, and fixing — which is why the ladder above starts with running the examples rather than with another book. The language is now yours to use, and the sources on this page will keep it honest.

Welcome to Odin. Fall in love with programming all over again.