unless I missed it, one thing the video doesn't mention is that while _runtime_ with c# is more performant, launch/start time (from the editor, not the actual game) is far faster with gdscript - which can be a huge help if you are learning the engine or fine tweaking some numbers and get into this loop of changing one little thing and re-running your game a million times, believe me those few seconds start to add up real quick
I have heard they have a proposel to make GDScript compiled. But Honestly I would like a Trio of GD Script, Swift and C++ than C# in this group. Swift lang supports Windows,Linux,Android and Apple side pretty good. Also swift is overall better in case of performance than C#.
@@Volt-Eye. No. Swift isnt even used outside of the apple ecosystem. While C# is running many apps in the world, is performant with wide range of packages and community support. Not to mention linq!!
yeah pretty much how I approach stuff too. Most things are fine to do with GDScript so I usually stick to what's easiest, but once in a while C# can be worth the extra effort.
I will stick to C#; I've used it in Unity, and in Godot, it's not really hard to continue writing C# code. Also, why should I learn a new language when I already know C#? It is much easier for me to use C#, and that's what you said... it depends :D And I do not like GDScript, even if it might have some handy shortcuts and stuff At the end it is personal reference :) I have a better eye on overview in C# Thank you for your video :)
Thanks for the heart :) To be honest, Godot is performing quite well compared to Unity. Even though I had to work around a lot of things, it tries to keep things clear and structured. I'm happy about the situation with Unity :) It wouldn't even surprise me if they vanish within the next ten years. I don't think many will stay there after finishing their projects they are working on right now. I'm glad they implemented C# into Godot ^^ so it doesn't feel that much different.
I work with C# but I would suggest to use GDScript. Why? Cose C# will always be second class citizen and a bit clunky to use when comparing with GDScript. Also, porting to console is probably much easier with GDScript.
C++ is used for modifying godot features, but out-of-the-box isn't used to program stuff within godot. Via GDExtension, C and C++ can be used as well though (officially supported) and community members have made other languages available with varying degrees of support
@@vkmicrov GDScript is not compatible with python. You can't call a python library from gdscript, and you can't import gdscript in python. GDscript is pythonic but it's not python.
python is not officially supported by Godot, but there are some 3rd party projects that make various languages available. In most cases I'd suggest to stick with the official options though, unless there's a good reason to use the module. A lot of 3rd party stuff becomes discontinued after a while and I don't really like taking the extra risk
Like current Rust and an upcoming Swift bind, you would have to either find someone or maintain the langue binding yourself. There isn't a larger demand currently for Godot APIs bound to Python right now. Since there's no advantage over GDScript unless you get compiled Python bound. The main use cases would be calling on external Python bound code libraries, and most likely the underlying C++ binary. On Desktop, it's within Godot's APIs to ask the OS to run command line scripts, so you can build a Godot App that runs Python Scripts and then takes any results or files as needed.
You are not allocating and freeing memory manually in GDScript, therefore it is 100% garbage collected. Not sure where the idea that it wasn't came from.
@@CHURCHISAWESUM Well yeah, memory safety and garbage collection are mostly unrelated to each other. Memory safety isn't really a concept with scripting languages unless you are digging into the language used for the interpreter/runtime.
@@CHURCHISAWESUM GDscript garbage collection is very different from C# tho, GDscript is refcounted, refcounted garbage collectors usually don't suffer from pauses/lag spikes like C# does.
Go for c# if you can. gdscript is for programming noobs. If you know how to code, do it with a more known language. Don't lock yourself to a engine-only language. I speak for game devs. Or you can use both on spesific scenarios, why not. being type static is an important feature in game development in languages.
With the recent Godot 4.2 update, C# now has experimental support for Android and iOS again. Not 100% tested yet, but big progress!
unless I missed it, one thing the video doesn't mention is that while _runtime_ with c# is more performant, launch/start time (from the editor, not the actual game) is far faster with gdscript - which can be a huge help if you are learning the engine or fine tweaking some numbers and get into this loop of changing one little thing and re-running your game a million times, believe me those few seconds start to add up real quick
good point!
I have heard they have a proposel to make GDScript compiled.
But Honestly I would like a Trio of GD Script, Swift and C++ than C# in this group.
Swift lang supports Windows,Linux,Android and Apple side pretty good.
Also swift is overall better in case of performance than C#.
@@Volt-Eye. No. Swift isnt even used outside of the apple ecosystem. While C# is running many apps in the world, is performant with wide range of packages and community support. Not to mention linq!!
good review mate keep the great job
I use gdscript when I don't need performance. Vectors are much easier to use in gdscript compared to c#.
yeah pretty much how I approach stuff too. Most things are fine to do with GDScript so I usually stick to what's easiest, but once in a while C# can be worth the extra effort.
same, since godot 4 that has been my approach as well... before I was pure C# because I can't stand coding without first class lambdas
I will stick to C#; I've used it in Unity, and in Godot, it's not really hard to continue writing C# code. Also, why should I learn a new language when I already know C#? It is much easier for me to use C#, and that's what you said... it depends :D
And I do not like GDScript, even if it might have some handy shortcuts and stuff
At the end it is personal reference :) I have a better eye on overview in C#
Thank you for your video :)
Thanks for the heart :)
To be honest, Godot is performing quite well compared to Unity. Even though I had to work around a lot of things, it tries to keep things clear and structured. I'm happy about the situation with Unity :) It wouldn't even surprise me if they vanish within the next ten years. I don't think many will stay there after finishing their projects they are working on right now.
I'm glad they implemented C# into Godot ^^ so it doesn't feel that much different.
GDSCRIPT ITS is! thankyou was wrecking my head over this
I work with C# but I would suggest to use GDScript.
Why?
Cose C# will always be second class citizen and a bit clunky to use when comparing with GDScript.
Also, porting to console is probably much easier with GDScript.
GDscript it is.
Your videos keep improving. While it took you longer to make this one, the highlighting code turned out pretty nice.
*GDScript ;-)
And use types - it could be up to 2x the speed!
What about c++? What they don't support it?😢
C++ is used for modifying godot features, but out-of-the-box isn't used to program stuff within godot. Via GDExtension, C and C++ can be used as well though (officially supported) and community members have made other languages available with varying degrees of support
what about python?
GDscript is basically Python with built in features of GoDot 👍
@@vkmicrov GDScript is not compatible with python. You can't call a python library from gdscript, and you can't import gdscript in python. GDscript is pythonic but it's not python.
python is not officially supported by Godot, but there are some 3rd party projects that make various languages available.
In most cases I'd suggest to stick with the official options though, unless there's a good reason to use the module.
A lot of 3rd party stuff becomes discontinued after a while and I don't really like taking the extra risk
Like current Rust and an upcoming Swift bind, you would have to either find someone or maintain the langue binding yourself.
There isn't a larger demand currently for Godot APIs bound to Python right now. Since there's no advantage over GDScript unless you get compiled Python bound.
The main use cases would be calling on external Python bound code libraries, and most likely the underlying C++ binary. On Desktop, it's within Godot's APIs to ask the OS to run command line scripts, so you can build a Godot App that runs Python Scripts and then takes any results or files as needed.
GDScript doesn't use garbage collection, while C# often causes massive lag spikes due to its pause-the-world GC.
You are not allocating and freeing memory manually in GDScript, therefore it is 100% garbage collected. Not sure where the idea that it wasn't came from.
@@ForeverZer0 ruclips.net/video/tzt36EGKEZo/видео.html
@@ForeverZer0There are ways to have memory safety without garbage collection (Rust did it) but gdscript absolutely has a GC
@@CHURCHISAWESUM Well yeah, memory safety and garbage collection are mostly unrelated to each other. Memory safety isn't really a concept with scripting languages unless you are digging into the language used for the interpreter/runtime.
@@CHURCHISAWESUM GDscript garbage collection is very different from C# tho, GDscript is refcounted, refcounted garbage collectors usually don't suffer from pauses/lag spikes like C# does.
Go for c# if you can. gdscript is for programming noobs. If you know how to code, do it with a more known language. Don't lock yourself to a engine-only language. I speak for game devs. Or you can use both on spesific scenarios, why not. being type static is an important feature in game development in languages.