Move GDScript to GDExtension

[ValorZard]

Similar to what's happening with C# (https://github.com/raulsntos/godot-dotnet), this has been proposed by @vnen in the past so I'd figure I'd bring it up here

[ValorZard]

For my money, I think this is a really good idea. It makes GDExtension even more dogfooded (if that's even a word), and it would let GDScript be potentially decoupled from Godot leading to faster development. A lot of people's biggest issues with Godot is GDScript, so putting GDScript on the same playing field as something like the Rust bindings would go a long way to making that feeling go away.

[Delsin-Yu]

Architecturally, this is also preferable, as this migration reduced the number of binding layers the team needs to maintain, which is also one of the reasons why C# is migrating to GDExtension-based binding.

[Calinou]

I don't think moving GDScript to GDExtension would reduce the number of binding layers to maintain. The reason C# had its own binding layer previously is that its first implementation was developed in mid-2017, when GDNative was just starting to be a thing. GDNative wasn't ready to accomodate C# back then, so a custom binding solution had to be developed.

[Calinou]

I'm concerned this would add performance overhead for a scripting language. It's not like GDScript is too fast as it is right now. Remember that GDExtension has marshalling overhead that is not present when using GDScript directly (since it's a statically compiled C++ module right now).

This is the reason why most GDExtension bindings look pretty fast when they're doing isolated number crunching, but performance plummets to a level similar to GDScript (if not worse) if you don't pay attention to script/extension boundary marshalling.

[Delsin-Yu]

Then you should talk to Vnen, as the GDScript team member (leader?) He is considering decoupling the GDScript from the engine in next major version.
https://chat.godotengine.org/channel/gdscript?msg=mY9st8mGNyQtLZRfv

[vnen]

I think there might be a misunderstanding here. The plan is to GDScript to use the GDExtenion API for registering classes, instead of using the ScriptLanguage API as it does now. The GDScript implementation itself will still be a module and still part of the engine.

There is a goal of making GDExtension (with godot-cpp) be as close as a module as possible, in terms of coding, so they're mostly interchangeable. This would allow GDScript to be extracted to a GDExtension (it probably could already, without breaking changes), but there's very little reason to do so. It's an unneeded complication.

[Delsin-Yu]

Thanks for clarifying. I wasn't aware that modules can utilize the GDExtension API directly.

[kisg]

FYI an older similar proposal from us: #7950