
JAI Primer: A Programming Language for Games - tasoeur
https://sites.google.com/site/jailanguageprimer/
======
AlexeyBrin
_As of this writing there are no public compilers for Jai, so all information
in this text is collated from Jon Blow 's YouTube videos. _

Until the language is actually released, at least in an alpha version, writing
a tutorial is just speculation. Anything can change in the actual language
implementation.

That being said, the author initiative is laudable if you don't want to watch
a few hours of Youtube videos.

~~~
candeira
I have a friend who writes a lot of C++ code for signal processing, software
sound synthesis mainly.

Watching Jon Blow's videos I could tell this was something my friend would be
interested in, because the problem space is very similar: you need realtime
performance, can't afford even the slightest garbage collection pause, etc.
However, I could not tell my friend "go watch videos for six hours".

Thanks to Jorge Rodríguez, I can email my friend a document that will take him
less than half an hour to read.

~~~
nephewtom
This is what Jon Blow said about C++ on Twitter:
[[https://twitter.com/jonathan_blow/status/561371202350878720](https://twitter.com/jonathan_blow/status/561371202350878720)]

"If you want to never get any work done, use a programming language like this:
[https://isocpp.org/blog/2012/11/universal-references-
in-c11-...](https://isocpp.org/blog/2012/11/universal-references-in-c11-scott-
meyers) "

I used to enjoy programming in C++, even though I always thought it was too
complex. Too many things to learn and too many approaches. For example, I
never could grasp template-meta-programming thing. May be I didn't dedicated
enough time, but that's the point. If it takes so much time to learn the
language and its complexities, you have much less time to program "things"
with it.

------
kabdib
Rule of thumb for doing a programming language: Write the debugger first. Or
at least, very, very early. This will inform you of poor choices you've made,
and you're going to need a debugger anyway.

~~~
cheepin
What poor choices are revealed by writing a debugger in particular?

At this point, he compiles Jai to C, and the compiler isn't too gigantic yet,
so there's not a huge surface area to look for compiler bugs.

~~~
humanrebar
> What poor choices are revealed by writing a debugger in particular?

Well, for one, you can't just transpile to ANSI C, compile, and end up with
sensible debug symbols in your binary. You'll end up with debug symbols for
the C code, not the original language. So you end up writing in one language
and debugging in another. This is one reason most new languages target LLVM.

~~~
sanxiyn
Compiling to C with #line directive actually gives a good enough debugging
experience, similar to compiling to JavaScript with source map. This is _much_
easier than generating debug info, even with LLVM.

~~~
pcwalton
I don't think it's good enough. You can't inspect variables, types will be
wrong, any namespacing you're doing will leak into the debugger, single step
won't give you the right semantics unless your language is extremely close to
C, gdb pretty printing won't know how to print your language's values, etc.

Backtraces will sort of work (although the name mangling will leak through),
but little else will. You really need to generate DWARF directly in your
frontend in order to have an acceptable debugging experience.

------
imron
I love the idea of seamlessly switching between AoS and SoA for data types.

~~~
unwind
For those who don't follow, the acronyms mean "array of structures" vs
"structure of arrays". These are two orthohonal ways to represent data, both
of which have advantages which make them attractive. Being able to switch the
same data around between the two is cool and innovative.

------
DoctorZeus
The #run directive addresses some major pain points for me. Is there anything
analogous in other languages?

~~~
adrusi
Yeah, similar constructs exist in D and Nim.

I don't know well enough how they compare to give any thorough analysis,
though.

~~~
renox
I don't know what Nim do but AFAIK in D you're (voluntarily) limited in what
you can do at compile time because in effect with Jai compiling a program is
running it, so this can have security implications..

------
eigenbom
I'm excited for Jai, and if it ever makes it out into the world I look forward
to building some games with it.

However, I just see C++ continuing to get better and better for games
programming. The recent appearance of the Core Guidelines [1] (and the
eventual codified form for compilers) will be a huge leap. I wish we had full
#run-type control over the compile phase, but full constexpr support is a step
of the way there.

1\.
[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md)

------
vvanders
Aside from the aos/soa I feel like Rust hits a lot of the same points.

Nice to see #run similar to elixir macros.

~~~
Hemospectrum
Yep, a lot of people have noticed that. He's mentioned Rust in a few of his
videos (and the compiler devs are always taking notes about his grievances)
but he doesn't seem interested in working with the Rust community in any way.
He considers Rust too ideologically opinionated to be of use to him.

~~~
PopeOfNope
> He considers Rust too ideologically opinionated to be of use to him.

He's not wrong. The rust community approaches everything from the standpoint
that we should be forcing devs to code in a particular way because safety.
What I like about Blow is that, so far, he's big into giving the dev options
along with some (completely optional) syntactic sugar. The focus is on
functionality, not ideology.

~~~
pcwalton
> The rust community approaches everything from the standpoint that we should
> be forcing devs to code in a particular way because safety

No, I'd actually be perfectly fine allowing the safety features to be turned
off, and have suggested it several times. Nobody has seemed particularly
interested, though, because what people tend to find is that safety ends up
being good for _productivity_ as well.

~~~
sanxiyn
I don't think that's entirely true. We had many people interested in turning
off bound checks with compile option, but it was rejected.

~~~
pjmlp
Those who don't learn from history are doomed to repeat it.

My favorite Hoare quote given at his ACM award speech in 1980, referring to
his work in Algol during the late 60's:

"Many years later we asked our customers whether they wished us to provide an
option to switch off these checks in the interests of efficiency on production
runs. Unanimously, they urged us not to - they already knew how frequently
subscript errors occur on production runs where failure to detect them could
be disastrous. I note with fear and horror that even in 1980, language
designers and users have not learned this lesson. In any respectable branch of
engineering, failure to observe such elementary precautions would have long
been against the law."

~~~
erikpukinskis
In Jai it is easy to, for example, have bounds checks on during the entire
development process to aid in finding bugs, then turn off bounds checks in a
dozen critical loops for testing and release, then turn bounds checking on in
one loop that still proved crash-y.

Blow has said many times: he doesn't think the language should be prevent you
from shooting yourself in the foot, because sometimes that means preventing
you from doing what you want to do.

He usually asks: what is something simple we can do that will give us 90% of
the benefit, without adding a layer of overhead. Rather than Rust's "Safe All
The Things!" approach, bounds checking is just another tool you can use or not
use as is appropriate for the context.

~~~
agentultra
Most Common Lisp implementations, for what it's worth, take this approach as
well. For tight loops where you've removed the invariants and proved its
bounds removing the run-time checks can give a non-trivial performance boost
to production systems.

~~~
zurn
If you mean the (speed 3 safety 0), it's more in line with pcwalton's idea to
have a switch for generally turning off safety checks, not just bounds checks
- because the other checks typically affect performance more.

~~~
steveklabnik
Most of the checks affect compile time performance in a minor way, but also
have no runtime overhead. The borrow checker is an entirely compile-time
thing, for example.

------
jjaredsimpson
Watching him occasionally stream his sessions shows me that what he is doing
is just funzies.

His tooling is so far behind anything all other languages have that I would
never bother to learn this language, because it was "for games."

If I wanted to make a game I would learn any engine using any number of
language bindings.

~~~
adrusi
He's been working on this project mostly alone for only a few months, how can
you possibly expect the tooling to be on par with anything else.

There's a reason it's not released.

And it's great that you can just pick up an engine, but someone's gotta write
that engine, and there's a reason triple a studios aren't using unity for
major releases; you'll never get quite as good performance out of a general
purpose engine as you would from a custom one.

~~~
cheepin
Hearthstone (by Blizzard) is a Unity game, not that performance is a huge
concern for card games. It's a pretty thin client mainly for displaying the
animations/artwork while most of the logic runs serverside.

Still, it's a very profitable game by a triple A company.

~~~
learc83
Hearthstone isn't what anyone would normally call a AAA game though. Until the
end of the beta they only had 15 employees working on it.

They basically had to use an established engine because they didn't have the
budget to build their own.

