(Introduction here)

In systems programming, C++ has ruled the roost since the late 90s. But for game developers who want tighter control, and modern workflow – and above all: faster compile times, it’s far from perfect.

This is where Jai steps in, a language created by Jonathan Blow — best known for his games Braid and The Witness (actually, Blow has never officially called the language ‘Jai’ - the name comes from the apparent name of the compiler executable in YT demos).

Blow set out to design Jai as a purpose-built alternative to C++, tailored specifically for the kind of high-performance code that games demand. His pitch? “We can do better” - modern features, more powerful meta programming and extensibility with lightning-fast compile times. Jai is meant to give total control of the machine with most of the latest contemporary language features.

Blow started work on Jai around 2014, and although the language isn’t publicly available yet, it’s already made waves — spawning what some call the “low-level programming renaissance”. Languages like Odin and Zig can trace parts of their DNA directly back to Jai’s early ideas.

Jai’s Influence: Zig, Odin, and the new wave

It’s hard to overstate how much Jai has quietly shaped the new generation of low-level languages. Ginger Bill, the creator of Odin, openly credits Jai, saying he borrowed “quite a lot of ideas”. Features like compile-time code execution, type introspection, and a deep focus on data-oriented design are hallmarks of all three languages — but Jai pioneered the model.

Similarly, Zig’s focus on manual memory management, tight control over the binary layout, and the now-famous comptime execution system feel very much like a sibling to Jai’s concepts. But it’s worth noting: Zig limits what can happen at compile time for safety reasons, while Jai — true to Blow’s style — hands you the big red button and lets you press it. One developer quipped that Zig’s compile-time features feel like “child’s play” compared to Jai’s open-ended system.

In Jai, not only can you run arbitrary code during compilation (including, famously from his first demo, running a game at compile time), but you can script and tweak your entire build process inside your codebase. No Makefiles or external build scripts needed. Compared to that, Zig’s comptime and build.zig feels cautious and overly nerfed.

What makes Jai stand out?

Jai isn’t trying to reinvent programming so much as streamline it. Many of its features feel like common sense — if you’re writing big, performance-sensitive codebases:

  • Blazing-Fast Compilation: Blow’s target is compiling a million lines of code in under a second.
  • First-Class Metaprogramming: Any function can be tagged to run at compile time. There is no special language and no separate macro files.
  • Manual Memory Control: This is perhaps obvious. However, Jai also has a “context” allowing programs to do scoped overrides of the default heap allocator. (Odin also has a “context” – clearly inspired by Jai, but it is not as heavily emphasized as in Jai)
  • Built-in Reflection: Jai can inspect its own types natively at runtime and compile-time.
  • Data-Oriented Defaults: Structures-of-Arrays layouts, polymorphic procedures, and easy slicing — all geared for cache-friendly, high-performance code.
  • Rich Syntax for Control: Operator overloading, defer, #asm blocks, and more — with an emphasis on “control first, magic later.”

On top of all that, Blow’s design philosophy shows through: he wanted a tool that feels like C, but sheds C’s worst baggage. No silent errors, no complex build chains, no mysterious behaviors you can’t debug.

What user like about Jai

Despite not being publicly available yet, Jai has built a dedicated fanbase and a solid set of beta testers. Here’s what people generally seem to love about it:

  • Speed: Both in compilation and execution. No more coffee breaks between builds.
  • Productivity Gains: Less boilerplate means fewer bugs and faster iteration. Blow estimates about a 15% productivity increase — and he expects that number to grow over time.
  • Powerful Compile-Time Tools: Jai’s ability to run arbitrary code at compile time blows traditional macros (and even Zig’s comptime) out of the water.
  • Clarity and Simplicity: Even complex systems programming feels straightforward compared to C++’s jungle of templates, inheritance, and fragile build systems.
  • Better Debugging: Debug symbols, no name mangling, and runtime checks make debugging far more pleasant.

As one early user put it, Jai feels “tremendously simpler than C++, and even simpler than C” — but without giving up the power that serious systems work demands.

The bad parts

Not everyone loves Jai. Common criticisms come up again and again:

  • Closed Development: Right now, Jai is not open-source. It’s invite-only, with no firm public release date. Many developers simply won’t invest time into a language they can’t use freely.
  • Growing Complexity: Even Blow has admitted that Jai is “more complex than he intended”. New features keep creeping in, and some fear it is getting harder to master.
  • Changing Features: Some ideas have been scrapped (like automatic structure layout flipping), and others are still experimental.
  • Thin Ecosystem: With no public release, there are no big libraries, no third-party tooling, and not many community-built resources yet.
  • Potential Security Risks: Jai’s wide-open compile-time execution could open the door to more side-effects or vulnerabilities if not used carefully.

Blow has acknowledged some of these trade-offs openly. On the matter of complexity, he notes it’s a constant balancing act: “You want the language to stay simple, but sometimes you need the complexity to get real gains.”

Jonathan Blow has a fairly divisive public persona, that seem to also polarize the community’s response to his language. Even so, one might note that very little criticism has been directed at the language’s semantics and syntax, which seems generally well received (as well as frequently copied).

The “Closed Source” Debate

One of the hottest topics around Jai is its closed status. Blow has been clear: Jai won’t be open-sourced until it’s truly ready. This approach allows his team to stay nimble and uncompromising, but it also alienates many developers who expect open-source access by default nowadays.

Some in the community understand Blow’s logic — one developer noted that keeping Jai closed lets it stay “as opinionated as it needs to be”. Others are less forgiving, calling it “disappointing” that such an exciting language isn’t available for contribution or even serious testing.

Either way, the closed nature of Jai is a real roadblock for wider adoption, so we can’t really see the true potential of the language yet.

What Happens When Jai Finally Drops?

It’s interesting to speculate: when Jai eventually releases publicly, what happens to languages like Zig and Odin?

Zig, which has spent years slowly gaining traction, might suddenly have serious competition. One user warned that Zig would need to “solidify” its user base fast, because Jai could “steal the momentum”. Jai’s more ambitious metaprogramming, faster compile speeds, and deeper focus on game development might appeal to the very developers Zig is currently winning over.

On the other hand, Zig and Odin aren’t standing still either. And it’s possible that Jai’s release — whenever it happens — will benefit the whole low-level ecosystem by bringing more attention (and pressure) to raise the bar for all C++ successors.

Summary

Jai is a very interesting competitor to C++ and has good chances to be embraced by at least the game programming community.

Even if it isn’t widely adopted after its release, it has already had a huge impact — igniting a trend of building low-level programming languages, and spawning the rapidly growing Zig and the well-regarded Odin.