Learning Odin this year
To just compile the binary, use odin build day_XX. This produces a binary for your OS. Then run the binary like any other binary.
Use odin run to compile and run the programs in one step: odin run day_XX.
Example output:
+--------------------------------------+
| Advent of Code - Day 1 |
+----------+------------+--------------+
| Part | Result | Time |
+----------+------------+--------------+
| Part 1 | 2580760 | 1.27897ms |
| Part 2 | 25358365 | 2.176693ms |
+----------+------------+--------------+
By default all the programs load the input from ./day_XX/input.txt (relative to the binary)
Pass a filepath as the first argument to load another file:
./day_01.(bin|exe) my_day_1_input.txt
Wenn using odin run you need to add a double-dash to pass arguments to the binary instead of the compiler: odin run day_01 -- my_day_1_input.txt
Unit-tests can be run using odin test day_XX.
The tests folder contains a package that requires every other package and can be used to run all the tests at once (the github actions run these tests): odin test ./tests -all-packages
Now that I've collected all the stars let me also collect my thoughts on Odin:
Odin is a very pragmatic language. Everything in its design is there to solve a problem. It's a refreshing sight in modern days, were every new language comes with a "killer-feature" that adds unneeded complexity.
Odin is basic like c, but with very nice additions that make it very suitable for modern software development. No need for a build-system, packages are just folders you import, testing is a part of the core-library. You write code for the problem you have, nothing more and nothing less.
The creator of Odin has a physics-background and works on real-time VFX software, so it is no surprise Odin natively supports array-programming, swizzling, matrices and complex-numbers (as well as other things I probably don't understand).
I haven't used most of these things during Advent of Code, but I've written my fair share of math-code in my time working on CAD software (although I always seem to forget the theory immediately afterwords...). The math-code you can write in Odin is so nice to read, and it integrates great with rendering-code.
The core packages provide a ton of useful functionality, most of which I haven't touched during this event but I've read through a lot of it. It's evident, that the creators of Odin actually use the language for commercial purpose.
The vendor packages contain bindings to popular rendering-libraries like sdl and raylibg, wrappers around every graphics-API and so much more. I'm probably going to use Odin, if I need some graphics-rendering in the future.
It's also very easy to read and understand, which you kind of need to do if you dive deeper into the language.
Odin is so simple and solutions-oriented, that it might hinder you if you're used to different languages.
For example, it took me some time to get the lack of closures into my head. Odin's lambdas are just function pointers that can't capture any values (although you can use the implicit context system to kind of simulate closures). This makes it hard to write general procedures for things. On day 5 of AoC I wanted to sort an array of numbers, by some ruleset I collected. Odin provides slice.sort-by to sort a slice using a compare-procedure, but that compare-procedure couldn't capture the ruleset I had. In the end I wrote the pointer to the ruleset into the context and got access to it that way, but this takes some getting used to and adds some unsightly code.
Some parts of the core-library take in callbacks and explicit contexts for this reason, but this convention isn't widespread.
Because of things like this, I've ended up implementing a lot of small every-day functions myself and in some instances multiple times for different days. This isn't a big deal for small programs like AoC and I'm sure some of those can actually be consolidated into a general form with more experience, but I don't know how sustainable this might be for larger programs. Maybe it'll be no problem, but I'll have to see.
The overview page on Odin's website is a great start and I definetly recommend to read through it.
But the documentation of the base/core/vendor libraries is very hit or miss. Sometimes it's great and tells you everything you need to know, other times it may have no documentation at all and you need to read the source (which usually works well, but that's not great). I'm sure this will improve with time and rising popularity of the language.