GDScript vs C# in Godot: Which Should You Pick?
GDScript is the right choice for most Godot projects. It has tighter editor integration, faster iteration (no compile step), and 84% of the community uses it, which means more tutorials, more addons, and faster answers to your questions.
C# is worth it if you already have a C# codebase, need NuGet packages, or are building a large project with 5+ developers.
Its static typing, interfaces, and IDE tooling (Rider, Visual Studio) make big codebases easier to manage.
Performance is no longer a reason to pick C#. GDScript with static type annotations runs up to 59% faster than untyped GDScript. For typical game logic, the difference between typed GDScript and C# is invisible to the player.
84% of Godot developers use GDScript
The Godot Community Poll 2025 , which surveyed roughly 9,600 developers, found that only about 16% of respondents use C# to build their Godot games. GDScript dominates, and that gap has not narrowed meaningfully over the last three survey cycles.
This matters beyond preference. When you hit a bug at 2 AM, you want the language where the answer already exists on the Godot forum. GDScript has that coverage. C# answers exist, but they are sparser, and addons from the asset library almost always ship with GDScript examples first.
The most commercially successful Godot games reflect this split. According to revenue analysis based on Steam review data , Brotato earned an estimated $10.7 million, Dome Keeper $6.1 million, Cassette Beasts $4.1 million, and Halls of Torment $3.4 million. All were built with GDScript.
The performance gap is smaller than you think
The old argument was simple: C# is compiled, GDScript is interpreted, therefore C# is faster. That was true in Godot 3. In Godot 4, the picture changed significantly.
GDScript 4 introduced typed instructions , which let the VM skip runtime type checks when you add static type annotations. The result is dramatic. Independent benchmarks running 1 billion iterations on an M2 Max show:
Vector2 operations, which games use constantly, ran 59% faster with type annotations. The official Godot typed instructions report confirms 5-150% speedups depending on the operation type, with simple attribute access at the low end and pre-validated native function calls at the high end.
C# still wins on raw computational throughput. For tight numerical loops, array sorting, and custom physics simulations, C# with .NET’s AOT compilation runs considerably faster than typed GDScript. But here is the thing most comparison articles miss: almost no game logic lives in tight numerical loops. Player controllers, UI updates, dialogue trees, quest systems, camera logic, inventory management: these are all bottlenecked by engine API calls, not by language execution speed. Both GDScript and C# call the same C++ engine underneath. Once you hit get_node(), move_and_slide(), or queue_free(), the language overhead disappears.
If your game needs custom fluid simulation or real-time pathfinding over 100,000 nodes, C# (or GDExtension with C++) is the right tool. For everything else, typed GDScript is fast enough that you will never notice the difference during gameplay.
GDScript is built for Godot. C# is bolted on.
This sounds harsh, but it is the practical reality. GDScript was designed alongside the engine, and it shows in dozens of small ways:
Signals. GDScript’s signal keyword and await syntax are first-class. Connecting a signal is one line. In C#, you use ToSignal() wrappers and explicit delegate patterns. It works, but it is more verbose.
Coroutines. Every GDScript function is automatically a coroutine. You can await any signal or timer without changing the function signature. In C#, you need explicit async patterns with SignalAwaiter.
Editor integration. The built-in script editor understands GDScript natively: inline docs, node path autocompletion, drag-and-drop node references, and the ability to run changes instantly without recompilation. C# requires an external IDE (Rider, Visual Studio, or VS Code with the C# extension), and a separate compile step.
No import management. GDScript auto-resolves all engine types. You never write using Godot; or manage namespace conflicts.
David Amador, a veteran Unity developer, made a deliberate choice to learn GDScript when switching to Godot . His reasoning: “Honestly I’m growing tired of C#” and “there are way more tutorials and examples online using GDScript.” After building prototypes in GDScript, his assessment was direct: “GDScript itself is fun, clean, and powerful enough for full games.”
Popcar, another Unity migrant, put it more bluntly in their migration guide : “C# users are second-class citizens in many aspects in Godot.” They cited missing web export support, more bugs in the C# integration, and fewer tutorials as concrete reasons to switch to GDScript.
What you actually give up with each choice
Every comparison article tells you C# has “more features.” Few of them tell you what you lose by picking it. Here is the honest version for both sides.
GDScript has no external package manager, weaker IDE tooling than Rider or Visual Studio, and no interfaces or generics for large-codebase architecture. If you are building something with 50,000+ lines of code across eight developers, you will feel the absence of private, protected, and proper namespace organization.
C# has its own set of costs. As of Godot 4.6 , you still cannot export C# projects to web. The .NET WASM architecture conflicts with how Godot handles web builds, and there is no official timeline for a fix. You also cannot call GDExtensions directly from C#, which means any addon built as a GDExtension needs a GDScript wrapper. And every code change triggers a recompile, which adds friction when you are rapidly iterating on enemy behavior or UI tweaks.
That said, C# earns its complexity budget in specific scenarios. Sergio Flores ported a game with 500+ C# scripts from Unity to Godot in a single weekend because his existing codebase was already in C#. Rewriting all of that in GDScript would have been months of wasted effort. If you need NuGet packages for networking, database access, or serialization, C# is the only option. And for computational workloads like custom physics or procedural generation that crunches millions of data points per frame, .NET AOT compilation gives you native-speed execution that GDScript cannot match.
Even Chickensoft , the most prominent C# advocacy organization in the Godot ecosystem, acknowledges that “for most people, GDScript is probably the best choice.”
Start with GDScript. Add C# when the project demands it.
The chart above is not a popularity contest. It reflects where each language has a structural advantage in Godot 4.6. GDScript wins on everything that touches the editor and the iteration loop. C# wins on everything that touches codebases over 10,000 lines and external tooling.
For your first Godot project, a solo game, a game jam entry, a 2D game, or anything that needs to run on the web: GDScript. You will prototype faster, find answers faster, and ship faster.
For a Unity port with existing C# code, a team of 5+ C# developers, or a project that depends on the .NET ecosystem: C#. Do not fight the tooling you already have.
For projects that land in between, Godot supports cross-language scripting . You can prototype in GDScript and rewrite performance-critical systems in C# later. This is not a theoretical option; it is how several shipped Godot games handle it.
The worst decision is spending weeks agonizing over this question. Both languages ship real games. If you are comparing Godot vs Unity or figuring out which engine to start with, that is a bigger decision than which scripting language to use inside Godot. And regardless of which language you pick, AI tools for Godot can accelerate your workflow either way.