[fsloth]

We use C++ because of the C++ the ecosystem not because of the C++ the language.

There really is no other language that fits all of the constraints C++ fits. If there was, I'd be using it. And before you ask 'Have you looked into...' the answer is yes, unless the language is obscure, in which case it lacks the ecological robustness of C++.

[FiveDegrees]

I hope Jai ends up being made interoperable with C++.

[imron]

I just hope Jai end up being released.

jblow, I know you read HN, lots of us are looking forward to Jai.

[cr0sh]

Gotta say I'm looking forward to it too, even though I might not ever use it.

There are some things I disagree on with it, but most of those are orthogonal to the domain of which the language was meant to be applied, namely game programming. For that end, I can get behind those.

That said - the main things I don't like are the lack of exception handling, and no automatic memory management. I understand for game programming why these aren't going to be a part of the language. At the same time, I fear that without these, it may relegate the language to something of a niche language only used for game development and nothing else. While it is laudable to think that these features aren't needed, there is a reason they became available - and it mainly has to do with the fact that even "good programmers" aren't "perfect programmers"; we are all humans, not machines.

Features that make the language stand out, though, are the ideas of functions that run at compile time, which allow for a build system that is written in Jai and builds on compile (so you don't need to learn some other "language" just for building your world), the whole AOS/SOA mess that is made simple to implement with only one keyword (kinda neat!), plus the whole "uplift" of code from inner to global usage, with minimal changes, as it morphs from "lines of code" to "capture" to "anonymous function", etc - that's pretty powerful.

The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor. There's one part on this that I question - namely that variables are declared like:

name: type = value

...so:

foo: int = 0;

...but functions are defined as:

name := () -> return_type {}

ie:

bar := () -> float {}

I would have thought that a function would be defined as:

name: return_type = () {}

so:

baz: float = () {}

...thus more like the variable declarations (plus it would allow for turning a variable into a function easier, perhaps). There is probably something about compiler design, parsing, etc that I don't know that pre-empted things? That would be my first guess as to why this difference exists, but I would love to hear the actual reason from the author, if he reads this.

[imron]

> The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor.

Go, Rust, Swift, Ada, Pascal - languages both modern and old also use that inverted syntax and it's not such a burden to get used to.

> I don't like are the lack of exception handling

If done properly, it's possible to do without exceptions and have more robust and readable code - see for example Rust with its Error type and the try macro/? operator, which I've found I much prefer to exceptions.

[harrisi]

I'm not an expert at parsing, but one main issue I can imagine with having the same syntax for declaring functions and variables is that you need to look at six tokens to understand if it's a function declaration or a variable declaration. I say six because you have the name, colon, type, equal, parentheses (certainly you can't use this because then I couldn't declare a variable using parentheses, e.g., foo: int = (4 + 5) * 3;), and finally a pair of curly braces. And even then, I don't know Jai at all so it may be legal to use them in variable declarations.

With the name := () -> return_type {} syntax, you know whether it's a variable declaration or function declaration after two tokens: name (for either), then colon or colon-equal to differentiate the two.

[ndh2]

> no automatic memory management

Pretty sure Jai is already powerful enough that you could add this dynamically to any program.