By far the best feature (IMO) is that it has no trouble talking to the most important Windows COM libraries (like DirectX) and the Objective-C runtime (for Metal), and this comes as "batteries included", not some random third party library you have to download.
So for any sort of visual engine development (game engines being the most obvious, but also applications like blender or the JangaFx suite which is the main user of Odin), it is great. What you need is just there ready to go.
The language design itself is very much oriented around appealing to people who do this sort of work.
Other than there isn't much to the language really. It lacks a "big idea" feature like Rust's lifetimes or Zig's comptime. The closest thing to a "big idea" is the rejection of package managers but that's not really part of the language.
It's pleasant to use and compiles fast. Hard to complain.
Go really only took off thanks to Docker and Kubernetes, and even if it would be capable, there is hardly an ecosystem there.
Rust could be there, but there is really only Bevy, and several companies have tried it and pivoted to something else due to compile times hindering fast prototyping workflows.
Odin was created at a games company, JangaFX, and has already a few products using it.
At the level of this question, with most responses addressing Odin versus Rust or Go as in the question, I'd have been curious for community thoughts adding in Nim and Swift (now that Swift is on Linux and in any IDE that can use SourceKit-LSP).
Interactive applications where a GC is not an option.
Rust is shockingly good at being a general purpose language, but that's in the face of the strict semantics of the language and approach to memory. There became a comparison against Go because Go offers strong performance and a complete opposite memory-management experience (in having a GC that largely solves it for you.) Odin sits between these two levels of friction, leaning far more on the Go side of things. There are goodies in Odin which make memory management much breezier than other manual languages, but I'll admit it is still a task you are expected to complete.
So that's the story on the memory-management effort. That aside, I'd say Odin is best for interactive applications where a GC is not an option. Although at this point it comes out of my hands so easily that I'd probably write Odin in some situations where it'd be less optimal, and it'd be fun so why not?
Game engine programming, more generally projects where the programmer controls the spec and data. More specifically, passing custom allocators to specific subsystems.
That may sound like "Q:why buy this truck? A:Cos it has a nice oil filter" but it marketed as a language "[for the] joy of programming".
Perhaps the goal is to get more people into programming following the same playbook as the scripting wars we had in the 2000s. Or it's part of a larger trend to get mind-share away from c.
I've been using and loving Odin for probably around 5 years now, with this past couple years being more seriously invested in it. After tens of thousands of lines of code I'm still very happy. If you like C, but feel it's missing a few things, I highly recommend giving Odin a shot. Among the new litter of "better C" languages, Odin is easily the lowest-friction. It makes for a very nice experience. Congratulations, gingerBill.
Agreed completely. It’s my favorite language in its class. I need to build something serious in it someday. So far, I’ve only used it for building personal tools.
Clickbait video title, the first major release is going to be 2027 (date based versioning) (j/k).
Odin is a pretty neat language, I should play more with it. There's nothing outright wrong with it I can think of. Some things I would have done slightly different but they're all nitpicks (mainly having the context be a thread local so #contextless wouldn't be necessary).
Another common question I’ve gotten a few times is why the `context` is passed as an implicit pointer argument to a procedure, and not something like a thread local variable stack? The rationale being that there would not need to be a calling convention difference for `context`. Unfortunately through a lot of experimentation and thought, there are a few reasons why it is implemented the way it is:
* Easier to manage across LIB/DLL boundaries than trying to use a single thread-local stack
* Easier management of recovery from crashes where the context might be hard to figure out.
* Using the existing stack makes stack management easier already, you don’t need to have a separate allocator for that stack
* Some platforms do not thread-local variables (e.g. freestanding targets)
* Works better with async/fiber based things, which would then require a fiber-local stack instead of a thread-local one
* Prevent back-propagation, which would be trivial with a global/thread-local stack
Odin’s context also has copy-on-write semantics. This is done for two reasons: to keep things local, and prevent back-propagation of “bad” data from an third-party library (be it malicious or just buggy). So not having an easily accessible stack of context values makes it harder for this back-propagation to happen.
There's something seriously off about this ginger bill guy. In addition to copying most of Odin from Jai, Bill copied Jon Blows announcement to his announcement as well as the fake surprised "oh I didn't see you there" opening for the real announcement. He's also planning to release the language the exact same time as Jai, and even said "after ten years of hard work its finally here."
Any one of those things you could ignore, but all of them together and its starting to be weird.
There is also a strong argument about whether or not Odin can survive the public release of Jai. Which is rumored to be this year, but who knows if that will prove true.
Debatably, Odin's limited success, is due to Jai not being available to more of the public.
I think plenty of people will still use Odin, primarily because there's a lot more batteries included, but everything about this announcement makes me think Bill is worried about the competition, and trying to showcase his 1.0 with all his batteries...while releasing around the same time as jai. Kinda weird behavior imo.
Odin is different enough from those languages, where coexistence and what is offered should not be so much of a problem. Unless, out of sheer competitive or corporate spitefulness against others (the less, the better thinking) and for higher rankings, they feel compelled to reduce user choice.
Jai, on the other hand, arguably appeals to the same groups and circles as those that are or might be attracted to Odin. That even appears to go for their creators, where similar demographics of fans would likely choose Jonathan Blow.
What would you say is similar between Odin and Jai? I briefly used Jai (I have never had access) and found that essentially only declaration syntax is familiar.
The entire concept of Odin seems to be taken from Jai. They're both aiming to be C/C++ replacements "for the joy of programming" (another thing that was in the early Jai videos that Bill ripped off). In addition to the syntax (which is eerily similar across the entire language), there is the "using" keyword, the "defer" keyword, the context system, custom allocators, native AoS, polymorphic procedures, etc.
Again, any one of those things on it's own is not a smoking gun, and many of these features and syntax are becoming standard in modern languages. But the fact that SO MANY of Odin's features and even it's marketing strategy seems to be copying Jon Blow is weird to me. You can still go watch Jon's videos demoing early Jai from 11 years ago...and if you check the comments you'll see a familiar ginger face, so there's no doubt Bill saw those videos when they came out, and began developing Odin AFTER he saw Jai.
If he was simply inspired by Jon that's fine, there's nothing wrong with more well-thought out programming languages in the world. But when you copy a lot of the language, copy the announcement to the announcement video, copy the announcement video, and also plan to release at the exact same time as Jai, while largely denying that Jai had any influence of your language, red flags will go off for anyone that's paying attention.
I think both Bill and Jon have discussed this at length and are both mutually respectful of what problems each are trying to solve, could be wrong. At the least, I think it's disingenuous to suggest that Odin is "mostly copied" from Jai just because they have a few similarities and share inspirations.
See [1] where Bill discusses the influences and where they've diverged longer-form.
Bad video, I noped out after 2 mins, it is annoying and has a very low information density. Anyone uses a yt video -> information service that is fast, free, reliable etc?
I kind of like Odin, with its Pascal/Modula-2 influences, even if the community is a bit hardcore on some of their ideas.
Love the books in the background, and the whole video.
It is also nice that Odin takes the batteries included approach.
How well it would fair in the mainstream remains to be seen.
What kinds of project would Odin be best suited for, as compared to, say, Rust or Go?
By far the best feature (IMO) is that it has no trouble talking to the most important Windows COM libraries (like DirectX) and the Objective-C runtime (for Metal), and this comes as "batteries included", not some random third party library you have to download.
So for any sort of visual engine development (game engines being the most obvious, but also applications like blender or the JangaFx suite which is the main user of Odin), it is great. What you need is just there ready to go.
The language design itself is very much oriented around appealing to people who do this sort of work.
Other than there isn't much to the language really. It lacks a "big idea" feature like Rust's lifetimes or Zig's comptime. The closest thing to a "big idea" is the rejection of package managers but that's not really part of the language.
It's pleasant to use and compiles fast. Hard to complain.
Game development.
Go really only took off thanks to Docker and Kubernetes, and even if it would be capable, there is hardly an ecosystem there.
Rust could be there, but there is really only Bevy, and several companies have tried it and pivoted to something else due to compile times hindering fast prototyping workflows.
Odin was created at a games company, JangaFX, and has already a few products using it.
https://jangafx.com
Also Odin batteries include what you need to start coding a game right away, https://pkg.odin-lang.org/vendor
At the level of this question, with most responses addressing Odin versus Rust or Go as in the question, I'd have been curious for community thoughts adding in Nim and Swift (now that Swift is on Linux and in any IDE that can use SourceKit-LSP).
https://www.swift.org/install/linux/
See:
"A series of small programs/tasks to compare C++, Go, Zig, Odin, D, Janet, Swift, Nim and C# to see which I like the most"
https://github.com/phillvancejr/Cpp-Go-Zig-Odin
Interactive applications where a GC is not an option.
Rust is shockingly good at being a general purpose language, but that's in the face of the strict semantics of the language and approach to memory. There became a comparison against Go because Go offers strong performance and a complete opposite memory-management experience (in having a GC that largely solves it for you.) Odin sits between these two levels of friction, leaning far more on the Go side of things. There are goodies in Odin which make memory management much breezier than other manual languages, but I'll admit it is still a task you are expected to complete.
So that's the story on the memory-management effort. That aside, I'd say Odin is best for interactive applications where a GC is not an option. Although at this point it comes out of my hands so easily that I'd probably write Odin in some situations where it'd be less optimal, and it'd be fun so why not?
Game engine programming, more generally projects where the programmer controls the spec and data. More specifically, passing custom allocators to specific subsystems.
That may sound like "Q:why buy this truck? A:Cos it has a nice oil filter" but it marketed as a language "[for the] joy of programming".
Perhaps the goal is to get more people into programming following the same playbook as the scripting wars we had in the 2000s. Or it's part of a larger trend to get mind-share away from c.
Odin is not the only language with Pascal influences, as that applies to Golang and Vlang too.
Sure, but at least Odin embraces more stuff than Go, with its design mindset.
It has naturally the influences that came via Oberon-2.
I've been using and loving Odin for probably around 5 years now, with this past couple years being more seriously invested in it. After tens of thousands of lines of code I'm still very happy. If you like C, but feel it's missing a few things, I highly recommend giving Odin a shot. Among the new litter of "better C" languages, Odin is easily the lowest-friction. It makes for a very nice experience. Congratulations, gingerBill.
Agreed completely. It’s my favorite language in its class. I need to build something serious in it someday. So far, I’ve only used it for building personal tools.
Clickbait video title, the first major release is going to be 2027 (date based versioning) (j/k).
Odin is a pretty neat language, I should play more with it. There's nothing outright wrong with it I can think of. Some things I would have done slightly different but they're all nitpicks (mainly having the context be a thread local so #contextless wouldn't be necessary).
Regarding the implementation of Odin's `context` not being thread-local, source from here: https://www.gingerbill.org/article/2025/12/15/odins-most-mis...
Another common question I’ve gotten a few times is why the `context` is passed as an implicit pointer argument to a procedure, and not something like a thread local variable stack? The rationale being that there would not need to be a calling convention difference for `context`. Unfortunately through a lot of experimentation and thought, there are a few reasons why it is implemented the way it is:
* Easier to manage across LIB/DLL boundaries than trying to use a single thread-local stack
* Easier management of recovery from crashes where the context might be hard to figure out.
* Using the existing stack makes stack management easier already, you don’t need to have a separate allocator for that stack
* Some platforms do not thread-local variables (e.g. freestanding targets)
* Works better with async/fiber based things, which would then require a fiber-local stack instead of a thread-local one
* Prevent back-propagation, which would be trivial with a global/thread-local stack
Odin’s context also has copy-on-write semantics. This is done for two reasons: to keep things local, and prevent back-propagation of “bad” data from an third-party library (be it malicious or just buggy). So not having an easily accessible stack of context values makes it harder for this back-propagation to happen.
Yeah, all valid justifications.
a random video that some ginger dude put up on youtube doesn't seem like a reliable source. any info on this from a reputable institution?
shame that HN can't meet the moderation quality bar set by wikipedia
Honest question: Are you making a joke? Because while it objectively could be one, it doesn't sound like one.
The random ginger dude is the creator of Odin.
It's probably a joke, because Odin was deleted from Wikipedia for being "not notable" recently, and the author thought it was because of his politics.
I do think the guy's politics suck, but I also think his language's wiki page was probably targeted for it.
Ah, that changes thing. That actually makes the joke better.
yeah, it was a joke referencing this link that was on the front page a couple days ago,
https://katamari64.se/posts/2026/odin-wikipedia/
a little over the etiquette line for HN, the lack of joke comments here is awesome and i shouldn't be part of lowering our collective brows
Not to be confused with Samsung Odin[1], or ODIN (Open Disk Imager in a Nutshell)[2], or Odin for OS/2 Warp[3]...
[1] https://en.wikipedia.org/wiki/Odin_(firmware_flashing_softwa...
[2] https://odin-win.sourceforge.net/
[3] https://odin.netlabs.org/
Oh go away.
There's something seriously off about this ginger bill guy. In addition to copying most of Odin from Jai, Bill copied Jon Blows announcement to his announcement as well as the fake surprised "oh I didn't see you there" opening for the real announcement. He's also planning to release the language the exact same time as Jai, and even said "after ten years of hard work its finally here."
Any one of those things you could ignore, but all of them together and its starting to be weird.
There is also a strong argument about whether or not Odin can survive the public release of Jai. Which is rumored to be this year, but who knows if that will prove true.
Debatably, Odin's limited success, is due to Jai not being available to more of the public.
I think plenty of people will still use Odin, primarily because there's a lot more batteries included, but everything about this announcement makes me think Bill is worried about the competition, and trying to showcase his 1.0 with all his batteries...while releasing around the same time as jai. Kinda weird behavior imo.
What is the strong argument exactly? Odin coexists happily with Zig, Rust, C3, nim already, no?
Odin is different enough from those languages, where coexistence and what is offered should not be so much of a problem. Unless, out of sheer competitive or corporate spitefulness against others (the less, the better thinking) and for higher rankings, they feel compelled to reduce user choice.
Jai, on the other hand, arguably appeals to the same groups and circles as those that are or might be attracted to Odin. That even appears to go for their creators, where similar demographics of fans would likely choose Jonathan Blow.
What would you say is similar between Odin and Jai? I briefly used Jai (I have never had access) and found that essentially only declaration syntax is familiar.
The entire concept of Odin seems to be taken from Jai. They're both aiming to be C/C++ replacements "for the joy of programming" (another thing that was in the early Jai videos that Bill ripped off). In addition to the syntax (which is eerily similar across the entire language), there is the "using" keyword, the "defer" keyword, the context system, custom allocators, native AoS, polymorphic procedures, etc.
Again, any one of those things on it's own is not a smoking gun, and many of these features and syntax are becoming standard in modern languages. But the fact that SO MANY of Odin's features and even it's marketing strategy seems to be copying Jon Blow is weird to me. You can still go watch Jon's videos demoing early Jai from 11 years ago...and if you check the comments you'll see a familiar ginger face, so there's no doubt Bill saw those videos when they came out, and began developing Odin AFTER he saw Jai.
If he was simply inspired by Jon that's fine, there's nothing wrong with more well-thought out programming languages in the world. But when you copy a lot of the language, copy the announcement to the announcement video, copy the announcement video, and also plan to release at the exact same time as Jai, while largely denying that Jai had any influence of your language, red flags will go off for anyone that's paying attention.
I think both Bill and Jon have discussed this at length and are both mutually respectful of what problems each are trying to solve, could be wrong. At the least, I think it's disingenuous to suggest that Odin is "mostly copied" from Jai just because they have a few similarities and share inspirations.
See [1] where Bill discusses the influences and where they've diverged longer-form.
[1]: https://github.com/odin-lang/Odin/wiki/Odin-vs-Jai
Bad video, I noped out after 2 mins, it is annoying and has a very low information density. Anyone uses a yt video -> information service that is fast, free, reliable etc?
Free tier of Google Gemini can summarize and let you ask questions about pasted YT links.