[milliams]

There's an ongoing discussion at [1, 2] which highlights an important difference between GDNative and GDExtension in terms of what the developers expect them to be used for. A lot of people were using GDNative as a way of writing game logic in other programming languages (particularly I've seen this with Rust), but GDExtension seems to be designed to allow people to write editor plugins (e.g. things like a voxel node type, or a custom GUI tool). Each pligin currently seems to provide a custom Node in its own right, not the ability to hook into existing nodes.

This is why at the moment, you cannot live-reload a compiled GDExtension library, as the assumption is that it's a product that being provided to the user of the editor, not something which the game developer is directly creating.

I think there might be some mechanisms/hooks to allow this to work as wanted, but it has to work quite differently.

[1] https://github.com/godotengine/godot-proposals/issues/4437 [2] https://github.com/godotengine/godot/issues/66231

[iFire]

Faolan-Rad and I (fire) are working in that area https://github.com/godotengine/godot/pull/72883 "LibGodot is a system to allows Godot to be compiled as a library and connected into it using GDExtensions by giving a function pointer to the entry point of a GDExtension implementation"

[yalue]

Yes, I was in the first category of people, where I am using GDNative to ultimately call a single function written in Go, not due to speed, but simply in order to leverage a huge amount of code I had already written in that language. Judging by the GDExtension headers, I can probably pull off something similar if I forgo all of the C++ bindings that I don't need. However, I am hesitant to dedicate any time to doing so at the moment.

Don't get me wrong, GDExtension seems awesome, but it's also true that it doesn't seem geared towards the case that I was using GDNative for.