> What features in Jai make it superior to C++ for writing games specifically?
Some examples that come to mind from my personal experience.
- Compile times. 1-2 seconds vs the typical build times in a C++/Rust game can be a game changer
- Massive compile time capabilities.. you can have an entire content pipeline executed at compile time, all written in Jai
- Builtin Type reflection.. another gamechanger in games for editors and such
- Very easy to debug, the minimalistic approach means the code is not heavily transformed by the compiler thus really easy for a debugger to follow and still performant. Example: loading the same gltf file in my engines in Rust and C++ debug mode is MUCH slower than debug mode in Jai.. again, game changer.. you hit build/run and you're back in the game in few seconds.
- Very easy to learn
- Very ergonomic in its minimalism
- A lot of small things you instantly miss when jumping to other language.. one thing on the top of my head.. the ability to have struct members "overlay" other specific locations.. so you could have a Matrix4 struct with Vector members "forward" "right" "up" etc
- The builtin "context" based "temp allocator".. perfect for games, anything that is needed for a frame goes in there with close to zero allocation time and it gets reset every frame at zero cost
Jai has a HUGE potential if it can survive Mr. Blow's ego.. which is a big big ask.
I watched a video presentation and cringed a bit to be honest.
I've done a bit of 3D with Go some time ago ( https://www.youtube.com/watch?v=cjn3twYB7xQ ) and quickly realized it's not a viable tool because of the huge FFI overhead... weird to see all this claims about performance in an engine that will leave so much on the table every single time it makes a call into Vulkan... as soon a decent scene will be added it'll crawl to a stop.
I wish Go didn't have this performance bottleneck because I really like the language and it would be a great middle ground for indie like games that don't want to follow the big engines route but sadly any kind of request of a faster path to call cgo was ignored by the Go team as games is not really something they are interested in.
Still best of luck to the guy but eventually he'll hit a wall and all the claims about performance will look funny.
> Dude, it is not safe programming if you put all your code under unsafe brackets.
I'd be surprised in my Rust game (custom engine) had more than 1% code in unsafe blocks. If your does have "ALL under unsafe brackets" you are doing Rust really wrong.
Here's my experience so far.
1) The best analogy for LSP is GPS navigator in your car. It's invaluable when you have to navigate to unknown places to do stuff but, it also slows down your ability to learn the roads of your closer neighbourhoods.
I am often surprised how confused I am if my GPS sends me down a road that is closed for whatever reason and I have no idea how to figure out an alternative route even if I am driving around my place, it shows me how much I rely on the navigator to get me anywhere now.
So what using an LSP is doing for you heavily depends on the kind of code you write. Are you the kind of dev who works in pretty much a very familiar codebase for a very very long time? Then LSP could even be impeding acquiring a better mental image of your code. Conversely, if you are a coder who often ventures into different and unknown parts then LSP might make you way more productive.
2) Depending on the language, LSP can become an actual part of the language itself. When I code in languages with good LSP (C#, Rust but also C++) I often code with the LSP as my "target".. I think what I'd like to see popping up when I type a "." . In this part of the code I want to see this var and this method.. in that part of the code I want to see also this other vars and methods it gives a very good idea of what the "surface area" of a piece of code looks like.
LSP are also very good instant feedback if something you are typing is wrong. I press "." and nothing shows up? I have some error somewhere and/or the thing I am dotting is not what I think it is.
But, in order for this to work the LSP has to be REALLY good to the point that has to be close to zero doubt that if the LSP is not behaving it means it's your fault. Sadly, not many LSP ever reach this level of reliability.
This is one of the thing that made languages such as C# and Java so popular: the ability to "dot" your way through unfamiliar libraries with great ease without having to dive into documentation to discover there's a function X in some file Y that already does exactly what you are trying to do.
Some examples that come to mind from my personal experience.
- Compile times. 1-2 seconds vs the typical build times in a C++/Rust game can be a game changer
- Massive compile time capabilities.. you can have an entire content pipeline executed at compile time, all written in Jai
- Builtin Type reflection.. another gamechanger in games for editors and such
- Very easy to debug, the minimalistic approach means the code is not heavily transformed by the compiler thus really easy for a debugger to follow and still performant. Example: loading the same gltf file in my engines in Rust and C++ debug mode is MUCH slower than debug mode in Jai.. again, game changer.. you hit build/run and you're back in the game in few seconds.
- Very easy to learn
- Very ergonomic in its minimalism
- A lot of small things you instantly miss when jumping to other language.. one thing on the top of my head.. the ability to have struct members "overlay" other specific locations.. so you could have a Matrix4 struct with Vector members "forward" "right" "up" etc
- The builtin "context" based "temp allocator".. perfect for games, anything that is needed for a frame goes in there with close to zero allocation time and it gets reset every frame at zero cost
Jai has a HUGE potential if it can survive Mr. Blow's ego.. which is a big big ask.