Porting 58k lines of D and C++ to Jai

> In my eyes, the most important ones are faster compilation and allowing metaprogramming via unrestricted compile time execution.

I'm fascinated by languages that are adding more compile-time programming features, in the context of a low-level performance-oriented use case. Would love to know more about the history and state of the art of this area.

> I don't understand why they are not working in the open, this is a tool, not a game, input for a large community is extremely valuable.

Ayup. Talking about JAI is simply a waste of time until they put it in the open under a genuine open-source license.

Otherwise, you wind up with situations like "Our Machinery".

Putting together the available document "JayPrimer" (which may be obsolete) with the blog post, Jay it seems a language designed by somebody who's was fed up with C++, and deciced to write their own, tailored language; this looks great when seen through the lens of C++, but there isn't anything particularly innovative in the context of modern languages.

In particular, I'm personally neutral to Zig, but there seems to be little reason to prefer Jay over it.

From the primer:

> Arbitrary Compile-Time Code Execution

This is the big selling point, but, brought to the extreme, it's not necessarily a good thing. The examples in the primer are intended to look great:

- Insert build time data

- Download the OpenGL spec and build the most recent gl.h header file

- Contact a build server and retrieve/send build data

but they're the type of things that turn a build into a monster.

I guess comptime execution is big in the gamedev area (I can't say, I have little experience), but I suppose Zig fits the typical gamedev use cases (curious to hear devs with hands-on experience).

> Code Refactoring

The example presented seems to be "extract to function", which sufficiently advanced IDEs should support. It's also unclear if it's currently implemented.

> Integrated Build Process

I don't see this as a good thing. It's good from the perspective of old programming languages, whose build tools are a mess. But having a separate tool is actually an advantage, as long as it's standardized and well integrated (I suppose modern languages have this support).

> SOA AND AOS

This seems to be a very niche feature.

> Reflection and Run-Time Type Information

This is very convenient, but again, nothing unique.

> FUNCTION POLYMORPHISM

It seems to be an odd (flexible/inferred) generics implementation. One of the language objectives is to never perform automated type casting, but in this example, it is performed.

> THE ANY TYPE

I guess this is a polarizing feature.

> STRUCT POINTER OWNERSHIP

Is this syntactic sugar for a C++ destructor?

> Other Cool Stuff

> Specific data types for 8, 16, and 32 bit integers

No 64/128? :^)

Regarding the post, the non-trivial selling points are described as:

> Reducing compile times from about 60s right now to under 5s, hopefully around 1s

This is certainly very appealing.

> having debuggers work

Uh? That's based on the bad D experience.

> Replacing build-scripts with jai code

> Catching more errors by introducing custom compilation checks using metaprogramming

> Replacing complex metaprogramming code with simpler, imperative code

See Zig.

The rest are trivialities.

I heard about this "promising" language as a youngster and never heard of it again, it doesn't seem to have taken off after all these years, and probably it's too later for it ever take off.

Yeah, I guess that’s true as far as Blow goes. But there are other people interested in this thing (hence why the OP exists and why we’re commenting on it). And I presume not all of them want to lock themselves in to the apparent dead end that is the x86 platform in the current year when both cross-platform languages and cross-platform game engines are all over the place.