[MapsSlaps]

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.

[optymizer]

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.

[detrites]

Do you have any specific criticisms of GDScript you'd like to share?

[MapsSlaps]

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.)

[j_4]

Not GP but I'm a full time solo indie dev.

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.

[fb03]

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.

[hesdeadjim]

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.

[detrites]

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.

[jay_kyburz]

OMG cyclic dependency hell for a start.