It's like you believe GDScript is the only language for which any of these features are possible. Other languages are also easy to write, learn and teach. Integration with the client is an implementation, not language, issue. Support is a business issue. Debugger quality is orthogonal, and you can make a game in assembly if you want (Railroad Tycoon.)

Those are your words, not mine. The thread was talking about ditching GDScript in favour of C# and comparing it to other engine scripting languages. You want to go with the conversation on a trip to the mountains, you go alone.

You're being weirdly aggressive here, and you have yet to actually address any specific point I've made in any of my comments, much less defended your own, so I'm going to call it a night.

You've been just as weirdly hostile from the jump.

>its library pretty much covers what you need to make your average indie game

Hey, if GDScript could run my idea for a 3D Open hub Action RPG at 60fps with little concerns for performance, I'd have no issue.

But alas, my desire for a proper binding or directly tapping into the c++ comes out of necessity, not some pride as a "real game developer". It's not impossible for GDScript to one day become the WebASM of Godot, but we both know that WebASM was, and still is, decades in the making. I imagine it's simply faster to forge a fast path API and let the slow path work for non-performance intensive games.