Four Years of Jai (2024)

Surprising deep and level headed analysis. Jai intrigues me a lot, but my cantankerous opinion is that I will not waste my energy learning a closed source language; this ain’t the 90s any more.

I am perfectly fine for it to remain a closed alpha while Jonathan irons out the design and enacts his vision, but I hope its source gets released or forked as free software eventually.

What I am curious about, which is how I evaluate any systems programming language, is how easy it is to write a kernel with Jai. Do I have access to an asm keyword, or can I easily link assembly files? Do I have access to the linker phase to customize the layout of the ELF file? Does it need a runtime to work? Can I disable the standard library?

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.

> as soon as something's open sourced, you're now dealing with a lot of community management work which is onerous.

This is a common misconception. You can release the source code of your software without accepting contributions.

> without accepting contributions.

it's not even contributions, but that other people might start asking for features, discuss direction independently (which is fine, but jblow has been on the record saying that he doesn't want even the distraction of such).

The current idea of doing jai closed sourced is to control the type of people who would be able to alpha test it - people who would be capable of overlooking the jank, but would have feedback for fundamental issues that aren't related to polish. They would also be capable of accepting alpha level completeness of the librries, and be capable of dissecting a compiler bug from their own bug or misuse of a feature etc.

You can't get any of these level of control if the source is opened.

You can simply ignore them. This worked for many smaller programming languages so far, and there exist enough open source softwares that are still governed entirely by a small group of developers. The closedness of Jai simply means that Blow doesn't understand this aspect of open source.

I believe sqlite does this.

Famously, yes: https://sqlite.org/copyright.html (see "Open-Source, not Open-Contribution")

By my reading, the restriction seems to simply impose some (reasonable?) legal restrictions on contributions rather than ban them out of principle.

Interesting, they've softened their stance. Today, it reads

> In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.

But it used to read

> In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from unknown persons.

(I randomly picked a date and found https://web.archive.org/web/20200111071813/https://sqlite.or... )

Seems to be hardened not softened: a person who has submitted an affidavit dedicating code fo the public domain is at least minimally known, but a person may be known without submitting an affidavit, so the new form is strictly a stronger restriction than the old one.