I watched all his videos and my main take away was that there is actually no high level language besides C (and restricted subsets of C++ that don't use templates) that can be used to tell the computer what to do. Almost every high level language we have already abstracts away the idea that you are trying to control a piece of hardware. Game programmers are in an ideal position to have learned what is actually needed to make talking to a computer more efficient. The fact that J also has the vision to build the language to account for real world development processes is almost like an added bonus.

Presumably Rust wasn't stable enough for him to consider because that's the single language that seems to address his complaints.

Once you bar garbage collection, you're pretty much left with C, C++, and Rust (FORTRAN weenies can leave the room, thanks).

Also, he doesn't like Rust's stance on safety -- he thinks it's going to lead to too much hand-holding and boilerplate annotations.

Yes, that's the main design difference between Jai and Rust.

My personal feeling is that memory safety isn't something I want to compromise on. But, I work on browsers and not games, so I'm perfectly willing to acknowledge that, for games, developers may be willing to sacrifice safety for fewer type system restrictions. Browsers, critical OS components, databases, etc. are security critical, while games aren't. I'm a pluralist when it comes to programming languages, and I'm perfectly willing to accept that there are prima facie valid reasons for not wanting memory safety. One thing I like about Jai is that it's very up-front about not being type-safe or memory-safe, and specifically argues against the usefulness of memory safety for its domain.

It's interesting, though, that whenever I've floated the possibility of relaxing restrictions on an opt-in basis for apps that don't care about memory safety as much the reaction of the Rust community has been lukewarm at best and usually pretty negative, even from the game devs. It's interesting: most people don't want to give up their memory safety, once they see the benefits that it brings in terms of developer productivity (preventing annoying bugs). That's the camp I'm in too, at least for the apps I write.

In one of his latest video he show how it is going to work for array access: by default it's checked, but you have a directive to make one (or a block) of array access unchecked and then you have a global directive which can change the default to check all the array access or NOT check all the array access. So you get the full range from safe array access to C-like performance and with the possibility of dropping the checks only where this impact really performance.

Memory safety isn't limited to array access, but I really like the idea of this kind of control (even though for library this could create issue, I think that there are plans to allow the use of an 'ANDF' like format for libraries).

Bounds checking isn't as interesting as use-after-free protection (like the borrow check) for a couple of reasons: (1) you can easily opt-in and opt-out on a case-by-case basis (even in Rust), whereas UAF protection is nonlocal; (2) bounds checks rarely if ever show up in profiles with a well-designed iterator library and an optimizing compiler.

I mostly agree with you (UAF is more interesting but more difficult that bound checking), but I would nitpick on details:

- yes you can opt-in and opt-out on a case-by-case basis in Rust for bound checking but can you globally remove checks and globally force checks?

- as for UAF protection being non local, a true UAF protection true but a 99% solution such as overwriting the data with know garbage on free (0xDEADBEEF) and ensuring that the allocator doesn't reuse virtual addresses may be good enough in practice, no? But yes it's probably too expensive to release with such configuration..

> - yes you can opt-in and opt-out on a case-by-case basis in Rust for bound checking but can you globally remove checks and globally force checks?

No. Nobody has asked for it, because nearly all bounds checks in Rust just don't matter from a performance point of view, and thus there is no reason to remove them.

> - as for UAF protection being non local, a true UAF protection true but a 99% solution such as overwriting the data with know garbage on free (0xDEADBEEF) and ensuring that the allocator doesn't reuse virtual addresses may be good enough in practice, no?

You can't avoid reuse of virtual addresses. That would have terrible cache implications.

The only thing that sorta works is something like WebKit's PartitionAlloc, but that only mitigates some exploitation scenarios. There is no easy solution to UAF.

> You can't avoid reuse of virtual addresses. That would have terrible cache implications.

--> terrible TLB implications

> There is no easy solution to UAF.

Agreed.

> Browsers, critical OS components, databases, etc. are security critical, while games aren't.

This is only true for singleplayer games. For multiplayer games security is critical, because they are exposed to the internet.

  > How about designing a language for programmer joy.

Matz says that he created Ruby to make programmers happy, specifically.