Godot has always had native module support; the reason it is not more popular is because it is more or less impossible to support a stable C++ ABI across compilers and operating systems. So you have to build Godot yourself for your dev platform and every platform you ship to. That is what GDExtension and the official C++ bindings solve. Once you set up your builds native modules are totally decent, but personally I find it saps productivity compared to GDScsript, and if you only need it for performance critical code then GDExtension is probably fine (I haven’t used it or GDNative, but I did write native modules before those other options existed).
In my experience, most devs dislike working in C++. (I'm an industry engineer in games. Even the people who like C++ hate C++.)
Maintaining C++ support is expensive for an engine, just like maintaining any language binding. IMO, they should optimize for the most approachable/developer ergonomic language, which C++ definitely is not.
That said, I strongly disagree with their decision to simply build their own language. I think there are many languages that already exist that make better candidates for game development either because they are well known, well supported, or easily portable.
GDScript is basically Python syntax with some sugar.
* Well known: Python is well known. GDScript is thus familiar.
* Well supported: it's a first class citizen in Godot, that's all that matters
* Easily portable: portable to what? it runs on the Godot engine. That's all the portability it needs.
I think they built their own language because of the integration with their Editor. It's not Lua or JavaScript or Python, but it works well enough for Godot in my experience.
I don't doubt that I can learn it. Learning a language is pretty easy.
I doubt that I'll have rich tooling and libraries to draw from when I need them.
If I build a game in C#, for instance, I have editors that can lint my code, perform intellisense, automate test generation, and a rich set of libraries I can draw from. If I don't want to write my own Hierarchical Task Network planner, I can use FluidHTN. Likewise, I can pull out my code from my project and modularize it for other engines/games -- maybe I've got a great state machine implementation or something I want to share. GDScript limits my reach.
The knowledge is also not particularly useful outside of working with Godot. Picking up C# from working with Unity, for example, translates to other domains easily if I want to change careers.
I also can't write my backends and supporting services in GDScript. If I wanted to , I could make my entire codebase in C# for both front end and back end code, simplifying my tooling and knowledge needs.
I don't want to be too down on it. I'm sure there are ways that it would save time. My use cases are much more about setting a high bar for ergonomics and engineering excellence for larger projects. I think that in my case, they've provided the Extensions and C# support route. (Though it sounds like getting those to work on all platforms is non-trivial today.)
>I also can't write my backends and supporting services in GDScript.
I mean technically you can. Godot has a headless mode for servers, etc. I certainly wouldn't pick it as my first choice for all the other reasons you listed though.
In my case the main issue with GDScript is the tooling, or lack of thereof. No symbol aware rename, no go to definition/usages, poor autocomplete, cryptic errors. Also static typing that's kinda but not entirely there, which exacerbates the tooling issues.
Good tooling is an enormous undertaking, so the way I see it, GDScript is forever doomed to feel like someone's impressive hobby project.
Not the OP but I can pitch in that, for me, it is important (and I'd add: efficient) to invest my scarce time in a language that can be used in several contexts
e.g.: Using python, I can do games, scientific/bio work, math, web backends etc. The same time investment in GDScript will only net me experience with GDScript which right now only exists in Godot.
From my experience it's a lot easier to learn another language than to learn a new model of operation or new concepts entirely. And if you'll want to work with Godot, that will likely be the main barrier, and the main thing that will not be transferable to other contexts. The language however, can only make working with the concepts easier or harder. Godot team has decided that having their own language designed for dealing with the concepts of the engine makes it easier to use and results in less work than trying to adapt some existing language to the concepts of the engine. I've dealt with this a couple times, where a language was transformed so much by the context it was used in, it felt like an entirely different language.
On your last point, even just a language like JavaScript (or even Java) has, over long enough periods of time, evolved to accumulate enough new features and common idioms that if you look at typical code from the 90s vs now in those languages, it's not hard to picture entirely different languages. And engineers are expected to just learn the new changes and keep on, much as they're expected to just learn algorithms, libraries, test frameworks, other domain specific frameworks that come and go, database stuff, profiling and other monitoring methods, security concerns, how not to violate the GDPR, ....
But suggest a different language or a DSL for something, no matter how much sense it makes (sometimes getting simple SQL in places is a political struggle, and it's unfortunate when teams develop a "regex expert" even though all the regexes are simple), even one that is already super similar to one they already know like GDScript and so is rather trivial to learn (no one's asking you to learn something on the order of complexity and different-to-others like Haskell here), and devs start putting their foot down and saying "Of all the things, I"m not learning that!"
It's a toy language with almost zero open source library support. And trying to hire someone to work in it and implicitly agree that they don't care about their CV and future hireability is a tough sell.
I've no horse in this race, but want to point out that a lot of the criticism here seems to be from folks who haven't actually worked with GDScript, whether in a production, or even at all.
It's likely due to being cross platform. What's happening is they're bundling the scripts and assets with a pre-built binary. If you're writing all c++ you're likely going to link in the engine instead, not the paradigm they support. That said I know you can extend the game engine, and there is some kind of plugin support for building native code, but you've got to do compile time support yourself? It even supports Rust now apparently?
It is inasmuch as you can modify the engine source if you would like to program your game like that. Most engines maintain a distinction between the engine implementation language (usually C++) and scripting (game implementation) language, and Godot is no different.
It has at the same level as Unreal, via extensions.
Turns out most people doing the actual scripting don't use C or C++, rather tooling designed for game designers, level editors, scripting developers,....
Professional studios rarelly do everything in C++ for the last 20 years.