It was a little of both, but it's not really a valid complaint any more. When Godot first open sourced, it didn't have features like culling meshes that the player couldn't see, and the lighting implementation was pretty basic. The default language in the engine is basically python, so it could cause a performance bottleneck. Now it has a lot of the 3D performance features it was missing, and it has first-class C# support if the default language is causing a bottleneck.
I tried Godot again like ~8 months ago and the C# support was still awful to the point that I'd consider 'first-class C# support' an outright lie. It might be 'officially supported', but it's in 'late alpha' since 2018 and is very obviously a second-class citizen, which should be clear just from the bad state of the C# docs. Community resources for C# are also much more sparse (subpar support probably contributes to this).
It doesn't seem like they've made much progress in Godot 3.3 - seems like a grant ran out so they had to let their C# dev go, so I don't expect any major changes for the foreseeable future.
Keep in mind that I'm obviously quite soured by the experienced - Godot might still be the right choice for anyone who is considering. I'd just recommend anyone to factor the very rough C# support into their choice, especially for anyone planning to use it for a more involved project.
I've been using C# in Godot for all of my latest projects of the last ~year and have had absolutely no issues at all. Most of the docs these days have a "GDScript/C#" tab selection, and the intellisense support is so good that I rarely even have to check.
Now, I did already know the Godot API quite well when I started using C# so that contributes. But I haven't found it to be a second-class citizen at all, and in fact allows me to use features that I wouldn't have been able to in GDScript (native event handling, offloading to native data structures for computation rather than using the Godot API for them, nuget packages, and so on). I can also use eg Jetbrains DotTrace to profile code in much more detail than GDScript, and edit and launch my game code from an IDE without ever opening the editor.
You can also opt to use the dotnet-core compiler instead of the bundled Mono one these days which allows you to use some more modern features.
The only clunky thing I've found is that trying to use a native C# data type in a Godot Node object causes marshalling errors, but I'm pretty sure that would apply to nearly any Mono game engine and that Unity has similar issues (having to wrap things in MonoBehaviours etc- it's been a while so this may be inaccurate). The simple workaround is just to use the Godot API for things that are in the scene tree, and native types when you need to compute stuff with better performance.
I'm curious as to what actually felt rough to you in C#?
Yeah, no idea why C# was introduced other than to appeal to people with zero game dev experience who might be lured in by thinking their knowledge of C# is going to matter.
Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.
> Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.
You're going to have to know that stuff for any game engine that isn't just a pure C# framework. Unity is no exception afaik, you have to use the Unity API Job system to be able to run threads safely. I use async/await in Godot C# all the time. Threading requires using the Godot API, sure, that's natural, since threading can be a mess in video games.
"It uses a syntax similar to Python (blocks are indent-based and many keywords are similar)."
And[1]:
"If you've ever written anything in a language like Python before then you'll feel right at home."
So it's more than just whitespace.
I seem to recall it being acknowledged that Python was a big influence on GDScript's design and in a number of cases "How does Python handle this?" drove some of the design decisions.
You are not wrong, but the original point was that GDScript is slow because its syntax is similar to Python's and Python is slow. That just doesn't make any sense.
> The default language in the engine is basically python, so it could cause a performance bottleneck.
python is slow because the extreme flexibility of the language makes it very difficult for compilers/interpreters to perform analysis that could allow optimisations
this doesn't have anything to do with the syntax. we could completely replace python syntax with e.g. pyc bytecode or serialised AST data but the language would still be challenging to execute efficiently as the language is still exactly the same
one can get a few ideas of how python could perhaps be made faster by reading about all the restrictions that rpython imposes
But why did they chose to invent GDScript and not chose to use/embed python itself?
Using a newly invented special purpose language is something that often discourages me from considering a tool/framework.
