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.
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.
(not that that should be an issue due to python being able to directly output C code, but you understand the point).
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.
That said, how prevalent is the former vs the later really?
