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.
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.
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.
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?
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
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.
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.
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.
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?