It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.
I understand it. it was built a certain way to support ease of use above almost anything else.
That ease of use is important, but also may be holding back Godot's true 3d capabilities. From a cursory glance as someone wanting to work on a decent scale 3D game, I'd need to treat GDSCript as I do Unreal's Blueprints as of now: miniize use only to high level scripting and maybe UI/Shader code. That's not me saying that GDScript nor blueprints is bad, just that it gets in the way of my specific use case.
If I can help speed up the engine underneath as a whole in the process: wonderful. I don't necessarily want to disrupt GDScript for my convenience either, but like any refactor some breakage is inevitable.
For some, a few days of GDScript usage. For others, after they convert their bottlenecks into C++.
UE’s blueprints are much(!) slower than native code, but they’re still an incredible tool in the toolbox. GDScript is kind of the same; it’s covering a critical role of non-performance-sensitive glue.
That said, I’d really like to see Value Types added, as well as these sorts of heap allocations addressed in Godot 4 at some point.
It’s not about spending time, it’s about being ignorant of GDScript’s use cases. It’s like if people went into Python communities and shat all over it because C is faster. It’s true, but it misses the point that iterating in Python is leagues faster and is fast enough for a large section of projects.
If C bindings were slow because the underlying code was made to bridge with Python bindings, I would complain too, to be fair. Doesn't mean removing Python support is the perfect solution, but at some point that performance hurts everyone.
(not that that should be an issue due to python being able to directly output C code, but you understand the point).
I guess the argument is that GDScript has a different use case than Unity's C#? Seems like Unity devs know what a C# scripting engine is like and feel it covers the use case fine. To say they don't understand the use case would mean it must be different somehow. Can you go into that?
So are we fine keeping it that way and not addressing core performance issues because it's convinent for making simple 2D games?
To be honest, I'm surprised how dismissive parts of the gamedev community can be about improving performance of their game engine. That was a huge complaint from Unity and you'd think people would be interested in not repeating those mistakes with Godot.
