What Makes Odin Fun (Remastered)

Just about a year ago I made my first post here titled What Makes Odin Fun?. It was meant to be an exploration of what it was about Odin that compelled my interest, as I was being asked "why" by my twitter friendos a lot at the time. The post ended up being more of less a shallow overview of a few language features such as the context system, procedure groups, and so on. I was still very new to Odin at the time, so I didn't really even know why I was enjoying it but I made an effort. Fast forward to now and Odin has been my primary language for about a year. In that time my skillset and wisdom have both grown substantially (the bar was set pretty low), and Odin has seen a significant rise in popularity. In this post I'd like to reflect on my reasons for sticking with it.

I'm not going to tell you that it's the best language ever or that you should use it over any other. Rather, my hope is that if you're curious or on the fence about Odin, you'll find something here that encourages you to give it a fair shake and see if it suits you.

TLDR Vibe Check

The following is a list of concepts that I think many Odin devs would agree with:

• simple rather than complex wherever possible
• clear rather than clever
• explicit rather than implicit
• evolutionary, not revolutionary
• data is just data and should not have behavior

The most C-like of the C alternatives

Allow me to preface this section by pointing out that I am not an expert (or even intermediate) in C. I've done a bit of it for embedded projects on the ESP32, Pico, and the like but most of my experience is reading it rather than writing it.

Recent years have seen a surge in popularity of newer systems programming languages offering themselves as an alternative to C. Each has its own vision for what that means, and its own pros and cons. Personally I think there's a strong argument that Odin is the closest to the C way of doing things, while providing a much nicer language to use. Much like C, Odin won't provide you features like methods, closures, or algebraic data types, however what you get in return is a plethora of useful features such as (but not limited to):

• array programming and swizzles
• multiple return values (that are not just a tuple under the hood)
• precise control over memory layouts
• allocator support in the language itself
• scope-exit (rather than function-exit) defer statements
• explicit procedure overloading with proc groups
• parametric and subtype polymorphism
• tagged and untagged unions
• file suffix based conditional compilation (foo_windows.odin, foo_linux.odin, etc)
• a simple yet powerful build system (the compiler itself is the build system)
• many "vendor" libraries included as officially supported bindings (Raylib, SDL, OpenGL, Lua, stb, and more)
• best-in-class C interop

That last point is an important one. Porting or binding C to Odin is almost trivial in most cases, even for me. This repo contains a bite-sized example in the form of bindings for syslog.h and a few basic wrapper procs to make the API more idiomatic.

Consider the following from Odin's overview section:

Thus, when necessity calls for it, the entire literature and community of C is still (in effect) available to you in Odin as well. So, any time you are tempted to think “I can’t implement this in Odin yet because there’s not enough documentation” remind yourself that all (or almost all) of C is still available to you, but through a cleaner namespaced interface. Odin is also similar to C anyway, so direct translations of C to Odin (without even using the libc bindings) may still be relatively easy. In effect, any tutorial or book on C can also be thought of as an Odin resource too in that sense!

Roll, roll, roll your own

The larger programming world has developed an unhealthy addiction to "just pull in a library", with package managers making it trivial to do so. This is often done with little to no regard for the potentially massive chain of dependencies that can accumulate this way. I don't blame any single coder for doing this, as it is often recommended as a "best practice" and I've fallen prey to it myself many times.

But it's tech debt all the way down.

For an observable real world example, just look at the state of JS/TS/node/etc and npm. Or this post from Armin Ronacher on the problem as it pertains to Rust.

My aversion to the above combined with Odin's relatively small third-party library ecosystem means that it is tacitly encouraged, and often downright necessary, that I just write the functionality I need. When I was writing Rust, I often found myself browsing Crates.io just to see what was available that I could do cool stuff with. Now I generally don't even bother searching for a library.

• Need a raw mode terminal for a TUI? I wrote my own termios.h bindings to do it.
• Need to run another program from mine? I wrote a convenient wrapper to perform the POSIX fork-and-exec technique.
• Core doesn't include a way to handle zip files? I'm working on bindings for libzip.

This isn't some kind of brag. None of these things were difficult to write. That's the point.

And I own those packages. There's no magic and I have complete confidence to add to or modify them as I need.

That's not to say that third party packages are inherently bad, just that they should be used with care. When pulling in third party code is appropriate, the recommended method with regards to Odin is to vendor it into your project. Karl Zylinski, author of Understanding The Odin Programming Language, even encourages copying core packages into your project to modify them if you need to.

Community

I won't sugarcoat it (because they don't either): Odin devs and others who maintain a similar mindset tend to be blunt. Personally I prefer plain and direct communication, but I get that it rubs some people the wrong way. That said, my experience with the community has been a positive one where members seem genuinely eager to help each other and share knowledge and wisdom.

GingerBill, the creator of Odin, is very active on twitter and seems to have a supernatural knack for dropping in on streams where people are trying Odin for the first time.

Also of note is that an official forum was recently added to the Odin site. It's a great place to get help/advice, or showcase what you're working on.

On youtube I know of Rickard Andersson and Karl Zylinski. If you know of any other YT channels that feature Odin please do drop me a DM and let me know about them.

Jakub Tomšů has the awesome-odin repo.

Closing Thoughts

If you made it this far, thank you for reading and bearing with my rambling. As stated in the beginning, my goal here wasn't to sell you on Odin but rather to explore what it offers outside of just a feature list (the irony of saying that after including a feature list is not lost on me). My experience with it over the past year has been a good one and I look forward to writing a lot more Odin in 2025.