Should I choose GDScript or C#

Help
, ,
22

There is no such thing as an adult language, a programming language is just a tool, to put into work your abstract knowledge of programming. Every language is unique and has a goal for which it was created in a way it is. One need to learn computer science, engineering etc. The programming language is just a brush which you use to paint

1 Like
23

It is more adult for me :slight_smile:
obraz
C# is 23 year old and still in active development

1 Like
24

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.

2 Likes
25

Yes, in my opinion you have even more features in C#.
When I came over from Unity to Godot last year, I was a bit shocked how many things can be done entirely in C# without the need for the actual engine. In Unity most things were hidden on the proprietary C++ side. In Godot you have the unmodified .NET runtime next to the engine itself.

I can’t compliment the Godot 4 developers enough for this decision, as this allows you to use everything from the .NET ecosystem. This also includes IDEs like VisualStudio and Rider and their profiling tools.

There also is the performance aspect when going full C#. It’s a lot faster than GDScript itself already, and on top of that you can use SIMD datatypes from the .NET runtime without any extra work. (System.Numerics). Godot itself doesn’t have SIMD yet, making C# a lot faster than C++/GDExtension for all kind of vector operations at the moment.

The slowest C# part still is the interaction with the engine itself, which can be worked around by creating your own engine module in C++ to optimize any data transfers between Godot and the .NET runtime. (The C++/C# glue code is easily auto-generated, but I think that goes a bit too far now…)

Of course you won’t even need that if you do as many things as possible in C#. Here are some examples for things I’ve implemented in C# over the last year instead of relying on the engine:

  • File access (using System.IO)
  • Resource loading & savegame serialization
  • TCP networking (async + multithreaded)
  • Physics (BepuPhysicsV2)

Anyways, if you really have that much C# experience: use it. You’ve found the perfect game engine for it.

3 Likes
26

I prefer c# because it also means using Visual Studio.

However, using .Net means no Web export.

Thus, I use gdscript and VSCode both of which are good enough.

27

is should change with new .Net this year

2 Likes
28

That would be great. Visual Studio is a far superior development environment.

2 Likes
29

Alright. Thank you all for the very insightfull and informative posts regarding the two languages. The more I read the more I relize that C# really has more features than GDS.
I definitely want to make use of such features as interfaces and generic types.
Visual studio is what I use for my IDE, and it definitely has more features than Godots built in editor.
This, other things, and my previous experience have lead me to choosing C# over GDS. I have been made aware of certain caviots and performance hits you can take from the C# documentation, but just so long as I am being made aware I can easily work around them.

I would like to to thank everyone once again for their amazing posts, and will continue on my Godot adventures mainly using C#.