I was wondering what you would recommend using in Godot?
Is it worth learning GDScript for some additional functionality?
Should I stick with my trained knowledge of C# despite less features?
What are some pros and cons of using one over the other?
I have a similar amount of programming experience, though not primarily with C#. I’ve worked a little bit with C# before starting to use Godot, but I’ve worked extensively with a very broad range of languages. Assembly languages, C and C++, Bash, Python, Lua, JavaScript and TypeScript, and a lot more. Now, I’ve been working with Godot for the better part of a year, on-and-off but more on than off, in both GDScript and C#. There’s a whole impassioned debate happening in this post but I will attempt to answer the question more impartially and more exhaustively than most others will be able to do.
GDScript has one strength: So far, it has received closer attention to integrate it cleanly with the editor and engine than any other language.
GDScript has numerous weaknesses.
GDScript has no functional static typing system. There are type annotations and there is some static analysis functionality to check type correctness, but it is so incomplete and dysfunctional that you almost might as well not bother. Not having static types is not a big deal for smaller projects. If you are working on something more ambitious, especially if you are working in a team with others, the lack of mature static analysis tools will be extremely painful. (I know this from professional experience. It’s the same reason why TypeScript is increasingly replacing JavaScript in professional settings.)
GDScript is fundamentally object-oriented, and yet its tools for OOP are very incomplete. There are no generics and no interfaces. There is also no multiple inheritance. It’s all the drawbacks of Python’s convoluted, footgun-prone duck-typed classes, but without the same benefits.
GDScript’s error handling tools are nearly nonexistent. There are no thrown or caught exceptions. Functions cannot return multiple values, nor tuples, not unless you want to allocate an untyped array for it. Functions cannot receive arguments by reference, and there is no equivalent to an out parameter as in C#. There are no Optional or Result types, and no particularly good options for defining your own. If you have a function that needs to be able to both return a result and indicate error/success, beyond just returning null on failure or such, then you have no good options. If you need to propagate an error up the call stack, you have no good options.
GDScript lacks basic tools for writing performant and efficient code. There are no user-defined packed or pass-by-value types (i.e. structs). There are no user-defined iterators, there are no generators, there is no GDScript equivalent to the C# IEnumerable interface, and in general if you are working with lists of things you are just going to be using fully in-memory arrays.
GDScript generally lacks basic usability and quality-of-life features. And amid all of this, there is not even a preprocessor to try to work around some of it, i.e. no defines and no macros. Not without brewing up your own preprocessor, which will have no editor integration and won’t work with Godot’s LSP.
GDScript has no package ecosystem. It has no easy way to integrate with packages written in any other language. Though there are addons out there you can use, there are a lot of usability issues with that and not a lot of people are publishing them. If you need something that isn’t a built-in part of the engine, then you are probably writing it yourself from scratch. This is not the case with C# for Godot, with which you can use any NuGet package.
(For me, though, the final straw that had me fully give up on GDScript was when I started having to restart the editor for it to wake up and stop reporting nonsense errors. I would add a new method or property in one file and then Godot believed the new method/property name was nonexistent when trying to refer to it in other files, until I restarted the editor. I am not sure what caused this. What I do know is that it fully wore away the last of my patience for GDScript, despite the editor integration benefits.)
Those who praise GDScript are those who don’t know what they’re missing out on, which is a lot. I would estimate that GDScript is at least ten more years from being the right option for serious projects, at the current pace of development.
Godot’s C# support does have some small gaps. The gap I’m most looking forward to seeing fixed is that documenting comments in C# on exported properties cannot be shown as tooltips in the editor’s inspector, as they can with GDScript. But overall C# will give you a far better experience with Godot than GDScript, and you can always mix in a little GDScript if you want to. The only exception would be if you are working on a project so small that GDScript’s issues might not catch up with you, or if you were inexperienced enough that a more robust and professional language like C# would feel more intimidating than helpful.
.
