JAI is for games in the sense that reflects the experience of a well known game developer that writes game engines and games.
back
1 comments
And also in the sense that it allows you to easily remove the safety checks when you need higher performance while Rust doesn't necessarily allow it (array access for example).
So I'd say that Rust seems more suited to write an OS, a webbrowser as in both cases safety is critical and Jai for games as performance is critical.
For other applications which needs low latency (so no GC) but are neither safety critical nor performance critical?
Jai's 'look and feel' seems to me much more seducing than Rust (assuming/hoping Jai becomes real).
Rust does let you do unsafe array indexing and other unsafe stuff. But it doesn't support switching the semantics of safe code to unsafe with a build flag, you need to explicitly use "unsafe" in code.
> But it doesn't support switching the semantics of safe code to unsafe with a build flag
Jai allow this for array indexing AND it also allow the reverse: reinserting array checks even when there is an 'unsafe access' operation: this way even if you made a mistake in adding an 'unsafe access' operation it's easy to find where the error is (assuming the error is reproducible of course).
I haven't seen any cases in which adding a global build flag to turn off bounds checks would actually improve performance. People overfocus on bounds checks because they're an easy thing to understand, but they're just one of many performance issues when creating a new language, and not a particularly interesting one at that since APIs, compiler optimizations, and branch predictors all conspire to drive their overhead down to near-zero (in my experience).
Sure, but I think that having one global flag to remove bound checks is useful as it allows you to measure this bounds checks performance impact easily.
And then when you know how long it takes to find an index out-of-bound error and you see that the removal performance improve is small.. Well, you remove the flag.