GDScript is absolutely delightful, just give it a go.
People are always skeptical about it because they fear it is another thing to learn but it is very tailor made for Godot and for that reason you will pick it up in no time.
If you have worked with any scripting language, you will feel right at home. JS/TS would be a worse experience because that language is not designed for Godot.
Yup. I'm not a Python fan, and I have used C# in gamedev before, so I wasn't super thrilled about GDScript, but it is genuinely really good. And being custom made for Godot pays off in ways that I didn't think about fully when I was using c# in Unity or c++ for Unreal.
I tried it and eventually gave up and ported everything I was working on to C#. Not enough static typing and similar for me in GDScript, I like structure.
I know 4.0 is a bit better for that, though I'm not sure how much better.
I tried the static typing support in 3.x and it just wasn't nearly good enough. I really need being able to do shit like Array<Dictionary<Thing, OtherThing>>. And I want the static typing enforced automatically onto me, with compilation errors when I screw it up, not something I have to remember to label. Even with C#, there are still blank spots for this unfortunately, where the Godot standard library just passes you an untyped Array.
I know 4.0 has improvements here for GDScript, which is good to hear, but I'm quite comfortable in C#, coming from a background as a Java/Android dev.
What features does GDScript have that makes it fit Godot? I've been skeptical for the reason you mentioned but your comment might have convinced me that it's actually worth it.
GDScript is purpose-made for the task of being aware of how the engine wants to bind data. That is, its type system knows what the different components are, the events they can send, types of assets, etc. That makes it much smoother in terms of IDE support than using a general-purpose language - it helps you along with stuff like cueing an animation or audio event.
It's not really a language meant for lots of computation, but that isn't actually what most gameplay code needs: games are generally doing something based on a lookup table, finite state machine, or collisions. It only becomes a deep issue if you've got a lot of custom simulation going on.
I was in the camp formerly of "just use Lua/C#/JS/etc." for Godot as I didn't want them to reinvent the wheel. I've changed my mind on the matter after using it though. Or, through having a custom implementation, they've integrated it very tightly with Godot's node/refcounting memory model. Much in the same way UE's Blueprint execution feels similar to C++ logic, manipulating nodes and sending signals in GDScript ends up having a similar flow to something done lower-level in the engine.
I think it makes a tighter experience, and less maintenance work is done for bindings and transferring data to/from a separate heap/runtime for scripting.
IMO, their scripting language is pretty accessible to anyone with a bit of experience with programming and has nice syntactic sugar to integrate with the engine.
