?? It supports Vulkan which is far newer...
Seems like such a poor choice.
GDScript is the most tightly integrated into the Godot editor, but there are tonnes of language bindings that work just as well and call into the C++ API just the same. C# is officially supported and they just ported it in Godot 4 to use .NET 6 instead of Mono. I've also used the Typescript/Javascript module from a 3rd party in the past and it surprised me how good the dev experience was. I'd wager that most devs who want to use their preferred language with it are also probably people who don't rely too much on GUI tools and won't miss the few features that gdscript gets from being directly inside the editor.
Why? It's performant for basic gamedev type things, has near zero call overhead, is integrated into the engine and it's incredibly easy to learn. It definitely beats Blueprints or something like Lua. And if you really want C# or something, it has that too.
I think that one of the aspects can be the fact that IDE support isn't quite there yet. Going to using Godot's built in text editor or to an external editor with GDScript plugin from something like JetBrains Rider with IntelliSense feels like a large step backwards.
Then again, many projects out there won't need advanced code analysis or refactoring capabilities, but personally I think that engines supporting C# (and JetBrains having plugins for Godot or Unity) is a great choice to give that additional flexibility to those that need it, as well as access to at least some of that already existing ecosystem with lots of libraries available. Oh, also, the docs having C# examples next to GDScript examples is great!
I don't see anyone writing a linear solver, or their own networking library in GDScript anytime soon, even though there have been some pretty great plugins for Godot in GDScript already, like the terrain plugin or the LOD plugin (which I ported to C#, link to my blog post is in another comment), both of which are portable and work pretty well.
That said, Lua is also great!
JetBrains is a billion dollar company that ONLY makes tools lol... Of course they have a leg up.
> I don't see anyone writing a linear solver, or their own networking library in GDScript anytime soon
Wrong tool for the job. That's why GDExtension exists. That's why C# is integrated. Also Godot already has ENet networking integrated into the engine.
GDScript is an alternative to something like Blueprints for basic behaviours that only call engine functions, not a full replacement for real programming languages.
Admittedly, that's a pretty blurry line and I'm not sure it's that easy to quantify what a "real" programming language is supposed to be, without moving the goal posts!
For most games out there, GDScript could indeed be all that's necessary and might be "real" enough to get things done and be a comfy experience.
For others, they are more than happy to bring their own IDE and the knowledge, as well as the ecosystem for their more advanced needs!
While having an extension mechanism for the engine is pretty cool (here's an article: https://godotengine.org/article/introducing-gd-extensions) sometimes you want things to be as easy as just adding a script in the editor and opening it in your IDE of choice.
I think it's pretty cool that Godot mostly caters to all parties here!
Fair enough. I mean, when I use Godot, I use GDSCript... I do like it. It's just not general purpose and I'm ok with that. It accomplishes what you need for most games. And GDExtension or C# are there when you need more...
Gdextensions are only for tight optimization or to embed something else, it's not really for anything else.
I wanted to make some game logic in C++ but it was not worth it. You must use godot allocator and .new() for everything...