Jai Language Primer (2017) | Hacker News Reader

Jai Language Primer (2017)

github.com

53 pointsbegoon41 comments

Just a warning, this document doesn't reflect very well where Jai is at in 2021.

The best place to get information about the language is this youtube playlist: https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1...

However it has a lot of content.

I'm not super eager at having to watch a few 1-2 hours videos to even understand why I should use Jai.

jblow seems like a really talented developer. I loved Braid and there's clearly some great work being put into Jai. But if (and this is a big if) he wants to make Jai into a language people use, he should seriously consider putting more effort into the documentation and distribution side.

>...he should seriously consider putting more effort into the documentation and distribution side.

In addition to what other people have said, Blow is explicitly working on documentation over time and closed beta users have access to a fair number of documents detailing both language features and the philosophy behind the language.

One huge reason why the language IS still in closed beta is because Blow believes heavily in not releasing half-assed work. Documentation is a part of that.

From watching some of his Twitch streams, I get the general impression that he really doesn't care if Jai is a language that "people" use. He seems to be developing it basically entirely as a language that he wants to use and whether anyone else outside of his company uses it is almost irrelevant.

Languages are subjects to network effect and in the long term that is what will make or break them. Now, when one has to eventually deal with the wider public (just like when developing any given product addressed at public), it pays to consider its feedback. I understand that he is experienced and that most likely he knows better than what he might get from such feedback. We'll see how this turns out.

>Languages are subjects to network effect and in the long term that is what will make or break them.

That's a circular argument given what's discussed in this thread.

The "make or break them" presupposes the goal is for the language to "break out", whereas the parent said the goal is for the creator to be satisfied and use the language himself.

There tons of languages in domains like gaming where nobody cares if they "break out" or for network effects. People write them to use them themselves.

"the goal is for the creator to be satisfied and use the language himself"

That is only one of the goals. The author is also interested in making that language public at one point, even if that comes as a far secondary concern for him, otherwise he wouldn't have bothered to publish anything.

"That's a circular argument given what's discussed in this thread."

What would you say to "whether anyone else outside of his company uses it is almost irrelevant"?

he had a recent interview where he addressed this directly: his philosophy is that there's too much crappy stuff out there that's heavily promoted and branded, and so he's trying to get the language to a place where it's stable and worth using before he does a general release / chooses an actual name. It's in closed beta now.

I know. Anyway the playlist is not about why _you_ should use the language but more about why he started developing it and some of the more important steps along the way (2014 - 2021).

The compiler is not out yet, it's in a closed beta to a small number of developers with plans to release later this year (to the best of my knowledge).

jai isn't publicly available yet. (It's currently in a private beta.)

It took me a long time to find this out. It never occured to me the source code is private when an author is posting so many videos and discussing about the design of language.

The source code is not even published for public access

Well, he's not releasing it generally yet, so it's not fair to criticize not releasing documentation. This was created by someone else. He mentioned that when he open-sources it or soon after, he's planning on releasing the engine from the game Thekla is currently working on, which will provide a good sample of "idiomatic Jai". I'm hoping that good documentation will come with it.

The page says "Jai could be described as a modern replacement for C"

Rust and Zig are other languages that more or less try to be replacements for C. Without having looked too deeply, it feels like Jai could more or less be described as similar to D (with the -betterC flag, perhaps). Does that seem like a reasonable characterization? Is there something specific that Jai brings to the table that those other languages don't?

Well D and Rust are more contenders for C++ in terms on how wide their agenda is. D is (unless you opt out ?) GCed, Rust is not but they both pack a lot. Zig on the other truly aims to be a C replacement I believe, trying to avoid it considers its pitfalls (preprocessor, build system, error handling...)

The D GC is written in D so you can opt out as you wish, but the standard library is designed around the GC.

That being said if you are in a situation where you cannot use the GC you probably wouldn't need the stdlib all that much anyway (there's a bunch of alternatives available).

The one thing I remember surprising me was that the build scripts were also jai.

The D compiler has a build script called (imaginatively) build.d (rdmd let's you run a single D file in one step), and although it's not super sophisticated, I'm already convinced that makefiles should be considered harmful if the alternative is something in a real language.

Not only can you actually read the code, you can also express things in a platform agnostic way rather than the inevitable "which make are you actually" bug report

I think that is also the case for Zig. The build system is a zig file.

> It is still in development and as of yet is unavailable to the general public.

Damn. I was hoping that had changed. I'm curious to see the hype, but I'm not into PL stuff enough to dig into a language I can't play with.

I'm into PL(T) stuff and I've gotten tired about hearing about Jai. One thing I like is Jai adopting the SPAD X-form (Chi-form); he (mis)attributes it to Sean Barret:

    The syntax name: type = value; specifies that a variable named name is of the type type and is to receive the value value

Where the inferred/imperative-assignment form is a visual reduction:

    name : type = expr
    name := expr

It has the lovely property that if you elide the type expression the variable gets an inferred type. If you keep the type expression, then the language has both a type-expression for type-checking and type of the value-expression for type-inference; then, the PL can be designed in one of a few ways:

1. If the type expression mismatches the type of the value-expression, fail;

2. If the type expression can be unified with the type of value-expression, keep the unified; or,

3. If the value expression can be coerced to the type expression, keep the type expression.

SPAD used the second behavior and it was the bees-knees. This was especially true since SPAD supported refinement (quotient) types, so you could do things like this:

    name : int(-2 < n and n <= 10) = ... complex expression that we can't prove is in the range (-2, 10] ...;

... and this would fail to compile.

Funny enough GDScript, the internal scripting language of the Godot engine, is using a similar form for (optional) type declarations.

    var damage: float = 10.5
    var damage := 10.5
    var dynamic_typed_damage = 10.5

If you use the colon you get a static typing, without it you get dynamic typing.

https://docs.godotengine.org/en/stable/getting_started/scrip...

That's nice! Is is gradually typed or just untyped?

If curious see also

2018 (a bit) https://news.ycombinator.com/item?id=16596282

2016 https://news.ycombinator.com/item?id=11086708

2015 https://news.ycombinator.com/item?id=10346985

I really like that the arrays are a full type that pack their size information. C has always frustrated me on this particular point. One question though : Is the array types passed as a pointer and an int or copied locally ? I guess 1. because 2. would not make much sense (although this the C behaviour for structs in C... I wonder why...)

(2017)

The language has come a long way since this writeup.

Year added above. Thanks!

Jai changed quite a bit since then.

For more current info check out beta user's impressions (and the language primer) here: https://www.youtube.com/watch?v=i1vbvikDiI8 (first video in the series)

Ahh, I wish they could do concise text updates like this article, videos are so time consuming.

I've been waiting for this moment for such a long time. A lot time spent watching Blow's streamings

Which moment have you been waiting for? I have also spent a lot of time watching his streams, but I don't believe Jai is a thing anybody can use yet, is it?

It’s not public yet, still in close beta

This AoS -> SoA feature is really cool

It is no longer in the language. Much of this document is extremely out of date.

It is available as a metaprogram in the standard library, afaik. Someone asked about it on one of his streams before.

(2017)

Year added above. Thanks!

Why must every new language use a completely unique syntax?

This is so tiring...why can't they just stick to syntax that everyone knows...each one has to reinvent random new syntax and destroy old conventions that people already know thus needlesly creating friction.

Most of it doesn't seem terribly new. It's like a hybrid of some classic-Algol-style, C-style, and Haskell-style (particularly at the function/struct declarations), but mostly C-style.

That he seems to have thought deliberately about stepwise refactoring is actually pretty nice. This is hard to do in many languages (where refactoring-to-function/method is often a wholesale endeavor). Doing it stepwise means you can iterate and test more deliberately throughout the process, and is nicer if you're not using a refactoring tool beyond your text editor.

In the end, reading the example code caused me no headaches, it was as clear as any other C/Algol-derived language.

Well, if you split "language" into 1) syntax, 2) semantics, 3) standard library, then why would you think that #1 (syntax) is the only part that can't be improved upon?

You might very well be fighting against a force of nature, i.e. shouting at the wind.

Reply on news.ycombinator.com