The context thing has already been implemented in Odin. So if you wanna try that out, you can do that right now using Odin. Which is a language that is actually released and is public.
@@DeeaA.-qu2bn That is, unfortunately, exactly how I feel too. I like Odin, but if Jai hits the market before Odin has reach a critical mass in adaptation, I firmly believe people will throw it aside for Jai. NB. That is why I am going with Zig as my manual memory managed language.
@@dongueW Well, I will share why I have that exact same thought. Odin is sitting between 2 chairs. Being marketed towards game developers but as a general purpose language. Zig is an amazing general purpose language and even though Odin looks really nice as an improvement on C++ for game dev, Jai looks absolutely amazing for game development. I fear that Odin will be squeezed between Zig and Jai and end up a small obscure language that some people in the game dev community love, but that most people don't even consider.
@@ViaConDias What do you think Jai gets right that Odin may be dropped in favor of it for from your perspective in game development? Is there a specific feature set? The community mindset? Trust in Jon? (Maybe some combination)
I think part of what he's talking about here revolves around compiler optimizations which a language like C++ added compiler hints for to make it more explicit such as constexpr and consteval, but which in general shouldn't be needed with modern compiler techniques. However, it's sad to my mind that he's been working on his language for longer than I've been working on mine and he has had help yet he's maybe as far away from releasing Jai as I am my own language. Of course, I do keep adding ideas to mine and even though the x86 code generator works I want to wait until I get the ARM code generator working too. At some point, maybe after release, I'd love to come up with a language subset and make a 6502 and/or a z80 code generator. It'd be awesome to write a game that you could just hit compile and generate a binary for a Game Boy or NES.
That makes little sense. At some point you're gonna have to clear some buffer of memory, or your program is gonna keep growing in memory forever, hahaha.
@@lucy-pero for smaller programs that just run and doesn't have a loop (like a game loop) it's legit to just allocate and just let the OS free on exit, it's just not a problem but for larger applications yeah you need to free stuff so it won't like n bytes every frame and stuff
In memory only cases under the right circumstances sure, unless you mean something like object pools. But as soon as something like files get involved even the OS might not free it properly so you might as well free the memory while you're letting go of the file handle.
@@lucy-peroIt depends on how you use that memory. You can just allocate one big block, and reset the allocation offset at the end of the loop iteration. Very simple and practical for a lot of applications
Python had an arena allocator called pymalloc, then it was replaced by mymalloc. Garbaje collectors had evolve a lot the last 20 years, even on python who never focused on performance. I wonder what is the performance penalty on modern GC vs manual management.
The runtime performance is very small but it's not the performance difference that is the reason to not used GC/AMM languages. It's the lack on fine control over the memory allocation and the deallocation. You can have periods in your app where you need every single clock cycle so you do not want any delay of any sort to happen right then and there, then a few seconds or minutes later you might have plenty of time to clean up. This could be a critical system on a car, plane, etc., it could be precise measurement of extremely fast events like CERN working years to set up an experiment that plays out in 5 nanoseconds, or something as simple as a game where you don't want a sudden lag right when the hero is pushing the button to defeat the final boss.
All this said, I absolutely think that 95% of all software today should be written in GC/AMM languages. It is faster development and it is safer at runtime. Now, you mention Python, and I just want to point out that Python is not a typical GC language. It is an interpreted language and therefor it is far to slow to be useful for almost anything other than what it is meant to do, which is to wrap around, or glue together if you will, high performance C, Fortran, etc., code bases. That people ever started to write whole big applications in Python is a very bad thing, that should be stopped. We do not want billions of lines of Python code running 24/7 consuming 50 - 1000 times more power and natural resources then the same system build in a non-scripting language. I love python and use it for what it is intended to be used for.
Well even to this day there are talks about game devs having to do all sorts of work to reduce the damage that GC has done with the performance of their games so yeah it's still an issue.
Once it is out should not be hard to write bindings for it via GDExtension similar to how languages like Rust have bindings to Godot (or c++ if you want the default GDExtension option).
![Gunna - back in the a [Official Video]](http://i.ytimg.com/vi/oBrbejOHjLw/mqdefault.jpg)
The context thing has already been implemented in Odin. So if you wanna try that out, you can do that right now using Odin. Which is a language that is actually released and is public.
I do not fault jb at all for keeping his language closed. As much as I like Odin I will very likely switch to Jai permanently once I have access to it
@@DeeaA.-qu2bn Do you mind sharing why? Why switch that is
@@DeeaA.-qu2bn That is, unfortunately, exactly how I feel too. I like Odin, but if Jai hits the market before Odin has reach a critical mass in adaptation, I firmly believe people will throw it aside for Jai.
NB. That is why I am going with Zig as my manual memory managed language.
@@dongueW Well, I will share why I have that exact same thought. Odin is sitting between 2 chairs. Being marketed towards game developers but as a general purpose language. Zig is an amazing general purpose language and even though Odin looks really nice as an improvement on C++ for game dev, Jai looks absolutely amazing for game development. I fear that Odin will be squeezed between Zig and Jai and end up a small obscure language that some people in the game dev community love, but that most people don't even consider.
@@ViaConDias What do you think Jai gets right that Odin may be dropped in favor of it for from your perspective in game development? Is there a specific feature set? The community mindset? Trust in Jon? (Maybe some combination)
I think part of what he's talking about here revolves around compiler optimizations which a language like C++ added compiler hints for to make it more explicit such as constexpr and consteval, but which in general shouldn't be needed with modern compiler techniques. However, it's sad to my mind that he's been working on his language for longer than I've been working on mine and he has had help yet he's maybe as far away from releasing Jai as I am my own language. Of course, I do keep adding ideas to mine and even though the x86 code generator works I want to wait until I get the ARM code generator working too. At some point, maybe after release, I'd love to come up with a language subset and make a 6502 and/or a z80 code generator. It'd be awesome to write a game that you could just hit compile and generate a binary for a Game Boy or NES.
I´m a cpp dev and I never free memory to be faster. I let the os free the memory for me at the end instead.
That makes little sense. At some point you're gonna have to clear some buffer of memory, or your program is gonna keep growing in memory forever, hahaha.
@@lucy-pero for smaller programs that just run and doesn't have a loop (like a game loop) it's legit to just allocate and just let the OS free on exit, it's just not a problem
but for larger applications yeah you need to free stuff so it won't like n bytes every frame and stuff
Try that in a game that runs for hours and allocates memory potentially every frame at 60 frames a second.
In memory only cases under the right circumstances sure, unless you mean something like object pools. But as soon as something like files get involved even the OS might not free it properly so you might as well free the memory while you're letting go of the file handle.
@@lucy-peroIt depends on how you use that memory. You can just allocate one big block, and reset the allocation offset at the end of the loop iteration. Very simple and practical for a lot of applications
Cool idea. I like it.
Oh no, he is going to thresh my boy's GC...
Jai is a psyop, it doesnt exist, everytime youve seen it used it was pre recorded cgi
a
Python had an arena allocator called pymalloc, then it was replaced by mymalloc. Garbaje collectors had evolve a lot the last 20 years, even on python who never focused on performance. I wonder what is the performance penalty on modern GC vs manual management.
The runtime performance is very small but it's not the performance difference that is the reason to not used GC/AMM languages. It's the lack on fine control over the memory allocation and the deallocation. You can have periods in your app where you need every single clock cycle so you do not want any delay of any sort to happen right then and there, then a few seconds or minutes later you might have plenty of time to clean up. This could be a critical system on a car, plane, etc., it could be precise measurement of extremely fast events like CERN working years to set up an experiment that plays out in 5 nanoseconds, or something as simple as a game where you don't want a sudden lag right when the hero is pushing the button to defeat the final boss.
@@ViaConDias Ok, that's a fair point.
All this said, I absolutely think that 95% of all software today should be written in GC/AMM languages. It is faster development and it is safer at runtime.
Now, you mention Python, and I just want to point out that Python is not a typical GC language. It is an interpreted language and therefor it is far to slow to be useful for almost anything other than what it is meant to do, which is to wrap around, or glue together if you will, high performance C, Fortran, etc., code bases. That people ever started to write whole big applications in Python is a very bad thing, that should be stopped. We do not want billions of lines of Python code running 24/7 consuming 50 - 1000 times more power and natural resources then the same system build in a non-scripting language.
I love python and use it for what it is intended to be used for.
@@ViaConDias my point was that; even python, the slowest language; had a good and fast GC.
Well even to this day there are talks about game devs having to do all sorts of work to reduce the damage that GC has done with the performance of their games so yeah it's still an issue.
Am I the only one that thinks jai should be integrated into godot?
Once it is out should not be hard to write bindings for it via GDExtension similar to how languages like Rust have bindings to Godot (or c++ if you want the default GDExtension option).
Jai doesn't really exist as of yet
Godot devs are very pro Object Oriented Programming, so it's very unlikely that they would do that. Considering that John does not like O.O.P.
a