Is Godot Gradually Adopting C# as Its Primary Programming Language?

Hello fellow Godot enthusiasts,

I’ve been pondering a question that’s been on my mind lately: Is Godot moving towards adopting C# as its primary programming language? With the growing popularity and versatility of C#, I’m curious to know if the Godot community and developers are leaning more towards this robust language.

We all know that Godot currently supports multiple programming languages, including GDScript, which is great for its simplicity and ease of use. However, C# offers a powerful set of features and a vast ecosystem that could potentially enhance the development experience on the Godot platform.

I’m interested in hearing thoughts from the community:

  • Do you see a shift towards C# in the Godot ecosystem?
  • What are the advantages or disadvantages of using C# as the main language for Godot development?
  • How do you think this could impact the future of Godot game development?

Looking forward to a lively discussion and insights from everyone!

Best regards

2024.5.24 Edit:
Additional conditions
“Initially, Unity employed its proprietary scripting language, Mono, but transitioned to C# as its primary programming language. This strategic shift has yielded numerous advantages, such as broadening its developer base, enriching the available libraries and frameworks, and fostering a closer integration with Microsoft.”

2 Likes

Unlikely, this has been shot down many times by the Godot devs if you read the GitHub issues, so unless they leave the project and gdscript unprotected, it is here to stay.

Is it growing? I can’t accept this claim. I don’t see more or less people using either c# or gdscript in the forums. I think there may be a bigger community of migrating unity/c# users. They don’t use C# because it’s better, most likely they are comfortable with it and don’t want to change. There are also many compatibility issues currently with C#. It’s getting better, but I read it still gives them heartache.

10 Likes

Personally, I never cared for c# – it’s just a slightly more proprietary java, as far as I’m concerned. GDscript isn’t burdened with a garbage collector or massive additional libraries, and GDscript is much more fun to program in.

People have cited c#'s speed before, but most of the heavy lifting in any project is done by lower-level code in the engine, so c# isn’t as much of an advantage as it might seem. It’s really more of a personal preference.

However, godot won’t be developed by the same people forever, so I predict that c# will win… eventually… unless everyone switches to the next popular language first. I doubt it will happen for several years, so I’m content.

6 Likes

Seems like a zero-chance of that happening with how many extra hoops must be jumped through for C#. Plus it’s a largely proprietary language. As a totally custom language GDScript can be tightly bound to the engine in a way C# would not.

6 Likes

Godot’s c# support gets the job done. That is good enough for me. What ever shortcomings there are, if you know what you are doing, creating a workaround in c# isn’t that difficult.

gdscript will never be at the same level as c#. But it doesn’t matter.

Someone else might know for sure, but if Godot re-implements web browser support, I don’t know if c# will be supported.

In general, gdscript support is #1 priority. Also more people here know gdscript. So if you get stuck with gdscript, someone here will probably help you.

What I really do appreciate is gdscript is a full-featured scripting language. Adding gdscript support in c# easy. So I can write everything in c# while allowing people to write their own gdscript add-ons.

EDIT: my observation is between major releases small improvements are made to gdscript that might break existing scripts. Requiring they be updated.

2 Likes

Urrr… That’s an advantage? :wink:

4 Likes

Not MS, but .NET.
If we build a simple game, gds is quick and agile.
But with community, dot-net is older and strength.

1 Like

A bit, probably because of the Unity users coming over.

The biggest advantages are:

  • Full access to the .NET ecosystem, its cutting-edge features and industry standards
  • IDEs with auto-complete, refactoring, debugging tools, memory viewer, performance analysis and so much more
  • Performance very close (or equal) to native C++ code
  • NativeAOT support (direct P/Invoke calls, faster startup times, no runtime shipping needed, increased security, …)

The biggest disadvantages:

  • external IDE required
  • harder to understand for beginners
  • complicated cross-platform setup
  • very hard to master, especially the advanced techniques

Hopefully more (professional) Godot games will use C# in the future. The games I played and know to be using GDScript all have one thing in common: bad performance once too much is going on. (Brotato, Wrought Flesh, Halls of Torment)

Sadly there are still many misconceptions and false assumptions about C# everywhere on the internet. Most people simply don’t know better and don’t really care. Just look at the answers in this thread…

Microsoft made the .NET development open source many years ago. The whole runtime is under MIT license. The Mono runtime also still exists (and is implemented in Godot 3.X).

The GC is actually a good thing in most cases, but can be bypassed if desired. Manual memory management and stack allocations are optional and very, very fast when used correctly.

All that stuff is trimmed with NativeAOT in release builds. It’s all compiled down to native machine code. The end user won’t need the .NET runtime and the exported game only contains the code that’s actually used. Everything else is removed during compilation, unless explicitly configured to stay in.
Godot itself (the release templates) and GDScript can’t do this on their own and contain way more useless bloat in exported builds.

Anything you do in GDScript is up to 20 times slower compared to the C# equivalent. This adds up very quickly in any somewhat complex game and is completely wasted performance.
The good thing about C# with NativeAOT is that you can get rid of expensive managed<->native calls, making it similar to Unity with the IL2CPP backend. This makes your C# code run as fast as C++ GDExtension code in the end.

Sadly most C# stuff is still very badly documented, or not documented at all. Not only in Godot, but also in the .NET runtime itself. Also more advanced C# techniques (such as using ref structs, SIMD, direct P/Invoke calls, stack allocations or preallocated heap memory) are still uncommon and sometimes hard to learn, yet they offer exceptional performance benefits for games.

In the end I’d also like to mention that I’d be using Unigine or Flax by now if Godot wasn’t the first to implement NativeAOT support in 4.0. They have a real advantage here, as C# in Godot is a lot better than in Unity already. Most people just don’t know about it I assume, as it took me some source code digging as well to find out how exactly the .NET runtime was implemented into/next to the engine.

7 Likes

You make some good points.

That is true… now. Java and c# are both open, but c# started out as microsoft’s baby, and that’s where it spent its formative years. I’m not convinced that they’ve ever really let it go.

Good to know. Shame the garbage collector is still the easier option. I’ve had games bog down during garbage collection – it sucks.

…which is all most godot developers are going to be concerned with, though the theoretical benefits are nice.

That all depends on what you’re doing. Usually you need performance if you’re doing things you should be using the engine for. I haven’t seen any godot games that needed to work that way, but maybe I missed them.

I’d like to see recent, relevant benchmarks for c# vs gdscript. The last time I tried comparing, it was more like four times faster, not twenty, but that’s still good.

2 Likes

As an individual, I choose to use C# to create video games, and I have no intention of publishing games for the web, so it’s not a significant concern for me in the context of Godot.

On a personal level, I adopt the use of C# to create games in my spare time, and I intend to continue doing so until I eventually create something of high quality and potentially make a living from it.

It’s a fact that most people start out on their own and making a living as an indie is quite challenging. There are thousands of C# job opportunities, whereas GDScript job opportunities are virtually non-existent.

I can work in the industry with C# and continue using it to create games in my spare time and I can improve in parallel both in my daily work and in the development of videogames.

Some argue that using an external editor is a disadvantage, but nothing compares to the development experience with a robust IDE like Visual Studio or Rider for working with C# or C++. If you’re using two monitors, it’s not a disadvantage.

When prototyping a small video game or working as an indie, GDScript is undoubtedly faster to achieve the desired result. However, I wouldn’t use it for team work, as a more robust language like C# has a standard way of working and scales well for multiple developers working on the same project.

As a programmer, I believe that using statically typed languages like C# helps you gain a more robust understanding of software design.

6 Likes

I really hope not…
If it will, at least I beg Godot developers to mantain nonetheless support for GDScript as second choice language, for those like me who hate C# and its awful sintax :face_vomiting:

1 Like

Honestly I’ve always thought of C# support as just being there to make it easier for Unity devs to transition. From my perspective it adds extra installation steps and bloat for no practical benefit - the performance difference would only matter if game logic processing were actually the bottleneck, and even if some day I work on a project where that’s the case, using C++ with GDExtension is going to be the most performant. I’m glad the option is there for people who want to use it, but to me C# is in this awkward middle ground that’s clunkier than gdscript and slower than C++, and it’s hard for me to imagine ever having a use for it in my projects.

5 Likes

I hope not. GDScript is great for productivity.

I write everything in GDScript first, then for things that will do better in C# I will abstract it out, and refactor in C#.

What’s C# better at than GDScript in Godot?

For pretty much everything else? Stick with GDScript

3 Likes

I would love to see that would make for some interesting reading.

1 Like

I have to ask, but what are your experiences with the language and the platform behind (I myself working with C# at least four hours every single working day since Version 2.0 at 2005). Imho in real time application the GC is actually a bad thing in most cases and it can NOT be bypassed, even if desired. “Used correctly” means micro management of the language for every string, List, Stream, means management of every single visible and every single hidden allocation, means not using the cool features like linq, string interpolation, params, etc.

To make it clear, I like the C# language very, very much … it is in my opinion one of the best languages ever developed (syntax wise) and it is still excellent developed (no wonder, it’s the baby of one of the best compiler designer and programmer of our time … Anders Hejlsberg). And the GC … makes it so easy to use and fast to prototype … it is okay for web services, for Windows Forms/WPF Desktop Applications, for business applications, for controlling, ai and most every-day-used tools. But not for time critical apps … and not for games (escpecially FPS and other games which needs stable frame rates) … except you do not use most of the features, do not use most of the libraries and use many rules to verify no hidden allocation and to handle used allocations … but that would be the same as working with hands and feet bound together.

Just my two cents.

3 Likes

In my opinion working with both languages I have to say that with GDScript one can prototype much faster and there is less boilerplate. But I would never go for a bigger project in GDScript over C#. C# provides so many tools for code safety and reliability. GDScript is great for prototypes and small projects but I think one of the reasons why not many big games have been written in the engine is because GDScript is not great for big games and C# support is slow to come by.

1 Like

From what I gather C# is poised to become sort of official “reference implementation” on how to add support for additional languages to Godot. Also instead of C# being alternative to GDScript it’s actually thought as easier alternative to C++ .

The proposed solution is to move C# support to the new extension system in Godot 4.0.
This will give C# in Godot effective first class support at the same level C++ has, bringing the following features:

  • The entirety of the C# glue layer (currently done via C++ .net hosting API) will be majorly replaced by GDExtension, using the extension interface common to all binding languages (GodotCPP, Rust, etc). The modules/mono folder will be removed from the codebase and likely replaced by only by a tiny boostrapper to load the .net runtime on demand if installed in the project.
  • Because the entirety of the C# support will use the shared extension system (GDExtension), a single, unified version of Godot and the export templates will be possible.
  • Some of the C# API, including the native Godot collections, will be changed for more efficiency

The main idea is that C# should act as if it was a C++ extension. A library
(in the shape of a .net DLL), probably GodotLibrary.dll, can be added to
a project and this automatically is recognized and opened by Godot as if
it was a native shared object, but done actually via the .NET runtime.

In other words, if the C# runtime is installed in the Godot project (or
supplied by the platform to Godot), it is used to open GodotLibrary.dll
and call an entry point that should be the same as a regular GDExtension,
Juan Linietsky

Source:

Personally I think it’s great idea, especially since you can do a lot of stuff through C++ and GDExtensions that isn’t possible with GDScript and C# at the moment.

2 Likes

Please no

I hope not

3 Likes

i personally hope not

hi this is i believe my first post on this board
i’d like to express my appreciation for both gdscript and the godot shading language. thanks to all who contributed to its design and development :pray:

ive been using godot for only a few months, having some experience with unity before and with c#. it’s been an absolutely fantastic experience so far and i wouldnt go back to unity if they offered me a solid gold bar

honestly, i really dont like c# but that’s just me. it’s great for its open source and general purpose nature, and is obviously very powerful, but i feel it’s hard for someone like me who is not terribly interested in tech and programming, to keep up with the constant additions and changes to c#. it’s like there are always ten plus different ways to do the same thing with some ways better than the others and having to figure out what’s best is honestly annoying.

i honestly think c# is not unlike c++ in that sense. i think it’s a bloated and terribly complex language, despite being advertised as easy and beginner friendly. granted c# was my first ever programming language so i had to learn a lot of general programming concepts at that point, which added to the difficulty, but even considering that i personally would not advise c# to newcomers at all

ive tried a few other languages over the years. honestly gdscript is probably the easiest language out there and with godot i can easily make gui apps as well as games for family/friends for their birthdays ^^. before, making gui apps felt so difficult with all these frameworks (.NET MAUI for instance, anyone?). with godot it’s a breeze, it almost feels like cheating. i can make these amazing apps with almost no work.

i cannot imagine spending time learning GLSL either. godot shading language makes things so easy.

i dont know about you but for me gdscript and the engine’s shading language are both very easy to learn while still being very powerful. you can already so much with these languages. it feels like the designers of these languages had exactly people like me in mind, who dont mind writing code, but arent huge tech people either. like i said, im not a big programmer guy but gdscript makes writing programs so much fun (yes i know it’s more a scripting language but you get me point i hope)

3 Likes

the design philosophy of Godot is that it “just works”, so defaulting to a language like C# — which does not always “just work” — would clash.

Godot will keep having GDScript as its default language because it’s designed to “just work” in Godot.

using the C languages can make the game run faster but it’s much harder to typewrite the code and it takes at least thrice longer to typewrite the code.
for this reason, Godot recommends using GDScript by default and only translating performance critical code into C++.

1 Like