Maybe when it comes to learning compiler construction. But otherwise, what's the point of all this effort if the result is hardly different from anything existing? Some innovation or other special feature justifying all the effort to implement the language and toolchain and for the interested parties to adopt it should at least be present. I would still be interested to know where this can be found on Jay. Any hints?
In the end it comes down to healthy competition, it doesn't matter much why one thing is better than another, it just has to be preferred by enough people. And all those people may have different opinions on why they would choose one language over another. Traditionally, there has been a real lack of "better C" languages. Now since a few years we suddenly have a number of promising options but still not enough: Odin, Zig, Jai, and a few lesser known like C2 and C3, that's about it - I count Rust and D as attempts to a "better C++", not a "better C" (I'm aware of D's "das better C" subset though).
Apparently Jai is specifically tailored to game development problems and frustration with C++ for game dev (or at least it tries to fix rough edges that a typical game developer encounters in existing languages used for game dev) - whether that is actually true I can't tell though since I haven't used Jai yet.
> Now since a few years we suddenly have a number of promising options but still not enough
Well, but how do you recognize that there are still not enough options? I assume it should be a bit more specific than just a feeling or "personal preference", isn't it?
> Rust and D as attempts to a "better C++"
Rust has at least one big unique selling point which was not present so far in any other language (at least I'm not aware of any one): compile time automatic memory management. The unique selling point of D in contrast is not that obvious, at least not to me.
> whether that is actually true I can't tell though since I haven't used Jai yet.
> how do you recognize that there are still not enough options
One language that's still missing is a simple C-like language that offers Rust-style memory safety but without Rust's design philosophy of repeating every C++ mistake (that's not about memory safety) and high level type system wankery (or generally too much influence from functional languages).
There are also many more areas still to explore when it comes to memory safety that are less extreme than Rust's approach (I completely forgot about Vale which tries out some really interesting things in that direction: https://vale.dev/)
It would most likely need to 'break' C in a way that it wouldn't be recognisable as C anymore or at least break compatibility with existing C code (e.g. removing pointers, or at least pointer arithmetics, and the way pointers and arrays interact).
Not necessarily; the compiler has to trace ownership anyway and could also detect "legal" use of pointers and reject certain uses for objects under the "borrow checker regime", as Rust does it. But of course one could take a subset of C and augment it with the new features, as it was e.g. done in C++ in the eighties or Simula (with Algol) in the sixties; the obvious advantage is the similarity to the original language and (potential) reusability of a large existing code base.
> Traditionally, there has been a real lack of "better C" languages.
There never has been. There has been a lack of really successfull C alternatives for some time (after everything that wasn't unixish or Windows died, except for MacOS and Objective-C) - and still is. Rust is still less used than Pascal has been 30 years ago.
No language is perfect. There is nothing wrong with making your own that works the way you want a language to work. I don't get people who complain about new languages. Variety is good. Let people have fun.
I think it's not up to us, the peanut gallery, to judge what any particular developer spends their time on. It's worthwhile to Blow, and he is very vocal that he is developing the language for his own use, not for anyone else. If you keep that in mind, maybe some of the choices around how it's being developed will make more sense.
I'm a language implementor myself and just asked for a clear unique selling point of Jai, and guess what, there was indeed one fellow here who didn't question the question, but has personal experience and was able to give me the information I was interested in (see https://news.ycombinator.com/item?id=37369342), without me having to read or listen through dozens of outdated blog posts and presentations. I still think a language specification would be worthwhile, even during early development.
From what I understood from Blow, a specification at this point would only serve to have other people bike shed about syntax, features, etc.
Looking at the explanation you linked, I would say that the author uses the language in a very unidiomatic way (if idiomatic Jai would be a thing :D). It takes a very template focused mindset and uses the features of the language to bastardize and complicate things needlessly (IMHO, as a not game developer). I think my main take away from the language is that it focuses on the way memory is mapped (similarly to how C does it) and less on behaviour associated with that memory.
So for that example, instead of trying to overthink a container that uses a generic behaviour through templated types, it would implement different overloaded functions for each type as needed.
> a specification at this point would only serve to have other people bike shed about syntax, features, etc.
It makes little sense to announce a language with a lot of details over so many years without providing a decent specification. Either the author is interested in feedback, then a specification or language report is the established vehicle among language designers, or he is not interested in feedback, which raises the question why he publishes any details at all.
> It takes a very template focused mindset and uses the features of the language
But as it seems that's a focus point of the language; why otherwise the author would take the effort to even modify structure declarations with compile time expressions.
> that it focuses on the way memory is mapped (similarly to how C does it)
What do you mean by that? And is this really a unique selling point if it is similar to C?
I offered a very bird's eye view of what a newbie understood from the language, not a "unique selling point" because, like I keep failing to make you see, Blow is not trying to "sell it" to anyone.
