The obvious additional good from this approach is that you no longer couple everything so tightly with just one scripting language, so in some ways it's a bit easier to introduce bindings for other languages. The downside, however, is that it leads to fragmentation in the community, duplication of effort (suddenly you need the double amount of docs), more difficulty and friction in development with new mechanisms demanding that you take the limitations of both languages in mind, oh and if you dare to write your own language then suddenly you have to support both it, as well as any dev tools for it. For what was and still is a communtiy project without strong financial backing (just look at how much money Unity burns on useless stuff, and how much more the people behind Godot could do with that money), that's quite the gamble.
Maybe if they focused on the core engine more, then deltaV: Rings of Saturn wouldn't have odd performance issues for a 2D game and wouldn't get confused with multi-monitor setups. Maybe Road To Vostok wouldn't crash when loading into the Village map on an Intel Arc GPU, and also start on the wrong monitor same as deltaV. Maybe even demos like "Realistic Jungle Demo" on itch.io wouldn't have all white textures on said Intel Arc GPU. Maybe we'd be two or three whole releases of features ahead by now, if all of the hours spent on GDScript to date would have been spent elsewhere.
On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected. Similarly, if they didn't try with GDScript, the community would be smaller, due to its ease of prototyping, and being simpler and more approachable for the folks who don't know C# yet, even if it's also unnecessary to the folks who like tools like Rider/Visual Studio or are coming from Unity or engines with scripting in C# or just C++. I'm pretty split on it overall.
> Or maybe without GDScript the engine would not get the traction it has and would not have the resources to do anything at all.
Or the developers might not find C# to be as interesting to work on and some people that stick around in part due to getting to iterate on GDScript wouldn’t contribute at all! All of those are possibilities, that’s for sure, Godot definitely has a lot of appeal due to fast prototyping too!
> Intel Arc GPU rendering issues have nothing to do with Godot’s choice of high-level scripting language.
The GitHub repo for Godot has 83'164 commits. Let me pull an arbitrary unimportant number out of my ass, which is 6 hours of work per commit on average (lots of small ones, some that take weeks, doesn't matter) and we get 498'984 hours which we can round to 500k for our napkin maths.
There's around 52k LoC for the gdscript module, about 1'380 files. Around 5% of the overall commits in the repo are in that module, we can up that to like 7% to account for docs and editor and other parts, but we don't have to assume higher. That gives us about 35k hours spent on GDScript.
Remove GDScript and you get 35k hours to put elsewhere, including Intel Arc support. It's the exact same principle of Linux distros having like a dozen desktop environments and the efforts being so fragmented that it's impossible to make a single really good one (though there are different goals for the projects, for example KDE vs something lightweight like LXQt).
Of course, I addressed the possibility that people working on GDScript just wouldn't be able to work on the other stuff, so one should argue that redistributing work would be quite complex and since it's a lot of volunteer work, people might just not care to work on X instead of Y, that was addressed here:
> On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected.
That said, the above is more or less why Unity benefitted in regards to development velocity from saying goodbye to ECMAScript and Boo (or maybe they shot themselves in the foot, cause prototyping is slower compared to GDScript).
They do have a pretty nice page talking a bit more about GDScript: https://docs.godotengine.org/en/stable/about/faq.html#what-i...
The obvious additional good from this approach is that you no longer couple everything so tightly with just one scripting language, so in some ways it's a bit easier to introduce bindings for other languages. The downside, however, is that it leads to fragmentation in the community, duplication of effort (suddenly you need the double amount of docs), more difficulty and friction in development with new mechanisms demanding that you take the limitations of both languages in mind, oh and if you dare to write your own language then suddenly you have to support both it, as well as any dev tools for it. For what was and still is a communtiy project without strong financial backing (just look at how much money Unity burns on useless stuff, and how much more the people behind Godot could do with that money), that's quite the gamble.
Maybe if they focused on the core engine more, then deltaV: Rings of Saturn wouldn't have odd performance issues for a 2D game and wouldn't get confused with multi-monitor setups. Maybe Road To Vostok wouldn't crash when loading into the Village map on an Intel Arc GPU, and also start on the wrong monitor same as deltaV. Maybe even demos like "Realistic Jungle Demo" on itch.io wouldn't have all white textures on said Intel Arc GPU. Maybe we'd be two or three whole releases of features ahead by now, if all of the hours spent on GDScript to date would have been spent elsewhere.
On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected. Similarly, if they didn't try with GDScript, the community would be smaller, due to its ease of prototyping, and being simpler and more approachable for the folks who don't know C# yet, even if it's also unnecessary to the folks who like tools like Rider/Visual Studio or are coming from Unity or engines with scripting in C# or just C++. I'm pretty split on it overall.