kunos

The closest thing would be the book that Ivo Balbaert is writing and that's available here: https://github.com/Ivo-Balbaert/The_Way_to_Jai

this is also good: https://github.com/Jai-Community/Jai-Community-Library/wiki

> 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.

> crazy fast compilation times

This is just not true and it's the reason #1 I am not using Zig. To give you some numbers, ZLS is a reasonably sized project (around 62k LOC of Zig) and on my very beefy machine it takes 14 seconds to build in debug mode and 78 seconds to build in release mode.

Because of the "single compilation unit" approach that Zig uses this means you are paying for that very same time regardless of where you modify your program.. so basically clean rebuild time is equal to simple modification time.

As a comparison my >100k LOC game in Rust takes less than 10s to build in release mode for modifications that happen not too far down the crate hierarchy.

So yeah, be for whatever reason you want (LLVM, no incremental builds and so on) as for today Zig is not even close to having "crazy fast compilation times".

Not for Rust tho. VSCode+Rust Analyzer offers an amazing experience and I found it to be on-par if not better than IntelliJ/Clion with a much more responsive editing, startup times and task customization.

> Except we're talking about video games

Not really. Most of the times Casey & Co. (Blow et others) have entire rants bitching about photoshop, visual studio,windows, websites etc. They tend to present videogames as example of "how it should be done".

They (again, as Casey&Blow and the rest of the group they seem to belong to) have this weird attitude of automatically dismiss anything that doesn't belong to whatever microsubset they are already very experienced in.. so Rust is shit, C++ is shit, GC is shit, smart pointers are shit, get/setters are shit, public/private is shit, memory safety doesn't matter and so on.. all this while not offering any alternative other than "git gut". I tend to agree with a lot of the rants to be honest but I also perceive their suggested solutions as total non starters for large scale development.

sadly no, modules won't solve this problem. Yes you can write your implementation in a single module but it'll behave as if you were writing them in a .h file. That means that changing a single number in a module will trigger a recompilation of all the dependent modules. At the end of the day you end up with slower compile times for small changes. I was hoping to finally be able to be done with header files but no.. another missed opportunity for C++. Perhaps future C++ compilers will be able to figure out if the external surface of a module has actually changed or not and make this possible.. but alas it doesn't seem to be the case in VS2019 at the moment.

Honestly I think Haskellers should spend less time writing blogs and more time writing code that does something interesting/useful. When the language you claim being so superior comes with such bad tooling and usability your claim instantly looses any substance.

You keep missing the point entirely. Go was created to solve a very specific Google scenario: offer a valid alternative to C++ and Java for whatever they do in Google. It's not a language created to make college students or language hippies happy..if you are looking for that look somewhere else. Go can be picked up by any dev with minimal experience in C/C++/Java in 1-2 weeks and that was one the main design targets. Another one was fast compile times, adding all those nice features you'd like would also make the language more complex to parse and compile. I think you can talk about how much you like Haskell all day long, but if you keep using Go as a comparison you simply show you have no clue of what you are talking about. It's literally apples to oranges.