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.