In terms of actual features though (ignoring trivial syntax), Odin resembles more of Jai. In fact, when I first found about it a few years earlier I though it was an open source clone of Jai.
Today many features have diverged since then, and Odin is ahead by many aspects (mainly that the compiler is open source, but also that it’s already being used in production via EmberGen). I still really want the full metaprogramming capabilities that Jai has though (which is lacking in Odin currently).
gingerBill (the creator/designer of Odin) has been quite clear that Odin is done (in terms of language features) and that he does not intend to ever include support for "macros" or other advanced metaprogramming features.
I see it more as Odin has a very strong Go-like foundation, and then borrowed heavily from Jai too, in terms of syntax and various features. So that superficially, it looks like Jai. To the point, people could think it was a clone or fork.
Also, Jai is a lot more Go-like than many people realize. When Jai diverges from various C/C++ concepts and traditions, it can do so in Go-like ways.
> ...Odin is ahead by many aspects (mainly that the compiler is open source, but also that it’s already being used in production...
Totally agree with you here. It could be argued that Jai has fumbled its advantage or at least the window of opportunity to claim its more innovative or more game program friendly than other languages. Odin has pretty much covered that gap, so that most of what people liked about Jai, is in Odin and can be used today.
Well, such things can be subjective. Yes, Odin does not do concurrency and channels. This appears to be because Odin doesn't do automatic memory management, and has more limits on the language, in terms of focus. It can be argued that Odin adapted itself to being a strong Jai alternative and appealing to gaming, versus more general purpose.
My understanding is that Odin does not plan to ever attempt to put concurrency nor channels into the language. It looks like that some type of workaround, if it ever happens, will have to be implemented by a 3rd party library.
It should be added, Vlang (the other Go alternative mentioned) because it was designed for various memory management options (both automatic and manual), does do concurrency and channels (https://github.com/vlang/v/blob/master/doc/docs.md#concurren...). Vlang aims to be more general purpose versus more specific.
We are planning on adding channels to the core library but we have not added them yet since there are quite a few different forms (SPSC, SPMC, MPSC, MPMC).
One thing that I would like to bring up is that Odin differs from Go in that it does not have `go`routines (green threads). These require automatic memory management and a huge runtime to make them possible. And you cannot easily add them after the fact to a language either without huge issues. Channels are very basic things but the thing that makes Go's concurrency powerful are the `go`routines, not the channels.
Today many features have diverged since then, and Odin is ahead by many aspects (mainly that the compiler is open source, but also that it’s already being used in production via EmberGen). I still really want the full metaprogramming capabilities that Jai has though (which is lacking in Odin currently).