Four Years of Jai (2024)

Jai vs Other Systems Languages (Zig, Odin, C3, D, Rust)

• Some see Jai’s niche as “C-like for games” with much stronger metaprogramming, built-in build scripts, context pointers and arena-style allocators.
• Others argue Odin, C3, Zig and D already fill that space:
  • Odin and C3: simpler, open, IDE‑friendly, good C interop.
  • Zig: first‑mover, but perceived as verbose, strict, with “friction and ceremony”, especially for game dev.
• Several think Zig is uniquely vulnerable if Jai actually ships: Jai is framed as “Zig but with many more features”.
• A few doubt the article’s C++ performance comparisons and are unconvinced that Jai’s metaprogramming story (as described) is clearer than C++ templates.

Closed Source, “Beta”, and Open Source Philosophy

• Many are reluctant to invest in a closed language in 2024; they want source eventually, or they’ll stick with open tools.
• There’s secondhand talk that Jai will be released, then later open‑sourced, but no firm public timeline.
• Long subthread on “open source vs source‑available vs open-contribution”:
  • One side: you can open the code and still ignore PRs; open source is a licensing concept.
  • Other side: visibility and expectations create real social overhead; avoiding that is a valid reason to stay closed.
• Some argue closedness signals “not ready for adoption” and protects from early ecosystem lock‑in and breaking changes; others call that unnecessary and say many languages managed early open development.

Perpetual Closed Beta & “Cult of Personality” Concerns

• Several feel teased: lots of talks and streams, but no public compiler, so accumulated interest decays.
• Comparisons to Star Citizen, Mojo, Urbit, V‑lang, Elm: inner circles, “true believers”, and drama around a charismatic central figure.
• Defenders say the team is primarily making a game and engine, using Jai as an internal tool; releasing early would add distraction without benefit.
• Some explicitly say they now ignore the project until there’s a real release.

Memory Management: GC, Rust, RAII, defer

• One pole: GC is the compiler taking on complexity; performance issues are often overstated except for hard real‑time/embedded.
• Counterpoint: GC pause time, memory overhead and power use matter on phones, TVs, HFT, and tight‑latency games; “pauseless” GC claims are contested.
• Long Rust section:
  • Borrow checker praised by some as mostly invisible once learned; others describe common friction (partial borrows, big state structs, non‑lexical lifetimes gaps).
  • Clarification that Rust’s rules are stricter than “all memory-safe programs”, trading flexibility for static guarantees.
• Jai/Go‑style defer + arenas:
  • Fans say this covers most use cases with explicit, simple code and avoids fighting a borrow checker.
  • Critics stress it doesn’t provide memory safety; use‑after‑free is easy if lifetimes outlive scopes or cross threads/containers.
  • Several strongly argue defer is not a replacement for RAII/move semantics, especially for resources stored in vectors, passed across threads, or through channels.

Software Performance and “Dark Age” Narrative

• Many agree with the article’s complaint that modern software wastes hardware gains: slow IDEs, debuggers, GUIs, and terminals even on high‑end machines.
• Others push back: today’s systems do far more (crypto everywhere, isolation, huge media, distributed systems). Comparing to 1990s desktops is seen as misleading.
• Debate whether the “we’re in a dark age of slow, sloppy software” framing is insightful or catastrophizing.

Tone and Author Persona

• Some readers found the article smug and dismissive of safety‑oriented languages and their users.
• Others thought it was just “opinionated”, not hostile.
• The broader thread repeatedly circles back to the language designer’s public persona: viewed by some as elitist/gatekeeping, by others as courageously blunt and technically sharp.