Four Years of Jai (2024)

Iirc, pretty sure jblow has said he's open sourcing it. I think the rough timeline is: release game within the year, then the language (closed-source), then open source it.

Tbh, I think a lot of open source projects should consider following a similar strategy --- as soon as something's open sourced, you're now dealing with a lot of community management work which is onerous.

Apparently not only do the 90's approach still work pretty well when the language comes with a piece of green coloured hardware, all the ongoing returns to 90's licensing models prove that the free beer approach isn't working when the goal is to build a sustainable business of out the technology.

Some comparison with D:

> Do I have access to an asm keyword,

Yes, D has a builtin assembler

> or can I easily link assembly files?

Yes

> Do I have access to the linker phase to customize the layout of the ELF file?

D uses standard linkers.

> Does it need a runtime to work?

With the -betterC switch, it only relies on the C runtime

> Can I disable the standard library?

You don't need the C runtime if you don't call any of the functions in it.

There is this streamer that does a lot of interesting language exploring on his own. I don't say you will find all the answers to your questions, but I think you will get a good sense of what you can or cannot do in jai : https://www.youtube.com/results?search_query=Tsoding+jai

> The hardware I have sitting on my desk is vastly more powerful that what I was rocking 10-20 years ago, but the user experience seems about the same.

Not even.

It used to be that when you clicked a button, things happened immediately, instead of a few seconds later as everything freezes up. Text could be entered into fields without inputs getting dropped or playing catch-up. A mysterious unkillable service wouldn't randomly decide to peg your core several times a day. This was all the case even as late as Windows 7.

> Also a 19,000 line C++ program(this is tiny) does not take 45 minutes unless something is seriously broken

Agreed, 45 minutes is insane. In my experience, and this does depend on a lot of variables, 1 million lines of C++ ends up taking about 20 minutes. If we assume this scales linearly (I don't think it does, but let's imagine), 19k lines should take about 20 seconds. Maybe a little more with overhead, or a little less because of less burden on the linker.

There's a lot of assumptions in that back-of-the-envelope math, but if they're in the right ballpark it does mean that Jai has an order of magnitude faster builds.

I'm sure the big win is having a legit module system instead of plaintext header #include

I seriously doubt that any of them have trouble understanding a concept as simple as RAII.

There is no RAII in his language. Why would you care if he understands it or not?

The reality of a project like this is that to get it right (which is by the creator's standards, no one else's) takes time. Add on top of that Blow and Thekla are building games with this to dogfood it which takes time, too.

Sadly, there exists a breed of developer that is manipulative, obnoxious, and loves to waste time/denigrate someone building something. Relatively few people are genuinely interested (like the OP) in helping to develop the thing, test builds, etc. Most just want to make contributions for their Github profile (assuming OSS) or exercise their internal demons by projecting their insecurities onto someone else.

From all of the JB content I've seen/read, this is a rough approximation of his position. It's far less stressful to just work on the idea in relative isolation until it's ready (by whatever standard) than to deal with the random chaos of letting anyone and everyone in.

This [1] is worth listening to (suspending cynicism) to get at the "why" (my editorialization, not JB).

Personally, I wish more people working on stuff were like this. It makes me far more likely to adopt it when it is ready because I can trust that the appropriate time was put in to building it.

[1] https://www.youtube.com/watch?v=ZY0ZmeYmyjU

One thing I want to add to the other (so far) good responses: They also seem to build Jai for a means to an end, which is: they are actively developing a game engine with it (to be used for more than one project) and a game, which is already in advanced stages.

If you consider a small team working on this, developing the language seriously, earnestly, but as a means to an end on the side, I can totally see why they think it may be the best approach to develop the language fully internally. It's an iterative develop-as-you-go approach, you're writing a highly specific opinionated tool for your niche.

So maybe it's best to simply wait until engine + game are done, and they can (depending on the game's success) really devote focus and time on polishing language and compiler up, stabilizing a version 1.0 if you will, and "package" it in an appropriate manner.

Plus: they don't seem to be in the "promote a language for the language's sake" game; it doesn't seem to be about finding the perfect release date, with shiny mascot + discord server + full fledged stdlib + full documentation from day one, to then "hire" redditors and youtubers to spread the word and have an armada of newbie programmers use it to write games... they seem to much rather see it as creating a professional tool aimed at professional programmers, particularly in the domain of high performance compiled languages, particularly for games. People they are targeting will evaluate the language thoroughly when it's out, whether that's in 2019, 2025 or 2028. And whether they are top 10 in some popularity contest or not, I just don't think they're playing by such metrics. The right people will check it out once it's out, I'm sure. And whether such a language will be used or not, will probably, hopefully even, not depend on finding the most hyped point in time to release it.

It's a common thing in programming language design and circles where some people like to form little cults of personality around their project. Curtis Yarvin did that with his Urbit project. V-Lang is another good example. I consider Elm an example as well.

They get a few "true believer" followers, give them special privileges like beta access (this case), special arcane knowledge (see Urbit), or even special standing within the community (also Urbit, although many other languages where the true believers are given authority over community spaces like discord/mailing list/irc etc.).

I don't associate in these spaces because I find the people especially toxic. Usually they are high drama because the focus isn't around technical matters but instead around the cult leader and the drama that surrounds him, defending/attacking his decisions, rationalizing his whims, and toeing the line.

Like this thread, where a large proportion is discussion about Blow as a personality rather than the technical merit of his work. He wants it that way, not so say that his work doesn't have technical merit, but that he'd rather we be talking about him.

The faster computers get, the more the GC problem is way overblown apart from super-low-latency niches. Even AAA games these days happily run on GC languages.

There is a prominent contributor to HN whose profile says they dream of a world where all languages offer automatic memory management and I think about that a lot, as a low-level backend engineer. Unless I find myself writing an HFT bot or a kernel, I have zero need to care about memory allocation, cycles, and who owns what.

Productivity >> worrying about memory.

Well, 1) the temporary allocator strategy; and 2) `defer` kinda go against the spirit of this observation.

With (1) you get the benefits of GC with, in many cases, a single line of code. This handles a lot of use cases. Of those it doesn't, `defer` is that "other single line".

I think the issue being raised is the "convenience payoff for the syntax/semantics burden". The payoff for temp-alloc and defer is enormous: you make the memory management explicit so you can easily see-and-reason-about the code; and it's a trivial amount of code.

There feels something deeply wrong with RAII-style langauges.. you're having the burden to reason about implicit behaviour, all the while this behaviour saves you nothing. It's the worst of both worlds: hiddenness and burdensomeness.

>as impossible as finding two even numbers whose sum is odd.

That is a great line worth remembering.

> Either you sacrifice memory safety or you accept a more restrictive paradigm than GC'd languages give you.

This is true but there is a middle ground. You use a reasonably fast (i.e. compiled) GC lang, and write your own allocator(s) inside of it for performance-critical stuff.

Ironically, this is usually the right pattern even in non-GC langs: you typically want to minimize unnecessary allocations during runtime, and leverage techniques like object pooling to do that.

IOW I don't think raw performance is a good argument for not using GC (e.g. gamedev or scientific computing).

Not being able to afford the GC runtime overhead is a good argument (e.g. embedded programs, HFT).

There's a school of thought that correctly states that in that case it is very easy to cause expensive drop behavior to be ran for each element in the vector where a faster batch approach could instead be done, which is doable if not encouraged with defer, so it should be prioritized to push people towards that.

I do not subscribe to that idea because with RAII you can still have batched drops, the only difference between the two defaults is that with defer the failure mode is leaks, while with RAII the failure mode is more code than you'd otherwise would have.

[dead]

Same story with the Mojo language, unfortunately.

To me this raises the question of whether this is a growing trend, or whether it's simply that languages staying closed source tends to be a death sentence for them in the long term.

Yep. Same dilemma as Star Citizen. If both just threw their hands up and said, "Done!", today then everyone would agree that a great product had been released and everyone would be mostly pleased. Instead, development has dragged on so long as to cast doubts over the goodwill of the founders. Now, Jai is unusable because it's difficult to trust Blow if he's willing to lie about that and Star Citizen is unplayable because the game was clearly released under false pretenses.

The Odin programming language uses an implicit context pointer like Jai, and is freely available and open source.

I also found this comment a bit strange. I'm not aware of a situation where this occurs, though he might be conflating creating an anonymous function with calling it.

Probably misspoke, returning or passing anonymous functions cause allocations for the closures, then calling them causes probably 4 or 5 levels of pointer chasing to get the data that got (invisibly) closed over

Zig comes with a mountain of friction and ceremony, imo. It does a lot of things well, but for game dev I'd take Jai or Odin every time.

I can see the appeal if there is a need for stronger metaprogramming. Not that Zig is terrible in this area, it is just that Jon's language is much more powerful in that area at this stage.

That being said, I do see an issue with globally scoped imports. It would be nice to know if imports can be locally scoped into a namespace or struct.

In all, whether it's compete or coexist (I don't believe the compiler for Jon's language can handle other languages so you might use Zig to compile any C or C++ or Zig), it will be nice to see another programming language garner some attention and hopefully quell the hype of others.

Hard to see this compare at all without examples, but I'll stay patient

Well, they promise to release a full commercial game engine alongside it, so that might help :)